Overview
A multi-step approval template is a reusable definition of who approves what, in what order. Once built, it can be assigned as the default flow for a project or department, and an individual activity can override it when it needs a different path.
Every submission snapshots the template at the moment it's submitted, so changing a template later never breaks approvals that are already in flight.
Before you start
Have three things ready before building a template: the ordered list of approval steps, the primary and fallback approver for each step, and how long each step should wait before it escalates.
- The steps, in order: e.g. Site Engineer → QA Supervisor → Project Director.
- A primary and fallback approver for each step, in case someone is unavailable.
- An SLA duration per step, and who gets escalated to if it's missed.
- Which step a rejection should return to, the same step, or an earlier one.
Step 1: Create a template
In the Control Panel, open Approvals and start a new template. Give it a clear name that describes what it governs (for example, "Construction sign-off" or "Expense over $500") since this name is what approvers see on every request that uses it.
Step 2: Define steps and approvers
Add each step in order and assign its primary approver. Set a fallback approver for steps where a single point of failure would stall real work. This matters most for steps with tight SLAs or infrequent approvers.
Step 3: Set SLAs and reject-to-step logic
Give each step an SLA (how long it can sit before it escalates) and choose where a rejection sends the submission back to. Reject-to-step routing means a return goes to the exact step that needs to re-review it, not back to the beginning by default.
Step 4: Assign the template
Assign the finished template to a project or department as its default flow. If one activity or package needs a different path (an extra sign-off, a different approver) it can override the default without changing the template everyone else uses.
What happens after you publish
New submissions snapshot the template at submit time, so future edits only affect what comes after. Approvers see exactly what's waiting on them in their personal queue and can act from chat, mobile, or the queue itself, with every approval, rejection, and timestamp captured in an immutable audit trail.
