Workflow Builder

The workflow builder is where you design and run AI workflows. You compose them visually as a connected graph of steps, test them, and then publish them for use across your organisation.

Anatomy of the canvas

Open a workflow and you see four areas:

• Canvas - the connected graph of nodes and edges.
• Toolbar - save, run, preview, and publish actions.
• Side panel - properties for the selected node.
• Preview panel - a chat-style runner for testing the flow.

Drag nodes from the palette, connect them with edges, click any node to edit its properties.

Node types

The platform ships node types tailored to common AI patterns. The exact set depends on what your administrator has enabled. Common categories include:

• Input/output - entry points and result shapers.
• Model - calls a language model with a configurable prompt template.
• Knowledge retrieval - runs a similarity search against a knowledge collection and binds the matching content into the prompt.
• Logic - conditionals, loops, and branching.
• External - outbound HTTP calls and webhooks.

If your environment exposes additional custom nodes, they appear in the palette automatically.

Save and version

Every save creates a new version of the workflow. The version list is the audit trail of your edits. Two states matter:

• Draft - your in-progress version. Multiple drafts can exist in a row.
• Published - the version that callers consume. There is exactly one published version per flow at any time.

Promoting a draft to published is an explicit action. Until then, your edits do not affect anyone running the flow externally.

Version history

In the workflow list, each workflow shows a version marker next to its name, such as v3 (+2). The first number is the current version; the (+2) tells you how many earlier versions exist.

Click the (+N) marker to expand the list of earlier versions. Each entry shows:

• its version number,
• whether it is published or a draft, and
• when it was saved.

From the expanded list you can:

• Open a version - click any entry to open that exact snapshot in the editor, just as it was when you saved it.
• Delete a version - use the ⋮ menu on an entry to remove it. This cannot be undone, and any documents generated from that version are removed with it.

Saving or publishing without making changes does not add a new version - the platform recognises identical content and keeps the history free of no-op entries.

Restoring a previous version

There is no separate "restore" button - you bring an older version back by publishing it again:

1. In the workflow list, expand the version history with the (+N) marker.
2. Click the version you want to restore. It opens in the editor exactly as it was saved.
3. Click Publish.

That snapshot becomes the published version again, keeping its original version number, and the version that was live before is unpublished. Because nothing changed, no new entry is added to the history.

To branch off without touching the original instead, duplicate the workflow (the copy icon on the workflow row). That creates a separate workflow with its own independent history.

Preview vs. asynchronous run

Two execution modes:

• Preview - synchronous; the response streams back into the chat panel. Best for design-time testing.
• Asynchronous - queues a job; a worker picks it up and writes the result back into the workflow's history. Best for long-running flows and external callers.

Run history

Every run produces a record with input, output, status, and any error. The runs panel lists them with timestamps and lets you re-open the input and output for inspection. Failed runs include the error message that was returned.

For deeper detail - prompt, model, latency, token usage - open the audit trace linked from the run.

Publishing a flow for external callers

Once a flow is published, external systems can invoke it through the platform API. Both synchronous and asynchronous endpoints are available. Authentication is the same as for the UI - a token issued by your identity provider that represents either a user or a service account.

Common pitfalls

• Referencing a model that is not available - the run fails fast with an explicit error. Either ask your administrator to enable the model or change the node's model setting.
• Empty knowledge collections - a retrieval node against an empty collection returns no chunks. Make sure ingestion has completed (sources show Completed).
• Long preview waits - preview is synchronous. For flows that take more than a few seconds, prefer asynchronous runs and view the result in the runs panel.

What to read next

• Knowledge base for retrieval-aware flows.