Data Mapping
Part of Human approvals in technical workflows
Handling changes to a record while approval is pending
Classify edits to a record under review, preserve the terms shown and prevent stale approval from authorising changed terms.
Tie an approval to the terms the person reviewed. If the business record changes while the request is open, decide whether the approval remains valid, must be superseded or needs an authorised review. Apply that rule before an accepted response can release the sensitive action.
Suppose a manager is reviewing an equipment purchase with a stated supplier and amount. Changing the supplier creates a different proposal. An internal note might leave the approval valid if the process owner has explicitly excluded that field from the decision.
Define which changes matter
List the fields the approver authorises, such as supplier, amount, item or destination account. Define how edits to each field are treated. Cancelling every request on any edit may disrupt routine updates; always using the latest values may let an old approval authorise new terms.
| Change while waiting | Suggested treatment |
|---|---|
| An approved term changes | Supersede the request and seek a decision on the new terms |
| An administrative field outside the decision changes | Keep the request open only if the exception is defined |
| The business record is cancelled or becomes ineligible | Close the request and block the action |
| Materiality cannot be determined | Hold for an authorised decision |
Preserve what was shown
When issuing an approval, retain the business record ID plus a version, ETag, immutable snapshot reference or selected material values that identify the reviewed terms. Keep a readable summary with that reference. A bare version number is weak evidence if the reviewed content cannot later be explained; a summary alone may be stale without a comparison rule.
When a decision arrives, read the current record. If the defined rule says the request is superseded, close it and issue a new request for the current proposal. Record which request replaced it. A delayed response to the old request should remain visible as history without authorising the new terms.
Preserving what was shown during approval
- Retain the business record ID, version, ETag, or immutable snapshot referenceEnsure the reviewed terms are traceable
- Store a readable summary of the reviewed contentInclude key fields such as supplier, amount, item, and destination account
- When a decision arrives, read the current recordCompare against the original snapshot to determine validity
- If the request is superseded, close it and issue a new oneRecord which request replaced it for audit purposes
- Delay in response? Keep the old request visible as historyDo not allow it to authorise new terms
Resolve the edit-and-approval race
A record can change after a workflow reads it but before the next action starts. Use a conditional source update or equivalent controlled decision point to claim the reviewed version. If that check fails, read the current record and reassess it instead of overwriting the new value.
Where the data store supports it, use a conditional version check to reject a stale write. DynamoDB documents conditional version updates that fail if another process has changed the item since it was read. These are store-specific conflict checks, not a transaction across the approval store and a separate purchasing or billing system.
If the final action reads details from another system, pass the approved values or revalidate material current values at that action boundary. A successful check on the approval record alone does not freeze the separate business record. If approval is accepted before an edit, define whether an already-started action may proceed or needs to stop; do not relabel the earlier decision as approval of edited terms.
Resolving the edit-and-approval race condition
- Use a conditional update or controlled decision pointVerify the record has not changed since the workflow read it
- If the conditional check fails, read the current recordReassess the approval based on updated values
- Leverage store-specific conflict checks (e.g., DynamoDB ETag)Reject stale writes that attempt to overwrite newer versions
- Validate material values at system boundariesPass approved values or revalidate when integrating with other systems
- Define whether already-started actions can proceedPrevent relabelling earlier approvals as authorising edited terms
