Two concepts work together to define what a stage does: Stage Actions define the buttons the authoriser sees and what happens when each one is clicked, while Stage Statuses are the human-readable labels that travel alongside the request so the requester (and anyone with read access) can see where it currently sits.
Get these two right and your workflow practically explains itself to users. Get them wrong and you end up with stuck requests, confused requesters, and authorisers who don't know which button does what.
Stage Actions
Each row in the Stage Actions section attaches one or more actions to a specific stage. The action set effectively defines the authoriser's options at that stage.
A typical configuration on a manager-approval stage might be:
- Approve — advances the request to the next stage. Sends the Approved/Progress email to the requester.
- Decline — terminates the request and sends the requester the Declined email. The request is marked as declined permanently.
- Request More Information — bounces the request back to the requester so they can revise their submission. See the Stage Information Request Reminders article for the flow.
- Cancel — cancels the request entirely. Suitable for spam, duplicates, or withdrawn requests. Distinct from Decline in that Cancel implies "shouldn't have been submitted" while Decline implies "reviewed and rejected".
You can add as few or as many actions as you like on each stage. A stage with no actions is unusual but valid — it'd be a pure read-only checkpoint that moves on automatically (e.g. when paired with a timeout).
Stage Statuses
Each Stage Status sets the label the request displays while it's at a given stage. "Awaiting Manager Approval", "With Finance", "In Triage", "Ready to Order" — short, descriptive, and ideally something the requester can read and understand without needing the platform's internal vocabulary.
When the authoriser actions a request and it moves on, the status updates automatically based on the next stage's status row. The status appears:
- On the requester's view of their own submission.
- On any browse view that lists submissions.
- In the email notifications the requester gets (as a merge token:
##STATUSNAME##). - In the audit log.
Note: A request also has built-in overall lifecycle statuses — Submitted, Approved, Declined, Cancelled, More Information Required. The per-stage status configured here sits underneath those and gives the user finer-grained visibility into which stage the request is currently at. The two layers work together rather than replacing each other.
Stage Decline / Cancellation Notifications
If you need different email behaviour when a request is declined or cancelled at different stages, use the Stage Decline/Cancellation Notifications sub-section. There you can override the default Declined or Cancellation email template per stage, so a late-stage rejection can use a different message than an early-stage one.
Two examples of why you'd want this:
- An early-stage decline ("the request doesn't meet basic eligibility criteria") should be polite but quick. "Thanks for submitting; this didn't meet our requirements. Reasons attached. Feel free to re-submit if circumstances change."
- A late-stage decline ("the request was approved through 4 stages but the final sign-off declined") should be more detailed. "Your request was reviewed through every stage and ultimately declined at final sign-off. Here's the detailed reasoning. You can appeal by replying to this email or contacting your account manager."
Three worked-example workflows
Concrete configurations that show how Actions and Statuses fit together:
Workflow 1: Simple two-stage purchase approval
- Stage 2 — Manager Approval. Actions: Approve, Decline, Request More Information. Status: "Awaiting Manager Approval".
- Stage 3 — Finance Review. Actions: Approve, Decline. Status: "With Finance".
- Final state on completion: built-in "Approved" status. Status string shown to requester: "Approved — Ready to Order".
Workflow 2: Three-stage IT change request
- Stage 2 — Technical Review. Actions: Approve, Decline, Request More Information. Status: "Under Technical Review".
- Stage 3 — Change Advisory Board. Actions: Approve, Decline (with escalation note). Status: "At CAB".
- Stage 4 — Scheduling. Actions: Schedule (custom action that requires picking a date), Cancel. Status: "Scheduled — awaiting implementation".
Workflow 3: Customer support ticket with iterative back-and-forth
- Stage 2 — Triage. Actions: Assign to Specialist, Request More Information from Customer, Close. Status: "In Triage".
- Stage 3 — Specialist Investigation. Actions: Resolved, Need More Info from Customer, Escalate. Status: "Specialist Working".
- Stage 4 — Customer Confirmation. Actions: Confirmed Resolved, Still an Issue (loops back to Stage 3). Status: "Awaiting Customer Confirmation".