← Back to Mobile app developers

Skill · Version 1.0.0

Business approval workflows

Models commercial approvals around the document actually reviewed, with thresholds and responsibilities that remain valid at execution.

approval-workflows

Team members using this skill

See how it helps

When is it useful?

Use it when discounts, order values or financial actions determine who must approve and whether a previous approval still applies.

What does it help you do?

  • Binds approval to the document revision and content hash.
  • Routes decisions by value thresholds, sequence and quorum.
  • Rechecks validity before execution and prevents self-approval.

Try asking this

Require fresh approval when an approved quote’s discount changes. Raise the discount after approval and attempt order creation. The old approval must be invalid, with a clear new review task for the changed quote.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Approval Workflows

When to Use

Use when implementing business or security approval flows—such as discount/quote approvals, purchase orders, refunds/payouts, role elevations, or sensitive production operations.

Core Principle: An Approval Is Bound to a Specific Version & Payload

An approval is never a blank check on a mutable record. If Sales Rep A gets approval for a 5% discount on Quote #104 and then edits Quote #104 to a 40% discount before converting it to an order, an unbound status = 'approved' flag allows fraud!

1. Payload Hash & Revision Binding

Every approval_requests and approval_decisions record must bind to the exact state of the subject:

  • Subject Version & Canonical Snapshot Hash:
    • Compute a deterministic digest (subject_version + payload_sha256 over the canonicalized approval-relevant fields: line items, unit prices, discount, currency, counterparty, terms).
    • Freeze the subject record against direct edits while status = 'pending_approval' or 'approved'.
    • Re-Approval Trigger Rule: If any material field covered by payload_sha256 is modified (or if the price/discount moves in a risk-increasing direction), automatically transition the record back to draft / pending_approval and mark prior approvals superseded.
2. Separation of Duties (SoD) & Conflict-of-Interest Rules

Enforce SoD invariants at the database/service boundary:

  1. No Self-Approval: decision.approver_id !== request.requester_id AND decision.approver_id !== resource.created_by_id AND decision.approver_id !== resource.owner_id (unless an explicit, documented single-owner workspace exception is configured).
  2. Distinct Multi-Approver Quorum (Four-Eyes / $M$-of-$N$): When a high-value threshold requires 2 approvals (e.g., Sales Director + Finance Controller), the same person holding both roles cannot sign off on both steps (COUNT(DISTINCT approver_id) >= required_approvers).
3. Tiered Thresholds & Sequential / Parallel Routing

Model threshold rules declaratively:

  • Tier 1 (discount <= 10% and total <= 10,000): Auto-approved (no_approval_required).
  • Tier 2 (discount <= 25% or total <= 50,000): Requires sales_manager of the rep's department.
  • Tier 3 (discount > 25% or total > 50,000): Sequential approval—Step 1: sales_manager, Step 2: finance_director.
4. Expiration & Execution Re-Verification
  • Attach an expires_at timestamp to approvals where business validity is time-sensitive (e.g., quote price lock or temporary payout sign-off).
  • At execution time (converting the approved quote to an order or disbursing funds), atomically verify in a single transaction that approval.status === 'approved', approval.payload_sha256 === currentPayloadHash(resource), and approval.expires_at > NOW().

Included files 1

  • SKILL.md