An approval belongs to the request that was reviewed

The approved checkbox is too small a data model

In this example, a manager approves a purchase by email. The requester later edits the amount, while the approved flag stays true. Purchasing now has a decision and a request, but no evidence that they refer to the same terms.

The proposal treats approval as a record: request_id, request_version, approver_id, decision, decided_at and policy_version. Keep the exact amount, currency, supplier and scope reviewed with that version.

Decide which changes matter

The policy owner defines material fields. In this example, changing supplier, currency, total amount or scope invalidates the old release approval. Correcting an internal reference may not, but the edit should still be recorded.

Do not hide policy decisions inside arithmetic. Thresholds need a currency basis, treatment of taxes and delivery costs, and a rule for related requests. The example doesn't prescribe a financial approval limit.

A reviewer sees the current request and its supporting evidence. Delegation has a start, end and scope; it is not permission for anyone with the notification link to approve.

Design the complete approval policy ↗

Prevent a stale click from becoming a purchase

An approval link carries a request reference, but authorization is checked when the reviewer opens and submits it. If the request version changed, show the updated request and require a fresh decision. The old click should not approve the new amount.

Immediately before issuing the purchase order, verify that the current version has the required decisions. Use a request-version release key to prevent a double click or retry from issuing another order.

The requester and approver roles should follow the organization's separation-of-duties policy. Enforcing a role check in the backend matters more than hiding a button.

Absence and API failure need different queues

An unavailable approver follows the agreed delegation or escalation policy. A purchase-order API outage keeps the request approved but unreleased. Conflating those states causes people to seek another approval when the actual problem is delivery.

If order creation times out, check by the external release reference before retrying. Record the destination ID once known. If the request changes while release is pending, hold it for purchasing review rather than racing the two operations.

The purchasing owner reviews aging requests, expired delegations and unreleased approvals. Policy changes should be versioned and tested against existing requests before rollout.

Keep the release permission narrow

The integration should be able to issue only the type of order this process needs. Reviewers shouldn't need broad purchasing-administrator access to make a decision. Record the human approver and the system actor separately so an order doesn't appear to have been approved by the service account that transmitted it.

A small pilot can expose the important failures

Rehearse an amount change after approval, an expired delegate, two simultaneous approval clicks and an unknown order-creation response. Confirm that the release record points to the exact approved version.

If an existing procurement product already enforces these rules, use it. The custom work is the boundary between systems that otherwise lose request identity or approval state.