Hi all! I’m building a self-service platform on Temporal where a UI runs workflows contributed by many teams. To show and invoke them, I’d like to know ahead of time what workflows are available and what input each takes.
From what I can tell, Visibility covers executions but not registered definitions. Is that right, or is there a discovery mechanism I’m missing? And if you’ve built something similar, how do you source the workflow list and input schemas?
Thanks you
What do you mean by workflow defs? Do you mean the actual source code of the workflow that is being executed by Temporal/worker?
Thank you for responding. By Workflow definitions, I mean an endpoint where I can see all the workflows that have been registered to their worker and their input and output schemas. An endpoint similar to this in Kestra - /api/v1/{tenant}/flows/{namespace}. This will make it easier to discover workflows and integrate them dynamically into our IDP.
Steven, for some reason I cannot see your message. This what I see in your previous reply
You’re right, Visibility only indexes executions, not registered definitions. The server itself has no concept of your workflow types or their input shapes, the worker registers those locally, and the server just sees opaque task queues and data-converter payloads. So no API endpoint will ever give you that catalog.
The pattern that worked for us was to flip it around and make each worker self-describe. Every team’s worker registers a well-known describe workflow (or query) on its task queue that returns the workflow types it has registered and their input schemas. Your control plane polls each team’s queue for that describe workflow and you get live truth instead of a hand-maintained catalog that drifts the moment someone adds a workflow and forgets to update the docs.
For the static fallback, generate a manifest at build time from the registered types. It works fine until it doesn’t, someone adds a workflow, the manifest doesn’t get regenerated, and your UI shows a workflow that no longer exists or misses one that does. That drift is exactly why the live describe endpoint ends up being the source of truth.
So no, Temporal doesn’t give you that endpoint. You build it yourself on top of the workers, and the trick is making the workers the registry rather than trying to get the server to tell you something it fundamentally doesn’t know.