Test an approval workflow before you choose the software
When two functions must sign off, what happens if one approval is missing, someone exceeds their authority, or the approved proposal changes? Run these five cases in a vendor demo and record what actually happens.
Use your browser’s Print command to print a blank copy.
Agree the rule before the demonstration
Test the product, plan and configuration you would buy, with the permissions each participant would actually hold. Write your expected outcome before each attempt. Use a fresh proposal where stated so an earlier approval does not contaminate the next test.
A fictional supplier exception
Version 1 permits Supplier A to continue a critical service for eight weeks while a migration is prepared. The current spending cap and weekly risk reviews remain. Procurement accepts the commercial exception; Risk accepts the operating risk. Both must approve the same version before the exception takes effect.
The Delivery proposer has no approval authority. Procurement and Risk approvers can sign off but, under this example’s permissions, cannot author the proposal. A material change requires a new version and fresh approval from both functions. The delivery goal is service continuity; the linked work is a migration-readiness review before the exception ends.
This is an illustrative test policy, not a rule for every organisation. Adapt it before testing. Check the approval mode explicitly: a first response, all required responses and a rejection can lead to different outcomes. Microsoft’s approval-type documentation illustrates why the configured mode matters.
Run the cases and keep the evidence
Choose Demonstrated when the expected result and evidence were shown; Partial when only part was shown or a dependency remains; Failed when an observed result conflicts with the agreed rule; Untested when there is no reliable observation. Nothing is scored automatically.
1 · Positive control: both functions approve
Try: Use a fresh version 1. Have Procurement and Risk each approve that same version using their assigned roles. Then attempt to put the exception into effect.
Compare with the rule: Check that both required sign-offs cover version 1, that the approved wording is identifiable and that the permitted next action follows the agreed policy.
2 · Withheld sign-off, then rejection
Try: Use a fresh proposal. Procurement approves; Risk does not respond. Inspect the status and attempt the next action. Then have Risk reject it and inspect the result again.
Compare with the rule: Under this fictional rule, neither stage permits the exception. A request ending in rejection is not permission to proceed. Record whether the product distinguishes pending, rejected and approved outcomes.
3 · Authority and editing permissions
Try: Give each participant only the access the policy allows. First, have the Delivery proposer attempt to approve. Then have a Risk approver approve the relevant version and attempt to rewrite its wording.
Compare with the rule: Record the approval result and editing result separately, including which version each action affects. For this rule, Delivery cannot approve; Risk can sign off but cannot author the proposal. If approval needs extra editing rights, record whether that conflicts with the policy. Do not grant extra authority just to make the demonstration pass.
4 · Material change and reapproval
Try: Start from the version 1 approved in case 1. Propose extending the exception from eight to sixteen weeks as version 2. Obtain only Procurement’s new sign-off and attempt the next action. Then obtain Risk’s new sign-off and try again.
Compare with the rule: Check that version 1 and its evidence remain retrievable, that old sign-offs are not silently treated as approval of version 2, and that the new exception waits for both required approvals. Follow the link to migration work and record which commitments the Delivery owner needs to review; decision approval is separate from completing that work.
5 · A second reviewer retrieves the evidence
Try: Ask someone who did not run the demonstration to find the approved wording, required authority, actual sign-offs and version for each case, using only their intended review access. Give them the decision reference, not a narrated walkthrough.
Compare with the rule: Can they distinguish the approved eight-week exception, the proposed sixteen-week change, a missing response and a rejection? Record where they found the evidence and any help, access or export they needed. Confirm that the evidence identifies the version covered by each sign-off.
Use the result to decide what to check next
Review failed, partial and untested cases with the vendor. Separate a setting you can demonstrate now from a proposed configuration, future feature or manual step. Keep the evidence reference beside the observation. This records what the demonstration showed; it does not establish regulatory compliance.
Prepare the proposal with the decision record template. When assessing Traceway’s decision records and human approval workflow, use the same policy and cases and record only what you observe. The changed-decision example follows the strategy and delivery commitments that may need review.