Appearance
Workflow Configuration
Where to find it: Administration, then Workflow Settings (/settings/workflow).
Workflow configuration decides how much governance each kind of decision carries in your tenant.
For the mechanics of stages, transitions and resolvers, see Workflow Templates. This page is about the administrative decisions.
What you are configuring
| Decision | Effect |
|---|---|
| Which template governs which object type | The stages a decision passes through |
| Whether a routing tier gets a lighter chain | Proportionate governance for low-tier work |
| Which role is bound to each stage | Who receives the approval |
| Where segregation of duties applies | Which stages require an independent actor |
Choosing chain depth
Choose by consequence, not by seniority of the submitter
The question is not "who submitted this?" It is "what happens if this is wrong and nobody catches it?"
| Depth | Right for |
|---|---|
| Four-eye | Most operational governance: mappings, ordinary exceptions, standard policies, routine assessments |
| Six-eye | Material external consequence: regulatory responses, material outsourcing decisions, board-level policies, risk acceptance beyond appetite |
| Eight-eye | Where a committee genuinely needs to see it, and the delay is acceptable |
Over-deepening is not free. A six-eye chain on routine approvals produces a bottleneck, and bottlenecks produce workarounds.
Tier-based bindings
A binding can select a different template by routing tier, so low-tier work gets a proportionate chain.
| Object type | Tier | Template |
|---|---|---|
requirement | * | Full chain with management sign-off |
requirement | tier_3 | Lighter Work, Review, Close |
A tier binding does not reshape a run in progress
Bindings select the template when a run starts. Changing a binding never forces or skips a stage in a decision already under way.
This is deliberate: a decision part-way through a three-stage chain should not silently lose a stage because configuration changed.
Before changing a chain
Four checks worth running.
1. What is in flight? Existing runs complete on the template they started with. A chain change affects new decisions only.
2. Does every stage have holders? A stage bound to a role nobody holds routes nowhere. There is no error — the decision simply sits.
3. Does segregation actually hold? A six-eye chain where one individual holds two consecutive stage roles is a four-eye chain in practice. The engine blocks the same person acting twice; it cannot know that two roles are the same individual.
4. Have you recorded why? Approval chain changes are the kind of thing an internal auditor asks about, and "we tightened exception approval after an audit observation" is a better answer six months later than a configuration diff.
Reviewing chain health
Two metrics tell you whether a chain is doing anything.
First-time approval rate. A chain approving 99% of submissions first time is a chain nobody is reading. A realistic rate on a genuine review stage is 60% to 90%, depending on the object.
Median time to decision. A chain whose median exceeds its SLA is producing overdue work structurally, not occasionally.
The comparison that matters
Look at the two figures side by side across your chains. A four-eye chain at 88% first-time and 4 days, next to a six-eye chain at 56% and 11 days, tells you the six-eye chain is earning its cost. If both sat at 95%, neither would be.
Permissions
| Action | Permission |
|---|---|
| Define workflow steps and stages | workflow.configure |
| Assign step responsibility | workflow.assign |
| Approve workflow transitions | workflow.approve |
| Administrative override | workflow.override |
workflow.override is separately audited. Use of it should be rare and explicable.
Example
Tightening exception approval after an audit observation.
Observation: exceptions on critical systems were being approved at the same level as routine ones.
Change: a second binding was added so exceptions affecting critical systems use the six-eye template — draft, then risk review, then executive or CCO approval. Routine exceptions stayed on four-eye.
Checks run before the change:
| Check | Result |
|---|---|
| In flight | 7 exceptions mid-chain; all completed on four-eye as expected |
| Stage holders | Risk Manager role held by 2; CRO role held by 1 — single point of dependency noted and a deputy added |
| Segregation | Confirmed the CRO does not hold the Risk Manager role |
| Rationale recorded | Yes, referencing the audit observation |
Result over the following quarter:
| Chain | Decisions | Median days | First-time approval |
|---|---|---|---|
| Four-eye | 41 | 4 | 88% |
| Six-eye | 9 | 11 | 56% |
Nine decisions took a week longer each and four of them were sent back. Applying six-eye to all fifty would have added that week to every routine exception and produced pressure to route around the process.
Troubleshooting
"A decision is not appearing in anyone's queue." Its stage is bound to a role nobody holds, or the owner_department_head resolver cannot find the owner's unit.
"Changing a binding did not affect an in-flight approval." Correct. Runs complete on the template they started with.
"A six-eye chain is only involving two people." One person holds two stage roles. See Users & Roles.
"An approval did not update the business state." It was not the terminal stage. Intermediate approvals advance the stage only.