Cloud 9 Creative

Move SharePoint approval workflows to Power Automate before April 2026

by | Oct 3, 2026 | AI

Colleagues reviewing SharePoint approval decision

Use modern Configure Approvals together with Power Automate for almost every new sharepoint approval workflow you build today, and reserve classic content approval (moderation) for scenarios with a strict legal or compliance need for version-gated visibility. The immediate next step is simple: open the library you care about and either turn on Approvals from the Automate menu or create a flow from the Power Automate approval templates.

TL;DR:

  • Modern Configure Approvals supports parallel workflows, auto-approval, and Teams integration, but has no native bulk approval feature.
  • Classic content approval links to versioning and offers an auditable state, suitable for strict compliance needs without external dependencies.
  • Using both approval models on one library causes metadata conflicts; only enable both if you carefully map each features’ approval state updates.
  • Approval flows must re-fetch file metadata before each content approval status update to prevent status resets caused by stale ETags.
  • Migrating legacy SharePoint workflows to Power Automate is urgent before the 2026 retirement, requiring careful planning and testing in non-production environments.
Cloud9
Simplify Your Workflow Migration
Cloud9 helps established businesses replace fragmented digital systems with integrated cloud services, workflow automation, and ongoing support.

Explore Cloud9 solutions

Table of Contents

Overview: the two approval models and when to pick each

SharePoint gives you two genuinely different ways to gate content: the modern “Configure Approvals” experience and the older content approval feature built around major and minor versioning. They solve overlapping problems but store their state differently, and mixing them without understanding that difference causes most of the conflicting-status bugs people hit in practice.

Modern Configure Approvals sits on top of Power Automate and ties into Microsoft Teams. When someone requests approval on a file or list item, the request lands in the Teams Approvals app, where approvers can accept or reject without opening SharePoint. These requests are stored in Dataverse, and the Approvals app provisions that environment the first time it is used, which matters for how you plan licensing and rollout. Microsoft itself recommends Power Automate for custom page approval flows specifically because it supports parallel approvals, auto-approval rules and other logic that the built-in experience cannot express.

Classic content approval works differently. It changes a list item’s ModerationStatus property and controls whether a document is visible to readers as a published major version or hidden as a pending draft. It is older, blunter, and tightly coupled to versioning settings, but it still has a place: anywhere you need a built-in, auditable “this version was approved, that one was not” state without external dependencies.

A short decision checklist helps most teams choose quickly:

  • Need Teams integration, flexible routing or parallel sign-off: choose modern Configure Approvals with Power Automate.
  • Need a hard compliance record tied to document versioning with no external app: classic content approval is still appropriate.
  • Expect to import or approve items in bulk: plan around classic moderation temporarily, because modern Approvals has no native bulk action.
  • Need both visibility control and a Teams-based request: build carefully, since running both models on one library risks conflicting metadata.

Avoid enabling both “Configure Approvals” and “require content approval” on the same library unless you have mapped exactly how each writes its state, because the two features use different metadata and can create conflicting approval states.

Quick prerequisites and permissions to check before you build an approval workflow

Most failed approval setups trace back to a handful of missed prerequisites rather than anything wrong with the flow logic itself.

  • Confirm your tenant has Power Automate available and that a Dataverse environment can be provisioned, since the Approvals app creates one on first use.
  • Check that the person configuring flows or page approvals has site owner or SharePoint admin rights; standard contributors cannot create or edit approval flows.
  • Review library versioning settings before enabling classic content approval, because approval state depends on major/minor version tracking being switched on.
  • Add approvers through a Microsoft 365 group rather than a local SharePoint group wherever possible.

That last point is worth dwelling on. Microsoft’s own guidance on managing site access flags that approvers added through ad hoc local groups often end up unable to view the very item they are being asked to approve, which produces confusing “access denied” errors at the worst possible moment: mid approval cycle.

Teams Approvals templates can host up to 400 approval templates per team, which is generous for most organisations but worth knowing before you design dozens of near-identical flows instead of a handful of parameterised ones.

Turn on modern approvals on a list or library and request an approval

