Requiring Fresh Approval After an Asset Request Changes
Test whether asset workflows invalidate approvals when important request details change, while retaining the original decision and a clear version history.
What should happen if an asset request changes after someone approves it?
Retain the original approved version and require renewed review when a material field changes under the organisation’s workflow rules. Show approvers exactly what changed and link their decision to that version. Do not allow an old approval to authorise a different destination, asset population or transaction without an explicit rule.
A manager approves a transfer of two laptops to a regional office. Someone then edits the request to include four laptops and a different destination, but the approval badge remains green. The system has preserved a status while losing the meaning of the decision. Acceptance testing should confirm that approval attaches to the details actually reviewed.
Define which changes affect the decision
List the fields that matter for each request type. A transfer may depend on asset identifiers, destination and receiving custodian; a disposal may also depend on route and quantity. Ask process owners which changes require renewed approval and which minor corrections can follow a recorded administrative route.
Avoid making every edit equally disruptive. Fixing a typographical error in a comment is different from substituting the asset being transferred. The rule should be explicit enough for the system and understandable to users. Record who can make changes at each stage and whether the request must be withdrawn before editing.
Link approval to a preserved version
Store the approved field values or a reconstructable version with the approver, decision time and outcome. When a relevant field changes, show the request as awaiting the required review and retain the previous decision in history. The earlier approval remains a true record of an earlier version; it should not disappear.
Present a concise change comparison to the next reviewer. Show added and removed assets, changed destinations and altered conditions. If several approvers are involved, define whose decisions must be renewed. A receiving manager may need to reapprove a destination change even if an unchanged budget assessment remains valid under the agreed process.
Test both the user interface and saved state
Use a test request to approve one version, change a material field and attempt completion. Check the request screen, notifications, export and underlying saved result exposed through supported tools. A warning on screen is insufficient if another supported route still completes the changed request using the old approval.
Also test an allowed minor correction and a rejected amendment. Verify that the history explains which version was executed. Record any gaps before rollout and agree a temporary control if the software cannot yet enforce the desired rule. This is a practical acceptance scenario, not an assertion about a particular product’s existing capabilities.
Practical Example
Illustrative example: request TR-204 is approved for laptops L-12 and L-13 going to Office East. An administrator changes the destination to Office North. The system preserves the first approval, marks the revised request for receiving-manager review and prevents completion until that decision is recorded. A later correction to a misspelled internal comment follows the separately defined minor-edit rule without obscuring either destination version.
Action Checklist
- 1.Identify the fields whose changes alter the substance of each approval decision.
- 2.Agree minor-edit exceptions with process owners before configuring the workflow.
- 3.Preserve the exact request version linked to each recorded approval.
- 4.Show reviewers a comparison of changed assets, destinations and conditions.
- 5.Test whether all supported completion routes respect renewed-approval requirements.
For approval workflows tied to the details actually reviewed, explore Asset Management Software.