Workflow Builder - Temporal UI: why durable execution still needs a visual authoring layer
Workflow Builder has been shortlisted for Technology of the Year 2026 by money.pl. Learn more
Developers
Resources
PricingConsultingContact
Try for free
Text Link
Temporal Web UI is excellent at what it does: letting engineers see, search, and replay workflow executions in production. It is not a workflow authoring tool, and it was never meant to be. The gap between watching a workflow run and designing one with stakeholders is where a visual authoring layer earns its place… and the question Temporal teams keep asking is what that layer should look like.<br>The Temporal community runs into the same conversation almost every quarter. Someone on a forum, in a Slack channel, or on a GitHub discussion asks the same thing: is there a visual builder for Temporal workflows? The answer the community gives is consistent and accurate. Temporal is code-first by design. Workflows are TypeScript or Go or Java functions. The Web UI shows you what those functions did at runtime – pending activities, event histories, queries, signals, the whole timeline.<br>That is the right design for the engineering audience Temporal is built for. It is also why the question keeps coming back. Engineers do not always need a visual builder. Their stakeholders sometimes do.<br>What Temporal UI actually is (and what it is not)<br>Temporal Web UI is an observability and operations surface. Open it during a production incident and you can find a specific workflow run by ID, namespace, type, or status. You can read the full event history of every step the workflow took, replay it locally to reproduce a bug, send signals to running workflows, and inspect activity inputs and outputs. For engineers operating durable execution at scale, this is exactly the toolkit they need.<br>What it does not do – and is not supposed to do – is help someone design a workflow before it exists. The Web UI is the surface where you see the consequence of a code commit. The code commit itself happens in an IDE, and the conversation that led to the code commit happens somewhere else entirely: a whiteboard, a shared diagram, a Notion page with arrows, a Lucid file. Somewhere a product manager and an engineer agreed what the workflow should do.<br>That earlier conversation – the authoring conversation – is where the gap lives.
Temporal Web UI is on the observability axis. The authoring axis is open.Why a visual authoring layer matters even with great code<br>The argument against a visual builder for Temporal is that engineers can read code, and code is the source of truth. Both points are correct. The argument for a visual authoring layer is not that it replaces the code – it is that the code is not the only artifact a workflow needs.<br>Three audiences sit outside the codebase and have a legitimate need to see, edit, or contribute to a workflow:<br>#1 Stakeholders during design<br>When the conversation is "should the approval step branch on amount, or on customer tier, or both?" – that conversation goes faster on a visual canvas than in a TypeScript file. The output of the conversation becomes a spec, and the spec becomes the code. A visual authoring layer makes that whole loop tighter.<br>#2 Product managers and operations leads after launch<br>Once a workflow is live, the people closest to it are often the ones who cannot read its source code. They notice that step 4 should run before step 3, that a new node is needed for a regulatory check, or that a branch needs an extra condition. A visual layer lets them propose changes without filing a Jira ticket and waiting for a sprint.<br>#3 End users embedded in your product<br>If you are building a SaaS product on Temporal – and many durable execution use cases are SaaS products at the edges – your customers may need to author their own workflows inside your application. They are never reading your code. They need a canvas. Code-first is the right answer for the platform team. It is the wrong answer for the customer-facing surface.<br>None of this changes Temporal's value proposition. It simply means there is a layer above the runtime where authoring happens, and that layer needs its own surface.<br>What "visual authoring layer for Temporal" should mean<br>The phrase gets used loosely. Three different things have shown up in community discussions, and they are not interchangeable.<br>#1 Visualization of an existing workflow run<br>Temporal Web UI already does this for the timeline view. Some teams have built custom React components on top of Temporal's events to show a graph-shaped view of what a workflow did. This is observability, drawn as a graph – useful, but downstream of authoring.<br>#2 Code generation from a visual editor<br>A canvas where a user drags nodes and edges, then exports a TypeScript or Go file that compiles into a Temporal workflow. This works for narrow domains where the node types map cleanly to activities, and breaks down quickly for workflows with conditionals,...