Approval design is not a UI detail - it is the safety boundary that determines whether automation scales or becomes a liability.
Use these references as you implement:
The three buckets (keep them explicit)
1) Auto-execute (low risk, reversible)
Criteria:
- Reversible without money movement or contractual commitment
- Can be retried safely (idempotent or checkpointed)
- Has clear success/failure states and operator visibility
Examples:
- Draft generation (summaries, suggested fields)
- Queue routing (assignment and escalation)
- Non-committing notifications (with rate limits)
2) Approval-gated (money + commitments)
Criteria:
- Moves money, commits the company, or changes records that drive money
- Produces irreversible external side effects
- Changes permissions, vendors, or ledger-impacting structures
Examples:
- PO issuance and awards
- Payment runs and vendor payments
- Posting or finalizing accounting entries
3) Fail-closed (high uncertainty or missing prerequisites)
Criteria:
- Evidence is missing
- Confidence is low or the model flags an exception
- Preconditions are not met (permissions, required documents, parent record checks)
Behavior:
- Deny the action
- Log the reason
- Route to a review queue with evidence requirements
Evidence prerequisites: the real approval accelerator
The fastest approval workflow is not “approve faster.” It is “approve with the right evidence attached.”
Evidence-first design:
- Link documents to the action chain (invoice, PO, GRN, quote PDFs)
- Require prerequisites before approval is even requested
- Make exceptions explicit with reason codes and ownership
Make retries safe, or don’t automate
If you cannot rerun safely, approvals will not save you from duplicates.
Design principles:
- Use deterministic checkpoints
- Preserve audit history across reruns
- Never “fix by manual cleanup” as the primary recovery plan
Related: