Your farm patched clean. Every workflow on the 2010 engine is now off — by design.— The Reveille Bugle · Quick Answer
Quick answer: the September 2026 cumulative update for SharePoint Server Subscription Edition (KB5002908) disables the SharePoint 2010 workflow engine by default on every site collection — existing ones included. Approvals stall, items sit in “In Progress,” and Nintex for SharePoint on-premises workflows stop outright. The fix is one PowerShell cmdlet per site collection, below. Nothing is lost; the engine is switched off, not removed.
Why this one hurts
Nothing fails loudly. The CU installs clean, the farm reports healthy, and the workflows simply never start. Most teams find out from the business, days later.
01 — The Symptom
What you’re seeing
Any of these, starting the day the September CU landed.
- SharePoint 2010-era workflows won’t start — manually or on item creation — anywhere in a site collection.
- Nintex for SharePoint (on-premises) workflows stop functioning farm-wide.
- Workflows that do start hang in “In Progress” and never create tasks.
- Workflows with InfoPath task forms throw “The specified form template could not be found.”
- After the October 2026 CU: SharePoint 2013-platform workflows stop starting the same way. See section 04.
None of this is corruption, and none of it is your build. Microsoft is retiring the legacy workflow engines for security reasons, and September was the 2010 engine’s date. (Workflow health is one of the things Reveille checks continuously on SharePoint — the full test list is published here.)
02 — The Causes
Four causes, ranked by likelihood
Start at the top. The first one accounts for most of this month’s tickets.
| # | Cause | How to confirm |
|---|---|---|
| 1 | The 2010 workflow engine is disabled by design. KB5002908 turns it off on all site collections, new and existing. | Run Get-SPLegacyWorkflowEnabledSites. If the affected site collection isn’t listed, this is your cause. |
| 2 | The bulk re-enable missed site collections. Teams that prepared often enabled only the “known” workflow sites. | Same cmdlet — diff its output against everywhere workflows actually run, including archived and departmental sites. |
| 3 | InfoPath task forms. The September CU also blocks InfoPath browser rendering (“InfoPath is deprecated”), so 2010 workflows with InfoPath forms fail even where the engine is on. | Error says “The specified form template could not be found.” Reported on the September CU thread; no supported re-enable. |
| 4 | PSConfig wasn’t run everywhere. The CU requires the Products Configuration Wizard on each farm server; a skipped server leaves the farm half-upgraded. | Check upgrade status in Central Administration; look for servers still pending. |
03 — The Fix
Re-enable the engine where the business needs it
One cmdlet per site collection, in the SharePoint Management Shell.
Three things worth knowing. First, the cmdlets ship from the August 2026 CU onward, so farms that patched August can run them before installing September — that’s the clean path if you haven’t patched yet. Second, Nintex published an action-required notice with a bulk script that enables the engine across every site collection hosting Nintex Workflow, so you don’t hand-walk hundreds of URLs. Third, there is no supported fix for the InfoPath form rendering block — treat cause #3 as your forcing function to rebuild those workflows, because re-enabling buys time, not a future.
Microsoft’s rationale is attack surface: the 2010 engine is unsupported code paths in a farm that regulators assume is patched. Every site collection you re-enable is a deliberate, documented exception — keep the list.
04 — Next Month
SharePoint 2013 workflows stopped after the October 2026 update
The October CU is out. The same switch is now flipped for the SharePoint 2013 engine.
September was not a one-off. Per Microsoft’s announcement, the October 2026 CU for Subscription Edition disables SharePoint 2013 workflows by default on every site collection, the same way September did for 2010. It ships bundled with the 26H2 feature update. If your 2013-era approvals stopped the day October landed, this is why. Check with Get-SPWorkflow2013EnabledSites, re-enable per site collection with Enable-SPWorkflow2013, and decide for each one whether the answer is an exception or a migration. SharePoint 2013 workflows stay supported on SharePoint Workflow Manager; disabled by default is not retired. (If you’re still on SharePoint 2016 or 2019: the August 2026 CU was your last update ever — your farms are now unsupported, which is its own problem.)
The structural lesson is that this failure was invisible to infrastructure monitoring. Servers up, services green, CPU flat — and every approval in the company stopped. The signal that mattered was at the content layer — the layer Content Observability watches: did a workflow actually start, run, and create its task? That is the check a patch window needs before the business finds out for you.
Reveille for Microsoft 365
Reveille runs over 95 out-of-the-box M365-specific tests — including SharePoint Timer Job status, Windows Event Log checks, current health warnings and errors, and synthetic site transactions that create, check out, retrieve, check in, and delete a document on a schedule. Run those before and after a CU and a silently disabled workflow engine shows up in minutes, not in next week’s escalation. See Reveille for Microsoft 365 →
Before the next CU
See the 95+ SharePoint and M365 tests run against a live tenant.
Enter a business email and the platform you run. The demo environment opens with the SharePoint Timer Job, Event Log, and synthetic site-transaction tests already configured.
No credit card · Nothing to install · Runs on Reveille’s sample estate. Want the list first? Read the Microsoft technical overview.
Quick answers
