A SharePoint document approval workflow needs two separate decisions: who reviews the file, and what the system does with the result. Sending an approval request through Power Automate does not, by itself, prove that SharePoint content approval, document permissions and version controls are configured correctly.
This guide presents a design checklist for SharePoint Online. It helps a small team define a reliable process before building it. It is not a report of a live deployment, a legal sign-off mechanism or a guarantee that an approval record meets a particular regulatory requirement.
Choose the kind of approval you need
A one-off request asks a colleague for a decision. Native library content approval governs the approval state of an item under the library’s configured settings. A Power Automate process can route a request, collect the response and then perform a separate action such as setting content approval status.
Microsoft documents that integration in its SharePoint document approval guidance. Decide which outcome you require before choosing a template. An approved response is useful information, but it does not automatically grant a recipient access to a linked document.
| Requirement | Design question | Evidence to retain |
|---|---|---|
| One person’s review | Who is authorized to decide? | Reviewer identity, response and time |
| Several reviewers | Must everyone approve, or can one response decide? | Required reviewers and individual outcomes |
| Published library content | Does the process also set native content approval? | The final library approval state |
| A specific revision | What happens if the file changes during review? | File identity and the reviewed revision |
Define the request record before the flow
Use a stable request identifier and capture the document identifier, requester, assigned reviewer, submission time, decision, comments and final processing state. Add the document revision or another appropriate change marker to establish which content the decision concerned.
These are suggested process fields, not a claim that every template records them automatically. Keep a human-readable status alongside the technical run state. “Flow succeeded” can mean that actions executed; it does not necessarily mean a reviewer approved the document.
For a reusable field design, see our SharePoint document metadata schema. Keep custom workflow status separate from the native content approval status so employees can tell which value controls what.
A practical implementation sequence
- Create a safe pilot. Use a dedicated library and sample documents. Configure versioning, content approval and reader visibility to match the intended process.
- Select one trigger. Start with an explicit submission or a narrowly defined intake event. Avoid treating every file modification as a fresh request.
- Check the request state. Prevent a document that already has an active request from creating another identical review.
- Resolve the reviewer. Define where the approver comes from and what happens when that person is unavailable. Do not silently send a request to an empty field.
- Collect the response. Record approval and rejection separately, including comments needed by the author.
- Apply the outcome. If native content approval is required, use the corresponding SharePoint action and verify the resulting state.
- Notify the author. Include the decision, relevant comments and a document link they can actually open.
For the content approval action on files and pages, Microsoft’s SharePoint connector reference requires an ETag and identifies Get File Metadata as a way to obtain it. Make the revision check part of the design: fetching a current ETag is not evidence that the reviewer saw the current revision.
Handle edits, rejections and delays explicitly
If a document changes while approval is pending, the business must decide whether to cancel and resubmit, require another review, or prohibit edits through an appropriate controlled process. Do not assume that a pending request locks the underlying file in every configuration.
For rejection, return the file to a documented working state and preserve useful feedback. For an absent reviewer, define an escalation owner and deadline. A reminder and a reassignment are different events: the second changes who can decide and may need its own record.
For a retry after an automation failure, check whether the decision was already applied. Repeating an action without examining the state can produce duplicated notifications or misleading history. Keep the request identifier in the operational log so support can connect the document, approval and flow run.
Test more than the successful path
Run at least these cases: approval, rejection, no response, a reviewer without document access, an edit during review, duplicate submission and failure after the response has been recorded. Use a normal reader account to verify what is visible before and after the decision.
Measure completion against your own acceptance criteria. For example, an illustrative pilot might require that a rejected proposal never appears as released and that a second submission receives a new request identifier. Those are test expectations, not results we have observed.
Avoid rebuilding on retired workflow technology
For SharePoint Online, do not base a new procedure on old SharePoint Designer workflow screenshots. Microsoft states that SharePoint 2013 workflows were fully retired in Microsoft 365 on April 2, 2026; its modernization guidance points to supported replacements.
Check connector, environment and licensing requirements for the actual design rather than assuming every approval flow has the same entitlement. Finally, document the owner, backup owner and recovery procedure. Our version history versus backup guide explains why restoring document content is a separate concern from recording an approval.
