Steps & Gates
Every workflow is built from two building blocks: steps (the work that gets done) and gates (the checkpoints that control flow). This guide covers all available step types, gate configurations, and how steps connect to each other through transitions.
Step types
Section titled “Step types”Each step in a workflow has a type that determines its behaviour. Choose the type that matches what you need the step to do.
Action steps are the most common type. An assigned agent performs a task based on the instructions you provide.
When to use: Any time you need an agent to do something — send an email, look up data, draft a document, update a record.
Configuration:
- Agent — Select which agent handles this step
- Instructions — Tell the agent exactly what to do. Be specific and include any context the agent needs.
- Gate — Choose what happens after the step completes (auto, review, or approval)
Example: “Using the Gmail integration, send a welcome email to the new employee. Include the start date and office address from the workflow input.”
Condition steps add if/else branching logic. The workflow evaluates a condition and follows one of two paths depending on the result.
When to use: When the next step depends on the outcome of a previous step. For example, “If the refund amount is over $500, route to the senior manager for approval. Otherwise, auto-approve.”
Configuration:
- Condition — Define the rule that determines which path to follow. Conditions are evaluated against the output of previous steps.
- If true — The step to run when the condition is met
- If false — The step to run when the condition is not met
Example: A condition step after an order lookup that checks whether the order is within the return window. If yes, proceed to the refund step. If no, send a polite decline message.
Fork steps split the workflow into parallel branches. Multiple steps run at the same time instead of waiting for each one to finish before starting the next.
When to use: When you have independent tasks that do not depend on each other. For example, during employee onboarding you might want to create an email account, order a laptop, and schedule orientation all at once.
Configuration:
- Branches — Define two or more branches, each containing one or more steps. All branches start executing simultaneously when the fork step is reached.
Example: Fork into three branches: (1) IT agent creates email account, (2) Procurement agent orders equipment, (3) HR agent schedules orientation meeting.
Join steps merge parallel branches back into a single path. The workflow waits until all incoming branches have completed before moving forward.
When to use: After a fork step, when you need all parallel tasks to finish before proceeding. For example, wait for all onboarding tasks to complete before sending the “You’re all set!” email to the new hire.
Configuration:
- Wait for — By default, a join step waits for all incoming branches. You can optionally configure it to continue after a specific number of branches complete.
Example: After the onboarding fork, a join step waits for IT setup, equipment order, and orientation scheduling to all finish, then triggers a final notification.
Pipe steps chain the output of one step directly into the input of the next. The output from the previous step becomes part of the instructions for the next agent.
When to use: When one agent’s work needs to feed directly into another agent’s task. For example, a research agent gathers data, then a writing agent uses that data to draft a report.
Configuration:
- Source — The preceding step whose output will be passed along
- Agent — The agent that receives the piped data
- Instructions — What the agent should do with the piped data
Example: Step 1 (Research Agent) gathers competitor pricing. Step 2 (pipe) passes that data to the Analysis Agent with instructions: “Compare these prices against our current pricing and recommend adjustments.”
Gate types
Section titled “Gate types”Gates sit between steps and control the transition from one step to the next. Every step has a gate that determines what happens after it completes.
Auto gates let the workflow continue immediately. No human interaction is needed.
When to use: For steps where you trust the agent’s output and do not need anyone to check it before moving on. Most internal data-gathering and notification steps use auto gates.
Behaviour: As soon as the step completes successfully, the workflow automatically advances to the next step.
Review gates pause the workflow so a team member can inspect the agent’s work before it continues.
When to use: When you want a quality check but do not need formal approval. For example, reviewing a drafted email before it gets sent, or checking data accuracy before it is used in the next step.
Behaviour:
- The step completes and the workflow pauses
- A notification is sent to the designated reviewer (or the workflow owner if no specific reviewer is set)
- The reviewer sees the step’s output and can leave comments
- The reviewer clicks Continue to advance the workflow, or Send Back to have the agent retry the step with additional feedback
Notifications: Reviewers receive a notification in the portal and, if configured, via email or Slack.
Approval gates require explicit sign-off from an authorised person before the workflow can proceed.
When to use: For steps with real business impact — financial decisions, publishing content, granting access, or any action that cannot be easily undone.
Behaviour:
- The step completes and the workflow pauses
- A notification is sent to the designated approver
- The approver reviews the step output and clicks Approve or Reject
- If approved, the workflow continues to the next step
- If rejected, the workflow stops (or follows a rejection path if you have configured one)
Approval tracking: Every approval decision is logged with the approver’s name, timestamp, and any comments they provided. This creates an audit trail for compliance purposes.
Transitions between steps
Section titled “Transitions between steps”Transitions connect steps together and define the order of execution. By default, steps run in sequence from top to bottom. Each transition carries data from the previous step to the next, so agents downstream can reference earlier results.
When you create a workflow, transitions are added automatically as you add steps. You can rearrange steps by dragging them in the workflow editor, which updates the transitions accordingly.
For condition steps, you define two transitions — one for the “true” path and one for the “false” path. For fork steps, you define one transition per branch. Join steps automatically pull in all incoming transitions and wait for them to complete.
Best practices
Section titled “Best practices”- Keep steps focused — Each step should do one thing well. Instead of one giant step that does everything, break it into smaller, targeted steps. This makes workflows easier to debug and reuse.
- Use gates strategically — Auto gates keep things fast. Add review and approval gates only where the cost of an error justifies the delay.
- Name steps clearly — Use descriptive names like “Look up customer order” instead of “Step 1”. Clear names make the execution view much easier to follow.
- Provide detailed instructions — The more specific your step instructions, the better your agent performs. Include what data to use, what format to output, and what to do if something goes wrong.
Next steps
Section titled “Next steps”- Creating Workflows — Build a complete workflow from scratch.
- Workflow Execution — Monitor running workflows, handle failures, and review history.
- Workflows Overview — Return to the overview for a refresher on workflow concepts.