Skip to main content
A Workflow turns an authored Program into a reusable, versioned, durable process. Program source is the canonical definition; the topology in the Portal is a derived view, not a graph you edit.

​
Where they live

Open Workflows in the Portal. There is no separate build queue or visual graph designer.

​
Create a Workflow

Choose New workflow, then one of two starting points:
  • Generate from intent — describe the desired process. Noorle generates a Rune Program against the available Program surface and attempts bounded repair when compilation reports a problem.
  • Blank advanced draft — start with editable Program source, a name, and an optional description.
Both create a mutable draft. Neither creates a runnable version yet.

​
Prepare the draft

Work through the Workflow sections in this order:
  1. Bindings — attach the capabilities, Agents, knowledge bases, and child Workflows the Program may call.
  2. Schemas — define JSON Schema for input and output.
  3. Intent — describe a change and generate or patch the draft.
  4. Advanced — inspect or edit the entrypoint and Rune source; use the declarations panel for the exact bound handles.
  5. Overview — compile or dry-run, inspect the derived topology and effect manifest, and compare the draft with the active version.
Bindings are part of the Program contract. Noorle issues stable source handles from resource IDs, while display names remain presentation only.
Do not place credentials in Program source or input. Bind a connector so Noorle can inject and protect the credential at the capability boundary.

​
Publish and activate

Select Publish to compile the saved draft and create a new immutable version. Publishing never mutates an earlier version. Then activate the version you want new runs to use. A Workflow must be active before it can start, including when a caller requests a specific older version. Changing the active version affects future starts only; every existing run keeps the version it began with.

​
Start a run

From Runs, select Run, choose the active version or another published version, and provide JSON input. The input must satisfy that version’s input schema. Workflows can also start from:
  • an Agent or MCP gateway with the Workflow attached;
  • POST /v1/workflows/{workflow_id}/runs in the Management API;
  • a schedule Automation;
  • a parent Workflow that has it bound as a child.
Every mutating Management API request that starts, cancels, or signals a run must carry a retry-stable Idempotency-Key. Reuse the key when retrying the same logical action; use a new key for a new run or signal.

​
Add a schedule

The Automation section answers when the Workflow should start. Publish and activate a version first, then select an Agent owner, schedule, and input. The Agent must already have this Workflow attached. The Automation and Workflow remain separate objects. Replacing an Automation does not change Workflow source, and publishing a Workflow version does not create a schedule.

​
Current Workflow architecture

Customer Workflows use one Program-backed durable execution path. The retired graph definitions and Restate-backed customer runner are not selectable and cannot be run through the current Workflow surface.

​
Next