Skip to main content
An approval does not enforce itself. Something has to say which action needs a witness, and who that witness is. This is that something.

​
Two screens

  • Approval workflows — where a chain is built.
  • Workflow activity — where you find out a chain is stuck, before somebody complains that it is.

​
Building a chain

A workflow ties together three things: Each step names an approver by role, not by person — the same reasoning as notification audiences: naming a person is what breaks the day they leave. A step can also name more than one role, and say whether any one of them clears it or all of them must.

​
The chain is a graph, not a list

Drawn as boxes and arrows — a step per box, an arrow to whatever comes next — because a chain that branches (three approvers under a threshold, a fourth above it) is a shape a numbered list cannot show honestly.
  • Drag a box to arrange the chain.
  • Draw an arrow to send one step’s outcome into the next.
  • Click a step to set its approver role, and whether the chain continues on rejection or stops there.
Most chains are a straight line. The graph is only worth its screen space once a chain forks by amount, category or site — a purchase request chain is the usual reason one does.

​
Draft and publish

A workflow is versioned and published, exactly like state models and inspection templates. A draft can be reshaped freely; a published version cannot, because live approvals are already running against it.
Edit a live workflow and the edit lands on a new draft, not on the version chains are currently running against. Publish that draft and new triggers start using it; a chain already in flight finishes against the version it started on, so a change to the approver list never rewrites who actually signed off on something already underway.

​
Workflow activity

A monitor, not an editor. It exists so an admin sees what is blocked rather than discovering it when the person waiting on it complains.
Chains that are stuck, overdue against however long a step is allowed to sit, or failed outright — a step whose named role nobody currently holds, the same failure mode notifications can hit, and for the same reason: the chain and the approver list both look fine on their own, and only the actual running instance shows that nobody can act on it.
Every chain currently in progress, healthy or not, so you can see the shape of what is moving through approvals right now — not only the exceptions.
Each row names the workflow, the record it is guarding, which step it is sitting at, who that step names, and how long it has sat there. Opening a row goes to the record itself — usually Approvals is where the actual decision gets made, by whoever holds the role the stuck step names.

​
Who can configure workflows

Building and publishing workflows takes the workflow administration permission — System Administrator and Maintenance Administrator by default. See roles.

Related topics

ApprovalsRulesPurchase ordersPurchase requestsLost & Found