SharePoint Document Approval Workflow: Build One That Lasts

The most common way a SharePoint document approval workflow dies has nothing to do with approvals. Someone in operations builds a Power Automate flow under their own account, it runs fine for two years, and then that person leaves or changes their password. The connections inside the flow stop authenticating, documents pile up in “pending,” and nobody in IT knew the flow existed until the complaints started.

We see this pattern in a large share of the environments we assess, and the fix is not complicated. It just has to be part of the build from day one. This post walks through the three ways to approve documents in SharePoint, when each one is enough, and how to build an approval flow that keeps running when the person who made it is gone.

If approvals are one piece of a bigger controlled-document problem, the SharePoint document management page covers the full system. This post stays on the approval step itself.

What Is a SharePoint Document Approval Workflow?

A SharePoint document approval workflow is the process that moves a file from draft to approved, records who approved it and when, and keeps unapproved versions from being treated as final. In SharePoint that can be done three ways: with the library’s built-in content approval setting, with the Approvals app in Microsoft Teams, or with a Power Automate flow. They differ in how much they automate, how much they record, and how much they depend on a single person.

The right choice depends on two questions. Does anyone outside the approver need to be notified or to see the audit trail? And does the process need to be repeatable across hundreds of documents, or is it a handful a month? The answers sort most organizations quickly.

Option 1: Library Content Approval

Content approval is a library setting. Turn it on, and new or edited documents sit in a “Pending” state, visible only to their author and to people with approve permissions, until an approver marks them approved. It’s the simplest option and the one most people don’t know exists.

What it does well: it stops draft documents from being visible to everyone, it records approval status per document, and it works with major and minor versioning so readers only see published major versions.

Where it falls short: nothing tells the approver a document is waiting. There’s no routing, no reminder, and no escalation. Approvers have to remember to check the library or set up an alert themselves. In our experience that’s where it fails. A document sits pending for three weeks because the approver never opened the view.

Use content approval when one team owns a library, the approver checks it as part of their routine, and you need the visibility control more than the notifications. It’s a good fit for a policy library where an owner reviews everything before it goes live, which is the setup we describe in managing policies and procedures in SharePoint.

Option 2: The Approvals App in Microsoft Teams

The Approvals app lets anyone send a document to a colleague for a yes or no decision inside Teams, with a record of the request and the response. It’s fast to use, requires no configuration, and works with a file attached from SharePoint or OneDrive.

Its limit is that it’s a request, not a workflow. The approval record lives in the Approvals app, not on the document. The file’s status in the library doesn’t change. Nothing prevents the document from being edited after it’s approved. If somebody asks six months later whether a version was approved, you’re searching one person’s Approvals history.

Use it for one-off decisions, such as getting a manager’s sign-off on a proposal before it goes to a client. Don’t use it as the system of record for documents that have to prove their approval status later.

Option 3: Power Automate Approval Flows

A Power Automate flow triggers when a document is added or changed, sends an approval request to the right people, waits for their response, and then updates the document’s metadata, moves the file, or notifies a group. It’s the only option of the three that routes, reminds, escalates and records in one place. It’s also the one that fails the way this post opened with.

Why approval flows die when their owner leaves

Every flow has an owner, and every connection inside it (to SharePoint, to Outlook, to Teams) is authenticated as a specific person. When that person’s account is disabled, the connections stop working and the flow starts failing. If the flow was built under the person’s own account with no co-owner, it becomes an orphaned flow that only an administrator can see, in the Power Platform admin center. Microsoft documents this in its guidance on orphaned flows, and the fix after the fact is an admin assigning a new co-owner and repairing each connection by hand.

A password change causes a milder version. Some connections keep working, others prompt for re-authentication that nobody sees, and the flow fails intermittently until someone opens it.

How to build an approval flow that survives turnover

• Run the flow under a dedicated service account, not a person. The account’s password gets managed by IT and it never leaves.
• Add at least two co-owners from the start, and make one of them an IT role rather than a person on the requesting team.
• Build the flow inside a solution, not as a standalone “My flow.” Solution-aware flows use connection references, which can be repointed to a new account without rebuilding the flow.
• Document who owns it and where it lives. A one-line entry in a flow inventory saves a week of forensics later, and our Power Automate best practices cover the naming and review standards that keep that inventory useful.
• Send approval requests to a group or a role, never to a named individual hard-coded in the flow. When the approver changes, you change the group, not the flow.

Treat the flow like any other system your business depends on. Most of the approval flows we find in trouble were never treated as systems. They were favors somebody did with a free tool. The wider version of this problem, and how to get flows out of the default environment, is covered in Power Platform governance.

Which Approval Method Should You Use?

Use content approval when a single owner reviews everything in one library and visibility control is the main goal. Use the Approvals app for one-off decisions that don’t need to live on the document. Use a Power Automate flow when approvals need routing, reminders or a record on the file itself, and build it under a service account with co-owners.