A document approval system should identify the version being reviewed, the people whose decisions are required and the evidence of the resulting outcome. Begin with the decision rule and the review subject. Then test what happens when a document changes during review, so a completed approval remains understandable to someone checking it later.
An approval request often contains a link to a document. The reviewer needs enough context to know what they are being asked to approve, and the document owner needs a record that connects the decision to that subject. Define the required evidence before configuring notifications. This keeps the workflow centred on a meaningful decision.
The original exercise here uses a hypothetical internal procedure with a draft amendment. Product examples come from Microsoft’s Power Automate approvals and SharePoint versioning documentation, read on 24 October 2026. See document management for the wider record-management decision and business systems for connected workflows.
Who must respond for a decision to be complete?
Power Automate lets an approval request identify its approvers and supporting information. Microsoft’s approvals introduction describes the information supplied through the Start and wait for an approval action. Begin by naming the decision: for example, whether a particular procedure amendment is ready for its intended audience.
Power Automate’s Everyone must approve option completes after all responses or a single rejection. Power Automate’s First to respond option completes when an approver approves or rejects. Those documented rules answer different business questions. Agree which rule matches the intended authority before deciding how many people receive the request.
Power Automate also supports custom responses that wait for all reviewers. Custom response wording can be useful when a decision needs more nuance than a simple approval. Define what each response permits and what follow-up it creates. A response labelled Needs clarification should have an understood owner and next action in the proposed process.
Power Automate supports sequential approvals requested in a specified order. If your procedure requires an initial content check before another person decides on release, describe that order in the requirement. Ask the demonstrator to show the chosen sequence and retain the observed result with the workflow configuration.
| Decision design | Question to settle | Evidence to retain |
|---|---|---|
| Review subject | Which document and version are being considered? | Subject identifier, version reference and review request |
| Reviewer rule | Is one response sufficient or must everyone respond? | Selected approval type and intended authority |
| Review order | Does one decision depend on another? | Agreed sequence and actual workflow settings |
| Rejection | What work should happen next? | Response, reason where needed and next owner |
| Changed document | Does the earlier decision still apply? | Changed subject and explicit disposition |
| Completion | Who can explain the decision later? | Decision record linked to its reviewed subject |
The table is an original decision-design sheet. Use it to describe the intended process, then add actual observations when demonstrating the configured system.
Which version is the reviewer deciding on?
SharePoint version history can show when a file changed and who changed it. The versioning guide describes version information that can help a document owner examine the review subject. Ask which version reference the approval record retains and whether a later investigator can locate the same content.
SharePoint can display a previous version without replacing the current version. This gives the demonstration a practical inspection case: show the version the reviewer considered, then compare it with the current file. The proposed approval design still needs to specify how those identities are connected; version history and approval responses should be assessed together.
SharePoint distinguishes major and minor document versions. Decide how those states correspond to drafting, review and release in your process. Write the expected document state beside the approval request. Keep the terminology consistent enough that a reviewer understands whether the content is a draft amendment or an instruction ready for wider use.
SharePoint allows configuration of who can see draft files. Confirm that the intended reviewers can access the subject before relying on a notification. A successful email delivery says less than an observed reviewer opening the correct version with their own account. Include that access step in the demonstration record.
How should changes during review be handled?
Choose a clear rule for a changed review subject. The document owner might decide that a substantive amendment requires another review request, while a separate clerical correction follows an explicitly agreed route. These are process choices to define with the responsible people. Record the chosen rule and ask the implementer how the proposed configuration supports it.
SharePoint warns that not every edit and save creates a new version. That qualification matters when designing evidence around frequent editing. Check the actual version captured by the intended editing method and avoid assuming that every individual keystroke creates a separately reviewable state. The acceptance record should refer to the versions actually available.
Prepare a changed-subject case deliberately. Give the reviewer a request for the sample procedure, then introduce a recognisable amendment in the test environment before the response is made. Record what the reviewer opens and what the eventual decision references. Compare that outcome with the agreed rule, and retain any mismatch as an implementation question.
Original reviewer-and-version binding exercise
Create the fictional procedure Request Review with an initial instruction and a draft amendment. Give the exercise a document identifier, a visible version reference and a short explanation of the decision needed. Use a separate test library and test flow, with invented content and designated test recipients.
First, run the agreed normal route. Ask the reviewer to identify the version they are considering and the response options available. After the response, inspect the decision record and locate the reviewed content. Write the observed identifiers and outcome beside the expected result. This establishes a baseline for the exception cases.
Next, demonstrate a rejection and inspect the next step. The document owner should be able to find the response, identify the work required and determine who owns it. If the workflow ends without the proposed next action, record that distinction so the remaining scope is clear.
Then run the changed-subject case. Retain the version before the request, the version opened by the reviewer and the version associated with the eventual decision. Ask the document owner whether that evidence supports the intended outcome. Where a new review is required, record who may initiate it and how the earlier request should be interpreted.
Finally, repeat the access check using an intended reviewer account and an ordinary reader account. Compare their views with the proposed audience rules. Keep the workflow’s response logic and the library’s visibility settings together in the evidence sheet, since each contributes to whether the review is usable.
Use the completed exercise to agree the reviewer rule, subject reference and changed-document treatment. For implementation beyond the approval step, see web development. To discuss the particular document and decision boundaries, get started with the evidence sheet and remaining questions.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.