ComponentsEnterpriseApprovalCard

ApprovalCard

ApprovalCard creates a governed decision surface with explicit ownership, policy readiness, workflow stages, and durable outcomes.

GovernanceStagesPolicy checksRead-onlyLoading3 variants

Overview

Use ApprovalCard to give reviewers enough context to make and understand a governed decision.

Production access exception

Live preview

Try approving, rejecting, returning, and resetting the request.

APR-2048

Production access exception

Allow temporary production access for the incident response window.

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

Approval path

  1. RequestSubmitted 9:12 AM
  2. ManagerApproved by Noah
  3. FinancePriya Shah
  4. SecurityAfter Finance

Policy checks

  • Manager approval
  • Access windowExpires after 8 hours
  • Incident evidenceOne attachment needs review
  • Security review
AccessApproval.tsx
tsx
import { ApprovalCard, Button } from 'omverse-ui'
 
<ApprovalCard
requestId="APR-2048"
title="Production access exception"
description="Temporary access for an incident response window."
status="in-review"
requester="Asha Mehta"
currentApprover="Priya Shah · Finance Lead"
dueDate="Today, 5:00 PM"
stages={approvalStages}
checks={policyChecks}
actions={
<>
<Button variant="outlined">Return</Button>
<Button variant="destructive">Reject</Button>
<Button>Approve</Button>
</>
}
/>
 

Anatomy

Keep request context, ownership, readiness, decisions, and history in a stable reading order.

APR-2048Production access exceptionIn review
RequesterReviewerDue today
✓ Request● Finance→ Security
✓ Policy! Evidence
TimelineReturnApprove
12345
  1. 1
    Request context

    Identifies the request and summarizes the proposed change.

  2. 2
    Decision status

    Communicates the current lifecycle outcome in text and color.

  3. 3
    Stages and checks

    Makes handoffs, readiness, warnings, and blockers visible before action.

  4. 4
    Decision actions

    Presents only outcomes allowed for the current reviewer and state.

  5. 5
    Timeline

    Holds immutable actors, timestamps, transitions, and rationale.

When to use

Use for decisions that require ownership, policy validation, or an audit trail.

Recommended

  • Governed changes

    Review access, budget, compliance, deployment, or policy changes.

  • Multi-stage handoffs

    Show the current reviewer and the next accountable team.

  • Evidence-based decisions

    Expose required checks and missing evidence before actions.

When not to use

Prefer simpler surfaces when a durable decision model adds no value.

Avoid

  • Do not use for acknowledgements

    Use Alert or NotificationCenter when no decision is required.

  • Do not hide complex editing inside

    Use a form, SidePanel, or dedicated task before returning to the decision.

  • Do not bypass authorization

    The application must validate every decision on the server.

Variants

Surface treatments change emphasis without changing the approval contract.

Outlined

Default card in a page, queue, or detail view.

Filled

Groups a decision inside a tonal workspace.

Raised

Elevates a focused request above supporting content.

Sizes

Small, medium, and large adjust type density while preserving targets.

States

Lifecycle and interaction states must stay distinct and understandable.

StateTriggerVisual responseInteraction
DraftRequest is editableNeutral statusOwner can refine before routing
PendingWaiting for a reviewerPending status and next ownerDecision controls follow permissions
In reviewReviewer started workActive stage and policy checksOne decision branch at a time
Approved / rejectedDecision recordedDurable outcome and timelineRead-only unless policy permits reopening
ReturnedMore information requiredReturn status and rationaleRequester updates and resubmits
LoadingTransition is being recordedProgress statusDuplicate decisions are prevented

Behavior

ApprovalCard presents workflow state; applications own policy, persistence, notifications, and authorization.

Explicit handoff

Only one stage is current in a linear workflow.

Policy-aware actions

Blocked checks should prevent unsafe decisions upstream.

Immutable result

Final decisions preserve actor, time, rationale, and evidence.

Application notification

The application alerts the next actor after persistence succeeds.

Accessibility

Semantic regions, named status, native controls, and explicit ownership keep decisions understandable.

KeyAction
TabMoves through application-supplied decision controls.
EnterSpaceActivates the focused native action.
ShiftTabMoves backward without entering non-interactive stage content.
EscHandled by a containing dialog or SidePanel when present.
  • Use a specific request title as the card accessible name.
  • Keep lifecycle labels visible; do not rely on color.
  • Describe blockers and remediation in plain language.
  • Provide a machine-readable dueDateTime when due dates are shown.
  • Announce loading and status changes politely.
  • Move focus to a durable result summary after a modal decision flow.
  • Require confirmation for irreversible or regulated decisions.

Content guidelines

Decision language should state the object, consequence, owner, and required evidence.

Name the object

Use a specific request title rather than a generic task.

ExampleProduction access exception

State action outcomes

Use verbs that describe the resulting lifecycle state.

ExampleReturn for changes

Identify ownership

Show the accountable reviewer or group.

ExampleCurrent reviewer: Priya Shah

Explain blockers

Tell reviewers what is missing and how to resolve it.

ExampleAttach incident evidence before approval

Examples

Keep async persistence outside the card and lock decisions while a transition is running.

Finalized decision

Live preview

Read-only outcome with a durable timeline entry.

APR-1932

Approved payment exception

Approved · Final
Current reviewer
Finance operations
Decision due

Approved by Priya Shah · Today, 11:42 AM · Policy checks passed

This decision is read-only.
AsyncApproval.tsx
tsx
const [saving, setSaving] = useState(false)
 
<ApprovalCard
title={request.title}
status={request.status}
loading={saving}
loadingLabel="Recording approval decision"
readOnly={!permissions.canDecide}
actions={<Button onClick={() => decide('approved')}>Approve</Button>}
/>
 
async function decide(nextStatus: ApprovalStatus) {
setSaving(true)
await recordDecision({ requestId: request.id, nextStatus, rationale })
setSaving(false)
}

Props / API

ApprovalCard extends article attributes and keeps workflow data explicit through typed stages and checks.

Props

PropTypeDefaultDescription
titleReactNoderequiredDecision request title used as the card accessible name.
descriptionReactNodeundefinedConcise decision context or proposed change.
requestIdReactNodeundefinedHuman-readable request identifier.
statusApprovalStatus'pending'Current lifecycle state.
statusLabelReactNodegeneratedReplaces the generated lifecycle label.
requesterReactNodeundefinedPerson or system that initiated the request.
currentApproverReactNodeundefinedCurrent reviewer, group, or decision owner.
dueDateReactNodeundefinedVisible deadline or SLA value.
dueDateTimestringundefinedMachine-readable due date for the time element.
metadataReactNodeundefinedAdditional read-only request context.
stagesreadonly ApprovalStage[][]Ordered review and handoff stages.
checksreadonly ApprovalCheck[][]Required validations and their current results.
actionsReactNodeundefinedApplication-owned approve, reject, return, or escalation controls.
timelineReactNodeundefinedImmutable activity or rationale content.
readOnlybooleanfalsePrevents supplied decision controls from receiving input.
loadingbooleanfalseMarks a decision transition as in progress.
loadingLabelstring'Updating approval'Status announced during a transition.
variant'outlined' | 'filled' | 'raised''outlined'Controls surface emphasis.
size'sm' | 'md' | 'lg''md'Controls type density.