A workflow connects blocks into a reusable procedure. A trigger supplies the input, blocks perform the work, and connections determine when each block runs.
This example classifies a customer message by category and urgency. Its Agent requests structured output through Response Format:
The parts of a workflow
Trigger
A trigger starts a run and supplies its input. A workflow can have several triggers, but each run enters through one.
Start accepts editor, API, and chat input. Event and timer triggers start runs automatically after deployment.
Block
A block performs a step. An Agent calls a model and can use tools; a Function runs code; a Condition chooses a branch.
A tool is an action an Agent can call within its step, such as searching a knowledge base or sending a Slack message. The block fixes that step's place in the workflow; the Agent chooses when to call its configured tools.
Function and Condition behavior is determined by the code or rule you supply. Model-driven blocks can produce different answers across runs.
Connection
A connection sets execution order. A block becomes ready when its active upstream dependencies have finished; independent branches can run at the same time.
Read an earlier output with a connection tag, such as <start.input> or <agent.content>. The tag's first segment is the block's name, not its type. See how blocks pass data and connection syntax.
Output
Each block produces its own output. A successful structured response in this example exposes <agent.category> and <agent.urgency>; ordinary Agent text appears in content. Check the output panel to confirm the actual shape.
In a simple chain, the workflow returns its last block's output. If several branches end independently, the last terminal block to finish supplies the default result. Join the branches into a final block or use Response to choose a deliberate result.
Callers can select individual block fields for chat responses, table workflow columns, or API output projection. The v2 API keeps its run-resource envelope: a Response block's result appears inside data.output, without changing the endpoint's HTTP status or headers.
Kinds of blocks
- Work: Agent, Function, API, and integrations.
- Control flow: Condition, Router, Loop, and Parallel.
- Run behavior: Response, Guardrails, Wait, and other core blocks.
An output can feed several downstream blocks without duplicating the source block.
How a workflow starts
| Trigger | Starts a run from |
|---|---|
| Start | Editor input, an API call, or a chat message |
| Schedule | A configured timer or cron expression |
| Webhook | An accepted HTTP request to its generated URL |
| RSS | An unseen RSS or Atom feed item |
| Table | A row insert, update, or delete in a Sim table |
| Sim Workspace Events | Run events, deployments, or workspace alert conditions |
| Integration trigger | An event in a connected service, such as a GitHub push or new email |
Editor runs use the draft. Automatic triggers use deployed configuration, so deploy an updated version after changing their blocks, connections, or settings.
Run and deploy
Use Run in the workflow builder to test a draft and inspect its block outputs. Open Logs to inspect recorded runs.
Deploy creates a versioned snapshot for API, chat, MCP, and automatic trigger runs. Editing the draft does not change the live version; Update deploys a new snapshot.