Overview
Approvals templates reduce rework by standardizing queue layout, decision controls, and evidence collection.
They also support auditability by coupling each decision with reason fields and history pointers.
Adapt an evidence-led decision workspace
Change queue scope, claim a recurring request, inspect the reviewer chain and evidence contract, then capture rationale before a governed decision.
Approvals
Review recurring requests with stable evidence, reviewer ownership, and decision integrity.
Production access exception
Requested by Asha Mehta · Security review
Manager sponsorship verified
Security training current
Access expires in 90 days
AMRequest submittedAsha Mehta · 42 minutes ago
PSPolicy evidence verifiedPolicy service · 39 minutes ago
Anatomy
Use each piece in this order to keep interpretation and automation consistent.
Required evidence
Immutable history
Decision rationale- 1Queue summary
Counts by stage and urgency.
- 2Approver list
Assigned roles and current reviewer context.
- 3Decision card
Item summary and action controls.
- 4Rationale field
Structured note with required details.
- 5History section
Immutable comments and state transitions.
The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.
When to use
Use this pattern when the user needs guided consistency, state, and reuse at scale.
Recommended
- Risk-sensitive systems
Use where governance is mandatory.
- Repetitive approvals
Use when teams review many similar request types.
- Cross-team handoffs
Use when approvals pass across functional roles.
When not to use
Avoid forcing this pattern where simpler, direct interactions are sufficient.
Avoid
- Automated decisions
Use alert templates for low-touch automation cases.
- Non-governed tasks
For purely operational actions, use quick actions.
- Single-user workflows
Use simple confirmation modals for one person decisions.
Variants
A small number of variants helps teams choose correctly without adding complexity.
Card queue
One decision card per request.
Compact list
High density mode for busy decision makers.
Guided flow
Step-by-step decision and evidence collection.
States
States communicate readiness, risk, and expected user behavior.
| State | Trigger | Visual response | Interaction |
|---|---|---|---|
| Awaiting | Waiting action | Unresolved decision cards | Assign reviewer and add notes. |
| Under review | Comment exists | Decision in progress | Allow updates and additional context. |
| Resolved | Action final | Final state and audit lock | Only comments or related references remain. |
Behavior
Behavior should remain predictable across devices, permissions, and async edges.
Decision integrity
Prevent duplicate decisions and track source request.
Rationale capture
Attach reason before commit.
Audit continuity
Preserve each attempt and final outcome.
Accessibility
Keep interaction clarity high and ensure assistive technologies get the same meaning.
| Key | Action |
|---|---|
| A | Approve focused item. |
| R | Return for revision with reason form focus. |
| Esc | Exit focused decision card. |
- Announce required rationale fields programmatically.
- Make critical and irreversible actions explicit through button labeling.
- Keep decision result and actor details visible for assistive users.
Content guidelines
Consistency is achieved by language standards, not by design only.
Decision phrase
Use direct decision verbs.
Approve deployment request
Reason field
Always include why this decision happened.
Budget approved after risk check.
Queue labels
Use stable priority labels.
High priority · Needs finance review
Examples
Reference implementation style, payloads, and practical behavior.
Production use
- Use templates for recurring request types with consistent required fields.
- Ensure audit details update in timeline as decisions are made.
- Bundle approval reminders and escalation in the queue summary.
Props / API
Use these API entries as a baseline contract and validate them against your domain layer.
These names are implementation-oriented and should map to your local contracts.
Props