Approval workflows: thresholds, categories and parallel approvals

Build rules that make authority clear and keep requests stable while they are being reviewed.

Define authority before drawing the workflow

An approval process should answer who may authorize a purchase and what each reviewer checks. Start with that policy rather than a diagram of names. A manager may confirm the business need, a category owner may check a specification, and a financial reviewer may check the amount. Make each responsibility clear so approvals do not become repeated checks with no distinct purpose.

Use actual request examples to test the policy. Include routine purchases, category exceptions, high-value requests and mixed requests. Ask what should happen when the requester is also an approver or when an approver is unavailable. Those are ordinary operating conditions. Resolve them during configuration rather than leaving the first live request to discover an undefined path.

Combine ordered levels with clear thresholds

Ordered approval levels define the sequence. A later level starts after the required work in the earlier level is complete. Amount thresholds determine which review is required under the policy. Define the amount basis, currency handling and treatment of changes. A request should not move through different rules because two screens calculate its amount differently.

Test the boundaries around each threshold. Check a request below, at and above the configured value. Also test an edit that changes the amount before submission and an edit during review. Decide when a changed request needs renewed approval. Keep the policy and the system behavior aligned so users cannot bypass review by splitting or modifying a request in a way the policy did not intend.

Give category rules explicit precedence

A category-specific approval block can take precedence over a general block inside the same level. That lets a specialist review apply where it is needed without duplicating every general rule. Define the precedence clearly and test it with mixed categories. The reviewer should be able to see why a specific block applied and which general rule it replaced.

Poor category data makes this policy unreliable. Assign an owner for the category mapping and a process for uncertain lines. Free-text items still need classification before category rules can work as intended. Do not silently place unknown items in a harmless category to complete the flow. Give buyers a clear way to resolve ambiguity and retain the reason for the classification where it affects approval.

Distinguish parallel approvals from groups

Parallel approvals within a level mean that all required branches must approve before the request advances. An approver group is different: one active member can close the group's step. Choose the structure based on the policy. Two reviewers with separate responsibilities may need parallel approval. A pool of people with the same authority may suit a group.

Make these semantics visible to administrators and users. Test what happens when one branch rejects and when a group member becomes inactive. Name an owner for maintaining group membership. Without that ownership, a technically valid workflow can stop because nobody available holds the step. Avoid solving that by granting broad authority to everyone. Use the delegation and membership rules agreed for the process.

Freeze the submitted rules and audit edits

Freeze the rule set as a snapshot when a request is submitted. Later configuration changes should not silently alter a request already in flight. This lets a reviewer explain why a particular approval path applied at that time. Decide how deliberate migration of an open request would be handled and authorized if it is ever needed.

Keep buyer edits visible with a field-level diff. Reviewers need to know whether the amount, supplier, category or purpose changed after their decision. Before go-live, confirm behavior when no approval rules exist: a workflow with no rules can approve everything. That is a configuration risk to resolve, not a reason to rely on users noticing it. Run a pilot and inspect the rule snapshot and edit history alongside the visible approval path.

Checklist

Define each reviewer's authority and responsibility.
Test threshold boundaries and amount changes.
Document category precedence and mixed-category behavior.
Distinguish all-required parallel steps from one-member groups.
Maintain active approver membership.
Freeze rules at submission and retain field-level edits.
Verify that an empty rule set cannot surprise the team at go-live.