Enabling Approvals on a document library takes a few minutes once you know where Microsoft has put the controls.

  1. Open the library, select Automate from the command bar, then choose Configure Approvals.
  2. Toggle the feature on and set your default approvers, choosing whether the flow requires a response from everyone or accepts the first response it gets.
  3. Save the configuration. SharePoint creates the underlying flow and the request path through Teams automatically.
  4. To request approval on a specific item, select the file, open the context menu, and choose Request approval.
  5. Add or confirm approvers for that specific request, include a short message if useful, and submit.
  6. Watch the status pill on the item: it moves from “Pending” through to “Approved” or “Rejected” as approvers respond in Teams or SharePoint.

The approver behaviour choice matters more than it looks. “Require a response from all approvers” suits anything where every sign-off genuinely matters, such as a shared policy document. “First to respond” suits time-sensitive approvals where any one authorised person’s decision is enough, such as routine purchase requests.

Pro Tip: Name your default approver group clearly (for example “Finance Approvers L1”) rather than listing individuals, so you only have to update membership in one place when staff change roles.

Configure page approvals using the page approval flow

Page approvals work through the same Power Automate foundation but live under the Pages library rather than a document library, and site owners configure them slightly differently.

  1. Go to Site Pages, select Automate, then Power Automate, then Configure page approval flow.
  2. Choose whether you want a simple built-in flow or want to build a custom one from a blank template.
  3. Supply the approvers who should review pages before they go live, and save.
  4. Open the generated flow in Power Automate if you need to adjust logic, such as adding a condition that auto-approves pages edited by a specific manager group.
  5. Test by editing a page and submitting it for approval, confirming the request appears correctly in Teams.

Page approval flows are still ordinary cloud flows once created, which means site owners can open and edit them directly in Power Automate. The caveat is that only the specific triggers and actions already wired into the Pages library template are supported for that library type, so swapping in unrelated triggers can break the connection between the page and the approval request.

A common pattern worth copying: keep one flow for standard pages that simply routes to a content lead, and a separate flow for news pages that routes to both a content lead and a communications approver in parallel, since news content usually carries more reputational risk than an internal update page.

Build a custom approval flow in Power Automate for SharePoint

Once you move past the built-in toggles, most organisations end up building a bespoke flow, and the pattern that works reliably is consistent across scenarios.

Start with a trigger. Use When an item is created or modified for list-based approvals, or When a file is created (properties only) for document libraries where you only care about new uploads. Immediately after the trigger, add Get file properties or Get file metadata, because this step captures the item’s current ETag, and that ETag becomes important later if you are working with classic content approval.

The core of the flow is Start and wait for an approval, Power Automate’s standard action for modelling sign-off. It supports several approval types directly:

  • A single approver for simple, low-risk requests.
  • Everyone must approve, for parallel sign-off where every named approver has to agree.
  • The first to respond, for parallel sign-off where any one decision closes the request.
  • A sequential pattern, built by chaining two “Start and wait for an approval” actions one after another, where the second only fires once the first resolves as approved.

What happens after the approval resolves depends entirely on which model you are working with. If you are using classic content approval, the next action is Set content approval status, and this is where the ETag you captured earlier becomes essential: Microsoft’s own troubleshooting guidance confirms that flows which skip passing the ETag, or call Set content approval status without first retrieving file metadata, can fail outright or trigger unexpected status resets. If you are working with modern Approvals and have no classic moderation in play, skip “Set content approval status” entirely and instead update your own tracking columns (an “Approval Stage” choice column, for example), since modern Approvals manages its own internal state separately from ModerationStatus.

A sequential, two-level approval (Level 1 manager, then Level 2 director) is a good illustration of where people go wrong. The naive build runs “Start and wait for approval” for the manager, then immediately updates the item (setting “Stage = Manager Approved”), then runs a second “Start and wait for approval” for the director, then updates the item again. Each update changes the item’s version, which changes its ETag, and if content approval is also switched on, that second update can silently reset the approval status back to pending because the flow is working from a stale ETag captured before the first update ran. The fix is to re-run Get file metadata immediately before any action that writes to content approval status, every single time, rather than relying on an ETag captured near the start of the flow.

Sequential approval stages with version conflict

Pro Tip: Log each approval decision, approver name and timestamp to a separate tracking list rather than relying solely on the item’s own history, so you have a clean audit trail even if the item itself gets deleted or heavily edited later.

