EnterprisePatternsApproval flow

Approval flow

Structured multi-stage approval with explicit handoffs, state transitions, and traceability.

GovernanceWorkflowAudit

Overview

Approval flows require visible checkpoints: who approved, what changed, and why.

A strong flow balances speed with escalation, exception handling, and traceability.

Review a governed access request

Live preview

Add rationale, test guarded return and rejection decisions, approve the request, and inspect the resulting handoff and timeline.

GOVERNANCE QUEUE

Access approval

SLA: 3h 18m remaining
APR-2048

Production access exception

Temporary production access for the incident response window.

In review
Requested by
Asha Mehta · Platform operations
Current reviewer
Priya Shah · Finance Lead
Decision due
Context
High risk · 8 hours

Approval path

  1. RequestSubmitted by Asha
  2. ManagerApproved by Noah
  3. FinancePriya Shah
  4. SecurityNext reviewer

Policy checks

  • Manager approval
  • Automatic expiryAccess ends after 8 hours
  • Incident evidenceReview attachment INC-492
  • Security review
DECISION INPUT

Rationale

Required for reject and return decisions.

Decision timeline

3 updates
  1. Asha Mehta submitted APR-2048Requested 8 hours of temporary access.
  2. Noah Williams approved manager review Incident response coverage confirmed.
  3. Workflow assigned Finance review SLA due today at 5:00 PM.Unread

Anatomy

Use each piece in this order to keep interpretation and automation consistent.

APR-2048Access exceptionIn review
✓ Request● Finance→ Security
✓ Manager! Evidence
Timeline
12345
  1. 1
    Request card

    Summarizes decision context and proposed changes.

  2. 2
    Decision lane

    Tracks reviewer state and current owner.

  3. 3
    Policy check rail

    Shows required validations and blockers before action.

  4. 4
    Decision actions

    Approve, reject, or return with clear result states.

  5. 5
    Timeline

    Immutable activity log with actor and rationale.

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

  • Governed changes

    Use for anything that affects policy, budget, or risk.

  • Sequential approvals

    Use when each request has multiple approvers.

  • Cross-team handoff

    Use for handoffs that need owner and comment metadata.

When not to use

Avoid forcing this pattern where simpler, direct interactions are sufficient.

Avoid

  • Simple acknowledgements

    Use lightweight notifications instead of approval states.

  • Anonymous collaboration

    Avoid when actions are fully open and irreversible.

  • Single-click operations

    Keep flows minimal when no compliance state exists.

Variants

A small number of variants helps teams choose correctly without adding complexity.

Linear flow

Single reviewer path with explicit pass/fail checkpoints.

Parallel review

Concurrent reviewers with independent outcomes.

Escalation flow

Supports timeout and re-route to senior owner.

States

States communicate readiness, risk, and expected user behavior.

StateTriggerVisual responseInteraction
DraftSubmitted not yet routedEditable request summaryOwner can refine and resubmit.
PendingAwaiting reviewer inputPending badge and review queue indexReviewer receives contextual actions.
In reviewReview startedAction lock and active reviewer detailsSystem enforces one decision branch at a time.
FinalizedDecision madeImmutable decision summaryNo additional edits unless re-opened through policy.

Behavior

Behavior should remain predictable across devices, permissions, and async edges.

Alerting

Notify next responsible actor and show SLA hints.

Immutable timeline

Every decision writes a timestamped audit record.

Comment threading

Supports inline rationale and follow-up questions.

Accessibility

Keep interaction clarity high and ensure assistive technologies get the same meaning.

KeyAction
KFocus review comment input in some command-focused designs.
Ctrl/CmdEnterSubmit decision with required comment when required.
EscClose decision sheet without saving comments.
  • Expose decision outcome and required reason text programmatically in heading and status.
  • Pair icon-only decision states with visible text labels.
  • Use live region to announce stage transitions.

Content guidelines

Consistency is achieved by language standards, not by design only.

Decision clarity

Describe the action outcome in one sentence.

ExampleApprove payout for invoice #A-492

Rationale required

Ask for reason on exceptions and critical approvals.

ExampleException: expedited deployment needed

Ownership

Show owner and next actor at each step.

ExampleCurrent reviewer: Priya (Finance Lead)

Examples

Reference implementation style, payloads, and practical behavior.

Connect governed decisions

  • Attach request metadata as read-only fields to prevent tampering.
  • Log every transition to the audit stream before API commit.
  • Show timeout warnings near the next required action.
AccessApproval.tsx
tsx
const [rationale, setRationale] = useState('')
 
<ApprovalCard
requestId={request.id}
title={request.title}
status={request.status}
requester={request.requester.name}
currentApprover={request.currentReviewer.name}
stages={request.stages}
checks={request.policyChecks}
readOnly={!permissions.canDecide}
actions={
<>
<Button variant="outlined" onClick={() => decide('returned')}>Return</Button>
<Button variant="destructive" onClick={() => decide('rejected')}>Reject</Button>
<Button onClick={() => decide('approved')}>Approve</Button>
</>
}
/>
 
<Textarea
label="Reviewer rationale"
value={rationale}
onChange={(event) => setRationale(event.target.value)}
/>
Open linked component reference for implementation patterns

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

PropTypeDefaultDescription
requestApprovalRequestrequiredWorkflow data including lifecycle and actors.
decisionStatesDecisionStateConfig[]requiredDefines sequence and transitions.
onDecision(nextState: string, comment: string) => Promise<void>requiredPersist decision and rationale.
readOnlybooleanfalseLocks actions while still rendering timeline.