Waits and Timers
A workflow can pause. That is what makes it a process rather than a script.
Where to find it
Architect Panel → Automation:
- Workflow Builder — the canvas, nodes and edges
- Worklist — what is waiting on a person
Architect Panel → Automation:
- Tasks — the task that resumes waiting runs
Architect Panel → Data:
- Business Hours Calendars — working hours for timers
How pausing works
A run that reaches a wait or a timer records when it should resume and which port it will leave by, then stops. A scheduled task periodically picks up runs whose time has passed and continues them.
So nothing is held open, and a workflow can span days or weeks at no cost.
Wait against SLA
- Wait — pause, then continue. One outcome.
- SLA — a target with two outcomes, met or breached, each continuing down its own path.
Use a wait for "send a reminder three days later". Use an SLA for "respond within four hours or escalate", because the two outcomes genuinely differ.
The resume task must be running
The practical consequence. If the task that resumes waiting runs is disabled or failing, every workflow with a wait quietly stops mid-process.
Nothing errors — runs simply sit. When workflows "stop working", check that task first.
Working hours, not wall-clock
A four-hour target should mean four working hours. An SLA measured against the clock reports every Friday afternoon request as breached by Monday, and the team is not at fault.
Waits must be bounded
A run waiting for something that never arrives waits forever. Where a wait depends on an external event, pair it with a timer so the process has a way out.
The record may change while waiting
Three days is long enough for a case to be closed, reassigned or deleted. A workflow resuming into a changed situation should check before acting — sending a chaser about a resolved case is a small failure that customers notice.
A condition immediately after a long wait is usually worth having.
Watch how many runs are waiting
A growing population of waiting runs means either a resume task that is not running or a wait nothing satisfies. It is a useful number to look at occasionally.
Test with short waits
Build with a wait of a few minutes, confirm the whole path works, then set the real duration. Testing a three-day wait by waiting three days is how workflows go live untested.
Worked example
A workflow acknowledges a request, runs a four working-hour SLA timer, escalates on breach and continues on success. A three-day chaser wait is followed immediately by a condition checking the case is still open. Both were tested with two-minute durations first.
Recommendations
- Check the resume task when workflows stall.
- SLA timers against working hours.
- Re-check the record after a long wait.
- Test with short durations, then set the real ones.