Appearance
Approvals Hub
Where to find it: Work & Decisions, then Approvals Hub (/approvals).
The Approvals Hub is the decision centre: every governed decision awaiting action, across every module, in one view.
Workbench or Approvals Hub?
They overlap deliberately, and they answer different questions.
| Workbench | Approvals Hub | |
|---|---|---|
| Question | What is waiting for me to do? | What decisions are outstanding? |
| Scope | All your work — reviews, own work, attestations, offers | Governed decisions |
| Audience | Everyone | Approvers and governance functions |
| Organised by | Bucket, by what kind of obligation it is | Decision, by what needs deciding |
An approver typically lives in the Approvals Hub. Everyone else lives in the Workbench.
What appears
Governed decisions from across the platform:
| Module | Decisions |
|---|---|
| Compliance | Obligation submissions, requirement demonstrations, compliance validation |
| Applicability | Applicability decision approvals |
| Controls | Mapping approvals, assessment reviews, design adequacy reviews, expected evidence acceptance |
| Risk | Risk acceptance, exception approvals, action plan approvals and verifications |
| Policy | Publication approvals |
| Audit | Plan approvals, engagement sign-off |
| Inspections | Response package sign-off |
| Resilience | BIA, plan and exercise sign-off |
| Incidents | Closure review |
| Third-party | Engagement decisions |
Each item shows what is being decided, who submitted it, when, and a deep link to the record.
Segregation is applied before you see it
Decisions you are not permitted to make do not appear.
- Your own submissions are excluded from your queue.
- Decisions whose stage is bound to a role you do not hold are excluded.
You cannot see an approval you would be blocked from making. This avoids the common frustration of a queue full of items that error on click.
Working an approval queue
Read what is being asked. A mapping approval, a policy publication and an incident closure are different decisions requiring different scrutiny. The hub shows what kind each is.
Open the record. The hub shows enough to triage. It does not show enough to decide. Every item deep-links to the record.
Return rather than reject where the work is salvageable. A return with a specific comment gets the right outcome. A rejection restarts the chain.
Write the reason. The reason is read by the submitter now and by an auditor later. "Rejected" is not a reason.
Watch the age. An approval open for two weeks is blocking a person, and often a chain of people behind them.
A chain that never returns anything is not a control
If your approval queue has a 100% first-time approval rate, either your submitters are exceptional or the review is a formality. The policy publication example shows what a good return looks like — it caught a materiality threshold error that would have propagated into an entire reassessment programme.
Escalation
Some chains support escalation from a review stage to an executive or committee stage. Where available, escalation is a distinct action from approval and rejection, and it moves the decision up rather than concluding it.
Requires work.escalate or the escalation transition on the stage.
Permissions
| Action | Permission |
|---|---|
| View work and decisions | work.read |
| Approve a workflow transition | workflow.approve, plus the stage's role binding |
| Administrative workflow override | workflow.override |
| Module-specific approvals | The relevant module permission — mapping.review, exception.approve, risk.accept, policy stage roles, and so on |
Example
A Chief Risk Officer's Approvals Hub.
| Item | Type | Submitted | Age |
|---|---|---|---|
EXC-2026-0031 MFA exception, legacy trading platform | Exception approval | IT Security Ops Manager | 6 days |
RSK-2026-0022 acceptance, legacy settlement platform | Risk acceptance | Head of Operations | 2 days |
ENG-2026-0041 core hosting | Engagement decision | Technology Sourcing Analyst | 4 days |
INC-2026-0014 closure | Incident closure review | Head of Payments Operations | 1 day |
BIA-2026-0003 Retail Payments | BIA approval | Head of Payments Operations | 9 days |
What is not in the queue: three risk acceptances the CRO's own team submitted where the CRO is named as the requester, and two mapping approvals bound to the Compliance Manager role.
The nine-day BIA is the one to worry about. It is blocking the continuity plan approval behind it, which is blocking the exercise schedule behind that. A single stalled approval near the front of a chain delays everything downstream of it, and the age column is the only signal that shows it.
Troubleshooting
"An approval I expected is not in my queue." Either you submitted it, or the stage is bound to a role you do not hold.
"I can see it but cannot approve it." This should not happen — segregation is applied before display. If it does, check whether you hold the module permission as well as the stage role.
"Approving did not change the business state." In a multi-stage chain, intermediate approvals advance the stage. Only the terminal stage updates the business state.
"I need to approve something I submitted." Segregation of duties blocks this. Where your governance model genuinely requires a break-glass path, see Segregation of Duties.