Approvals and waiting steps
A workflow pauses on purpose. Approval steps hold an action until a person confirms it, and waiting steps hold the run until a reply, a sub-task, or a set time arrives. Every wait resumes automatically when its condition is met, without anyone re-running the flow.
How approvals work
Certain tools Harriet uses inside a workflow are approval-gated, for example sending an email or updating another system. Instead of running immediately, the workflow pauses until someone authorized approves the action. When the run is linked to a ticket, the pending action typically appears in the ticket view where your team already handles support. After approval, Harriet runs the deferred action and continues the same workflow, with context that the user confirmed it.
Approvals exist to prevent accidental mass emails or production writes from an automated run, and to give the team that owns the process a human checkpoint before sensitive operations. A common pattern: a workflow drafts an email to a vendor with account context attached, pauses until a team lead clicks Approve on the ticket, and only then sends the message and moves to the next step.
Make sure on-call approvers are defined for workflows that can pause outside business hours, and document what should happen when an approver rejects or ignores a request; often that is a manual ticket update or a workflow revision.
The wait types
A waiting step is intentional: the workflow pauses until something happens, then continues from where it stopped.
| Wait type | Pauses until | Typical use |
|---|---|---|
| Approval wait | An authorized person approves the pending action, often on the ticket | Sending email, writing to another system |
| Ticket reply wait | Someone replies on the ticket thread | The workflow asked a question of a person already on the ticket |
| Outreach wait | A contacted person answers by email or chat | Data-gathering conversations with someone outside the thread |
| Scheduled wait | A set duration passes | Letting an upstream system change propagate, or waiting 48 hours before chasing an unpaid invoice |
| Sub-task wait | A delegated sub-agent finishes its task | Sub-agent delegation |
Each wait resumes on its own when the condition is met. The ticket or workflow run page shows that the run is paused or waiting, and when the wait completes, the next agent steps continue with the new information included; the agent keeps the full context of everything that happened before the pause, as described in The agent step.
Example
An access-request workflow asks IT a question on the ticket and enters a waiting state. When IT replies "The license ID is 998877", the workflow resumes, fills the form, and closes the task. No one restarted anything; the reply itself woke the run.
Long waits should have an owner so stuck flows are noticed. And do not use a scheduled wait as a substitute for a business approval: when human judgment is required, use the approval mechanism, not a timer.