Build a workflow
A workflow is the series of steps an application follows. In the app it’s called a flow. Each step does one thing, and the lines between steps say what happens next.
Steps you can use
| Step | What it does |
|---|---|
| Trigger | Starts the workflow, from a system event or a schedule. |
| Heuristic | Applies rules, thresholds and lookups. |
| Agent | A model with tools, such as reading a record or searching your documents. |
| Thinking agent | Uses extended reasoning and plans before it acts. |
| Judge | Scores an output against a rubric, for example to check a draft before anyone sees it. |
| Person | Puts a decision in someone’s Inbox. |
| Action | Writes to a connected system. |
| Code | Runs a short piece of TypeScript in a sandbox. |
| Record | Writes to a data store. |
The canvas arranges steps in five lanes, from left to right: Intake, Reasoning, Decision, Effect and Record.
What can start a workflow
A workflow has one trigger. It can start:
- On a schedule, such as every weekday at 07:00.
- When something happens in a connected system, such as a deal reaching a stage.
- When something happens in Flowstate.
- When another system calls it.
- When someone selects a button on a row in a view.
- When a builder starts it by hand.
Rules every workflow follows
- One trigger. Each workflow starts in one way.
- No loops. To do something more than once, set a repeat on the step instead.
- Say what happens otherwise. When lines out of a step have conditions, add one line with no condition, so the workflow knows what to do when none of them apply.
When a draft breaks one of these, the workflow lists the problem, and it can’t be published until it’s fixed.
Test as you go
Give the workflow test cases: sample inputs and the result you expect. Run them as you build. A workflow can only be published once its tests have passed since it last changed. See Publish and deploy a workflow.