Workflows

A workflow is a versioned graph of steps (nodes) connected by edges (channels and messages).

If Jobs is about authoring one job, workflows are about composing many jobs into a system.

Lifecycle: draft → publish → new version

Draft: editable while you iterate.
Validate: checks schema and binding rules before you can publish.
Publish: makes the version immutable (the version you deploy).
New version: to change a published workflow, clone it into a new draft and publish again.

This “immutable published artifact” rule is the same idea used for jobs.

Perspectives vs workflows

Workflow: a deployable graph once bindings and validation are complete.
Perspective: a starter workflow skeleton with unbound slots. You clone/start from it, complete bindings, then publish a normal workflow version before planning deployment.

Steps: binding to building blocks

Each step is one node in the graph. A step becomes runnable when it is bound to a building block:

Blueprint: a reusable module from the Catalog (connectors, adapters, patterns).
Workflow module: an imported workflow that exposes an in/out interface (a reusable subgraph).

Steps have in and out bindings. Those bindings name the channels the step consumes/produces.

Edges: channels and transport kinds

Channel edges are the data plane: events flow along a named channel from producer steps to consumer steps.

Each edge also has a transport kind that controls how those events move (for example, fast in-memory vs durable spooling). The Deployment Manager can “stitch in” the required transport adapters when you choose a transport kind; you usually do not need to add extra steps manually.

If you pick a durable transport, the plan may include additional adapter jobs (for example “writer/reader” pairs). That is expected.

Rule of thumb:

Use worker channels for low-latency hops within a worker group.
Use file store or object store transports at stage boundaries where you need durability, replay/backfill, or blast-radius isolation.

Message edges: trigger and coordination

Message edges are the trigger plane: they wire “wake up” signals between steps. They are not for bulk event transport.

If you want the deeper mechanics, see Deployments Core Concepts and Messages. For how message tags/filters map into job DSL (output.message.tag and input.internal-messages.filter-tag), see Message Bus.

If you want a curated “run this now” invocation surface (UI + MCP) for message-trigger flows, see Triggers.

Starting points (Catalog workflows)

The Catalog includes end-to-end workflows you can use as starting points (for example the built-in “Quickstart: File Store Roundtrip” workflow), plus perspectives for guided architecture starters.

Typical flow:

Open Catalog and filter to Workflows or Perspectives.
If you selected a workflow, click Plan & register.
If you selected a perspective, use Start from this / Clone to workspace, finish bindings in the editor, then publish.
Provide a deployment name, select a worker group, and complete any wizard fields if the workflow provides them.