Workflows
A workflow is desired state: a versioned graph of steps and data or message edges. The Deployment Manager compiles a published workflow into jobs, transports, and assignments; the graph itself is not one long-running process.
Editor anatomy
Section titled “Editor anatomy”- Palette: jobs, built-in routing primitives, and reusable workflow modules available in the selected environment.
- Canvas: nodes and their typed input/output ports.
- Inspector: bindings, parameters, ports, dispatch, placement hints, and validation details for the selected item.
- Manifest: the declarative representation used for review and automation.
- Validation: structural, binding, transport, and availability findings.
Catalog items and Provider Packs appear only according to their installed and ready state. A missing palette item is not permission to substitute an internal API or claim the capability is installed.
The authoring and deployment lifecycle keeps reviewable desired state separate from runtime proof:
flowchart TD
accTitle: From workflow draft to running evidence
accDescr: An operator drafts and validates a workflow, publishes an immutable version, reviews a deployment plan, applies it, waits for convergence, and then collects runtime and destination evidence. Failed validation returns to the draft, and changed intent requires a fresh plan.
draft["Draft workflow"] --> validate{"Validation clean?"}
validate -- "No: correct findings" --> draft
validate -- Yes --> publish["Publish immutable version"]
publish --> plan["Plan deployment"]
plan --> review{"Plan matches approved intent?"}
review -- "No: correct and re-plan" --> plan
review -- Yes --> apply["Apply fresh plan"]
apply --> converge["Wait for convergence"]
converge --> evidence["Collect runtime and destination evidence"]
Create a workflow
Section titled “Create a workflow”- Open Workflows and choose New workflow.
- Give the draft a stable, outcome-oriented name.
- Drag a source or reusable module from the palette onto the canvas.
- Add processing, routing, and destination steps.
- Connect data output ports to compatible input ports.
- Select each node and complete required bindings in the Inspector.
- For branching, insert the Fan Out/routing primitive, add named output ports, and choose a dispatch mode. See Routing and Fan-out.
- Select an edge and choose a transport whose locality and durability match the topology. See Transports and Durability.
- Inspect the manifest and run validation.
Data edges and message edges
Section titled “Data edges and message edges”A data edge carries event payloads over a selected transport. A message edge wakes a step when a tagged internal message is observed; it does not carry the bulk event stream. Multiple message sources are OR-style wakeups. If the outcome requires an AND barrier, model explicit state and a supported join pattern rather than drawing two message arrows and assuming both are required.
Imports and reusable modules
Section titled “Imports and reusable modules”An imported workflow or blueprint packages a reusable bounded pattern. Keep its alias and node IDs stable because bindings, placement, and scaling intent can refer to them. Review the module’s availability, required credentials, transport assumptions, and limitations before publishing the parent graph.
Validate before publishing
Section titled “Validate before publishing”Resolve every error and review every warning. In particular, check:
- every required port is connected exactly as intended;
- dispatch behavior and unmatched conditional routes are explicit;
- worker-local edges are co-located;
- local file paths are not split across workers without shared storage;
- required contexts, variables, credentials, and Pack items are ready;
- placement references point to current stable node IDs;
- replica intent does not imply an unproved ownership model.
Validation proves that the graph is structurally admissible. It does not prove source/destination connectivity, sustained capacity, recovery, or external acceptance.
Publish an immutable version
Section titled “Publish an immutable version”When review is complete, choose Publish and record the workflow name and version. Published versions are immutable deployment inputs. To change one, create a new draft/version, validate it, and publish again; do not treat an editable draft as the artifact currently deployed.
Hand off to deployment
Section titled “Hand off to deployment”From the published version choose Plan and register (or create a deployment from Deployment Manager). Select a worker group and review the generated plan before apply. Continue with Deployment Manager.
For automation, use the gated MCP workflow lifecycle.