# Your SharePoint approval workflow stopped on April 2, rebuild it in Power Automate > SharePoint 2013 approval workflows were retired from SharePoint Online on April 2, 2026. Here's the fast version: why it broke, and the step-by-step rebuild as a Power Automate flow. [Home](https://tenantcraft.ca/) [Insights](https://tenantcraft.ca/insights) Power Platform Plan May 16, 2026 6 min read Geri Crroj Microsoft 365 consultant, Niagara, Ontario ## 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. The 5-minute version If you read nothing else, do this: 1. **Confirm it’s stopped**, check whether items still route for approval in SharePoint Online. They won’t. 2. **Write down what the old workflow did**, trigger, who approves, what happens on approve vs. reject. 3. **Rebuild it as a Power Automate automated cloud flow**, trigger, _Start and wait for an approval_, a condition on the outcome, then update the item and send an email. Anatomy is below. 4. **Don’t panic about licensing**, a straight approval rebuild uses only standard connectors, so your base Microsoft 365 plan covers it. Approvers and submitters need no license. The rest of this post is the detail. ## 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, reached end of support on **July 14, 2026**. That’s the app, not the SharePoint Online engine. Two separate things on two separate clocks, and both clocks have now run out. One retirement, two dates April 2, 2026 = SP2013 workflows stopped running in SharePoint Online. July 14, 2026 = SharePoint Designer 2013 (the desktop app) went end of support. If someone tells you “workflows died in July,” they’ve merged the two, and on-prem isn’t on either clock. ## 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: 1. Starts when an item is created (or changed). 2. Sends the item to an approver and waits. 3. Branches on the outcome, approved or rejected. 4. Updates a status column on the item. 5. 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) | ![Diagram of the rebuilt budget approval flow in Power Automate: a SharePoint trigger when an item is created, Start and wait for an approval, a condition on the outcome, then Approved and Rejected branches that each update the item and email the requester](https://tenantcraft.ca/images/budget-approval-flow.png) 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. ![An Approvals card showing a budget request with amount, cost centre and item details, and Approve and Reject buttons](https://tenantcraft.ca/images/approvals-card.png) 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. Standard vs. premium · one easy trap The generic _HTTP_ action is premium. But _Send an HTTP request to SharePoint_ is a standard SharePoint action (a different thing, no premium needed). If your flow only talks to SharePoint, Outlook, Teams and Approvals, you’re on standard connectors. ## 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. Rebuilding an approval workflow? Walk through it with the playbook. SharePoint Workflow Rebuild Playbook PDF · 7 pages · 44 checkpoints [Email me the PDF](https://tenantcraft.ca/resources/guides/sp2013-workflow-rebuild-playbook) ## 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. TWENTY MINUTES, NO PITCH ## Tell me what is stuck. I will tell you what it takes. Same consultant from the first email to the last cutover. If I am not the right fit, I will refer you to someone who is. [Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing) --- _Canonical HTML: https://tenantcraft.ca/insights/sharepoint-workflow-rebuild-power-automate · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_