Monitor, adjust, cancel and report on approvals

Once approvals are running in production, the operational questions shift from “how do I build this” to “how do I see what is happening and fix it when something stalls.”

  • Check approval status and history directly on the item in SharePoint, or open the Approvals app in Teams for a consolidated view across every request a person owns or has sent.
  • Expect a running approval request to auto-cancel if the underlying item is edited significantly while the request is still pending; re-trigger a fresh request rather than trying to resume a cancelled one.
  • Reassign a stuck approval by opening the request in Teams and delegating it, or by cancelling the flow run in Power Automate and starting a new one with a corrected approver list.
  • Pull detailed audit trails from Microsoft Purview audit logs for compliance reporting, since item-level history in SharePoint itself is useful but not built for formal audit exports.
  • Remember that modern Approvals data lives in Dataverse, so any reporting that needs to join approval history with other business data should query Dataverse directly rather than scraping SharePoint lists.

Reassigning approvers is the most common manual intervention teams end up performing, usually because the original approver is on leave. Building a simple “reassign” step into your governance documentation, rather than leaving it to ad hoc Teams messages, saves a surprising amount of back and forth.

Known limitations and painful edge cases

A handful of limitations catch almost everyone the first time they try to scale an approval workflow beyond a handful of documents.

The biggest one: modern Approvals has no native way to approve items in bulk. Microsoft’s own community guidance confirms there is currently [no bulk-approve option for Teams-based modern Approvals](https://learn.microsoft.com/en-gb/answers/questions/5645049/bulk-approve-files-in-sharepoint-(with-new-teams-b), and the practical workarounds are either scripting against the Graph API to approve requests programmatically, or temporarily switching the library to classic moderation for the duration of a bulk import.

A pragmatic approach to mass importing pre-approved documents is to temporarily enable classic moderation, mark items as approved through scripted updates, and then return the library to its desired settings, testing the whole sequence in a non-production tenant first.

That workaround carries its own risk, which brings in the ETag problem again: any metadata update made by a script or flow after content approval is set can reset the status if the correct ETag is not supplied with the update. The safer pattern uses the REST API’s ValidateUpdateListItem method, or explicitly passes the correct ETag to Set content approval status, to avoid an unintended reset back to pending.

A few other edge cases worth planning around:

  • Running both approval models on one library at once routes metadata through two independent systems, which makes debugging status problems considerably harder.
  • Elevated permissions are usually required for the account or service principal running bulk scripts, so plan access review alongside any migration.
  • Testing in a non-production tenant before touching live documents is not optional once bulk scripting or classic-moderation toggling is involved, given how easily an incorrect ETag can cascade into mass status resets.

Migrating from classic SharePoint workflows to Power Automate approvals

If you are still running SharePoint 2010 or 2013 workflows, migration is no longer optional. Microsoft has set a retirement timeline running through April 2026 for SharePoint 2013 workflows, and the recommended replacement path is Power Automate.

  1. Inventory every live workflow across your sites, noting which lists or libraries they run on and roughly how often they trigger.
  2. Rank workflows by business impact, prioritising anything tied to finance, contracts or compliance for early conversion.
  3. Pilot the conversion on one low-risk workflow first, rebuilding it in Power Automate using the approval patterns covered earlier.
  4. Validate the new flow against real scenarios, including rejection paths and reassignment, not just the happy path where everyone approves immediately.
  5. Retire the old workflow only once the new flow has run successfully across a full business cycle, then repeat the process for the next workflow on your priority list.

Teams planning a broader move away from legacy file shares or older workflow platforms at the same time may find it useful to treat this as part of a wider migration project rather than a standalone fix; our five-phase SharePoint migration playbook covers the sequencing in more detail.

Cloud 9 practical checklist and short playbook for implementing approvals

Years of fixing other people’s half-finished SharePoint rollouts tend to produce the same short list of things worth checking before you commit to a design.

  • Confirm roles clearly: who can edit flows, who can approve, and who owns the governance documentation.
  • Choose your environment deliberately, deciding upfront whether Dataverse provisioning and Teams integration suit your tenant’s current setup.
  • Run a pilot on one library or one page type before rolling the pattern out tenant-wide.
  • Plan a rollback path, including how you would revert to classic moderation if a flow fails in production.
  • Keep an audit trail from day one, rather than retrofitting one once compliance asks for it.

In practice, the libraries that go smoothly are the ones piloted on page approvals first, since pages are lower risk than contracts or finance documents, before extending the same flow pattern to document libraries that need the ETag-aware patterns described earlier for classic content approval.

Pro Tip: Test your bulk import strategy, ETag handling included, in a non-production tenant before you touch a single live document library.

Cloud 9 covers this kind of work as part of its Microsoft 365 support service, alongside broader Systems, Finance & Workflow Integration engagements for businesses that want the whole stack managed rather than pieced together internally.

When to choose a managed service versus building in-house

Building approval workflows in-house works well when requirements are simple: a single approver, one library, no bulk import. The calculation changes once you are dealing with sequential multi-level approval, scheduled bulk imports, or a genuine audit requirement, because that is where the ETag handling, Dataverse provisioning and permission design described above start to compound.

A managed supplier earns its fee by delivering a documented policy for who approves what, flows that are built to survive staff turnover rather than tied to one person’s tenant knowledge, ongoing monitoring so stalled approvals get caught quickly, and an audit trail that satisfies whoever asks for it later.

Before deciding, ask honestly: does anyone on the team understand ETag behaviour well enough to debug a silent status reset at 5pm on a Friday? Has the bulk import workaround actually been tested outside production? Is there a single named owner for the approval flows, or does the knowledge live in one person’s head?

If those questions expose gaps, that is the signal to bring in outside help rather than discovering the gap mid-migration.

— Rob

Cloud 9 managed Microsoft 365 and workflow automation services

A managed service can replace the patchwork of half-documented flows and tribal knowledge that most SharePoint approval setups end up with, bringing policy, build and ongoing monitoring under one managed service rather than leaving it split across whoever last touched the tenant.

Cloud9

Our approach runs in three stages: pilot a single approval pattern against a real library or page type, build out the full set of flows once the pilot proves stable, then run and monitor them as part of an ongoing support retainer.

  • Microsoft 365 support covering the governance and permissions work that approval flows depend on.
  • Managed cloud services that keep Dataverse, Power Automate and Teams integration working together rather than drifting apart.
  • Systems, Finance & Workflow Integration for organisations that want approvals connected to finance or CRM systems rather than sitting in isolation.

The outcome is fewer stalled approvals, a tested bulk-import path instead of a risky one-off script, and an audit trail someone other than the original builder can actually follow. If that sounds like what your organisation needs, see our managed cloud services page for how an engagement starts.

Authoritative Microsoft documentation and admin resources

For exact configuration steps, keep these references close by while you build.

If a flow or approval behaves unexpectedly outside the patterns covered here, raise a ticket through your Microsoft 365 admin centre before assuming the flow itself is at fault, since a surprising number of approval failures trace back to licensing or permission changes made elsewhere in the tenant.

Sources

FAQ

How do I configure approvals in SharePoint?

Open the library, select Automate, then Configure Approvals, and set your default approvers and response rule. For a specific item, use Request approval from the file’s context menu, which is the same path covered in the step-by-step section above.

How do I create an approval workflow from scratch?

Build an automated cloud flow in Power Automate triggered on item creation or modification, then add Start and wait for an approval to handle the sign-off itself. This pattern supports single, parallel and sequential approvals without needing any custom code.

What are the three types of SharePoint workflows?

Definitions vary across sources, but the practical distinction that matters today is between modern Configure Approvals, classic content approval (moderation), and fully custom Power Automate flows built independently of either built-in feature. Legacy SharePoint 2010 and 2013 workflows also still exist in some tenants but are being retired.

What is the difference between a workflow and an approval process?

A workflow is the broader automation, covering any sequence of automated steps triggered by an event in SharePoint. An approval process is a specific type of workflow focused on getting a yes or no decision from one or more people before an item or page is considered final.

Can I bulk approve multiple files at once in SharePoint?

Modern Teams-based Approvals has no native bulk-approve option, so bulk approval typically requires scripting against the Graph API or temporarily switching the library to classic moderation for the import. Test either approach in a non-production tenant before running it against live documents.