The problem
If your document or budget approval workflow in SharePoint Online quietly stopped working, this is why. Microsoft retired SharePoint 2013 workflows from SharePoint Online on April 2, 2026. There was no extension. The old workflows no longer run. You can still open a definition, but it opens as raw XML, not a working process.
This already happened, so it’s cleanup, not a heads-up. The fix is to rebuild the workflow in Power Automate, the tool Microsoft points to as the successor.
What actually got retired (and what didn’t)
The retirement is real, but it’s narrower than the panic suggests.
- SharePoint Online: SP2013 workflows retired April 2, 2026. They no longer run. (SP2010 workflows in SharePoint Online were already retired back in 2020.)
- SharePoint Server on-premises (2016, 2019, Subscription Edition): still runs SP2013 workflows on the supported SharePoint Workflow Manager engine. On-prem did not lose workflows in April 2026.
There’s a second date, and it’s easy to conflate with the first. The SharePoint Designer 2013 application, the tool many people built these workflows in, reaches end of support on July 14, 2026 28days. That’s the app, not the SharePoint Online engine. Two separate things on two separate clocks.
How to see what you had
Once a workflow retires in SharePoint Online, you can’t easily read its logic from the UI anymore. And run history only sticks around for about 28 days, so the audit trail is thin.
Microsoft’s Microsoft 365 Assessment tool runs a “Workflow 2013” assessment and produces a Power BI report, with a Power Automate upgradability score for each workflow. One caveat: SharePoint Online has already retired the engine, so this is now mostly a post-mortem. It reconstructs what you had, and it’s still worth running if you have on-prem servers to plan for.
The rebuild: old SPD approval workflow → new Power Automate flow
This is the part that matters. A classic SharePoint Designer 2013 approval workflow on a document or budget-request library usually does the same handful of things:
- Starts when an item is created (or changed).
- Sends the item to an approver and waits.
- Branches on the outcome, approved or rejected.
- Updates a status column on the item.
- Emails the submitter the result.
Every one of those steps has a direct equivalent in a Power Automate automated cloud flow. Map it like this:
| Old SPD 2013 workflow step | New Power Automate step |
|---|---|
| Workflow starts on item creation | Trigger: When an item is created (SharePoint) |
| Send for approval, wait for response | Action: Start and wait for an approval |
| Branch on Approved / Rejected | Condition on the approval Outcome |
| Set the status column | Update item (SharePoint) |
| Notify the submitter | Send an email (Outlook) |
The rebuilt flow
The whole budget-approval rebuild as one Power Automate cloud flow: trigger, approval, a condition on the outcome, then the two outcome branches.
When the flow hits Start and wait for an approval, the approver gets an Approvals card right inside Outlook and Microsoft Teams. They click Approve or Reject without opening SharePoint at all. That beats the old pattern of an email link pointing back to the site.
What the approver sees
The approver responds straight from Outlook or Teams, no trip back to the SharePoint site.
One thing the old workflow gave you cheaply was a record of who approved what. Power Automate run history only holds about 28 days, so if you need a durable audit trail, add one step: a SharePoint log list the flow writes to after each decision (item, approver, outcome, date). That’s your permanent history, built on purpose instead of assumed.
The classic workflow waited for an approval. The new flow does the same thing. It just delivers the request as a card in Outlook instead of a link back to the site.
Licensing: the good news, then the gotcha
Everyone braces for the same thing: “rebuilding in Power Automate means buying Premium licenses for the whole company.”
For a like-for-like approval rebuild, that’s not true. The trigger and actions above (SharePoint, Outlook, Approvals, Teams) are all standard connectors, and base Microsoft 365 plans cover standard connectors: Business Basic, Standard, Premium, and E1/E3/E5. The people who only receive approval requests or submit items need no Power Automate license at all.
Premium is the gotcha. Power Automate Premium (about US$15/user/month; confirm current Canadian pricing before you quote it) only gets triggered by specific things. It kicks in if your flow uses:
- The generic HTTP action, custom connectors
- SQL Server, Dataverse, or an on-premises data gateway
- Child flows, or robotic process automation
A plain document or budget approval needs none of those. If your rebuild stays inside the standard connectors, your existing licensing carries it.
What doesn’t translate cleanly
Before you start, be honest with yourself: Power Automate is not a one-to-one copy of SPD workflows. A few things really do change.
01 Reusable workflows and site workflows
SPD 2013 let you build a reusable workflow once and attach it to many lists, or run a site-level workflow with no list at all. Power Automate flows are built per-trigger. You can copy a flow as a template, but there's no single definition shared across lists in the same way.
02 Impersonation / App Step
The SPD 'App Step' let a workflow act with elevated permissions. Power Automate handles identity differently: the flow runs as its connection owner, so any logic that relied on impersonation needs to be rethought, not pasted across.
03 Workflow history and a central status view
Flow run history is kept for about 28 days. There's no built-in central column showing every item's workflow status across a library. If you need either, build it: a log list for history, and a normal SharePoint status column the flow updates.
04 Long-running approvals
A single cloud flow run has a 30-day maximum. SPD workflows could sit waiting far longer. For approvals that may stall for weeks, design for it (reminders, escalation, or a re-trigger pattern) rather than assuming the flow waits forever.
None of these block a normal approval rebuild. They’re just the spots where “lift and shift” turns into “redesign,” so price them in.
Can you migrate instead of rebuilding?
Partly. The SharePoint Migration Tool (SPMT) can carry many list and library workflows across, and it flags the actions it can’t support. What it won’t bring over: site workflows and workflow run history. Treat SPMT as a head start. It hands you a draft plus a list of problems, not a finished flow. Whatever it produces, validate it by hand before anyone relies on it.
Bottom line
In SharePoint Online, the SP2013 workflow engine is already gone, so this is a fix, not a forecast. The rebuild itself is well-trodden: an automated cloud flow with a SharePoint trigger, Start and wait for an approval, a condition on the outcome, an update, and an email. A straight approval stays on standard connectors, so your current Microsoft 365 licensing covers it. The real work is the handful of things that don’t translate cleanly. Find those first and the rest is assembly.