On July 23, 2026, a bug in Microsoft's automated network maintenance system removed IP routes from more devices than intended in Azure's West US region, and one of the services that went down for close to five hours was Power Automate. If your Docusign Workflow Builder runs get triggered by a Power Automate flow, that trigger path went dark too, and nothing in the outage notice told you which of your workflows failed to fire.

This matters because a lot of RevOps and HR ops teams use Power Automate's own "Start Docusign Workflow Builder workflow" action as the glue between a CRM or ATS event and a Workflow Builder run. That glue is convenient to set up. It is also a dependency on Azure infrastructure that has nothing to do with Docusign, and when that infrastructure goes down, your trigger path goes down with it, silently.

What happened in the July 23, 2026 Microsoft 365 outage? #

Microsoft opened the incident (tracked as MO1437424) after a bug in its automated network maintenance request system removed IP routes from more devices than intended while performing routine maintenance in its West US Azure region. The bad route removal severed network traffic entering and leaving that region, which cascaded into Microsoft 365 services that depend on it.

Microsoft's preliminary post-incident review describes the trigger as routine device maintenance that required isolating specific network paths. The isolation step went wrong, and the blast radius extended well past the devices that were supposed to be touched.

Which Power Automate features actually failed during the outage? #

Microsoft's own status list for the incident named Power Automate directly. Alongside Teams, SharePoint, OneDrive, and Copilot Chat, Microsoft listed Power Automate flows as failing to load for the duration of the incident. The Microsoft 365 admin center itself was also loading slowly or not at all, which is the console most teams would have used to check on flow health in the first place.

That combination is the trap. The layer you would normally check (the admin center) was degraded at the same time as the layer doing the work (Power Automate), so a team relying on Power Automate to trigger Docusign wouldn't get a clean signal that anything had gone wrong. Flows either didn't fire, or the platform running them wasn't reachable to report status either way.

This was not the first time a Power Automate connector issue has quietly broken a Docusign trigger. Docusign's own community forum has a recurring thread of Power Automate connector outages where Microsoft confirmed a widespread issue was "impacting many connectors, including those built by third parties other than Docusign." The July 23 outage is a large, dated example of a failure mode that has happened before and will happen again.

How does a Power Automate outage break a Docusign Workflow Builder trigger? #

Docusign publishes an official Power Automate action for exactly this pattern. Docusign's own developer blog walks through it: a Power Automate flow watches for an event (a Dataverse row change, a SharePoint update, an HTTP trigger) and then calls the "Start Docusign Workflow Builder workflow" action to kick off a Workflow Builder run, passing along the fields the workflow needs.

That means the trigger chain looks like this:

Source event (CRM update, HTTP call, Dataverse row change)
        v
Power Automate flow evaluates trigger conditions
        v
Power Automate calls "Start Docusign Workflow Builder workflow"
        v
Docusign Workflow Builder starts a run and creates the envelope(s)

Every one of those middle steps runs on Power Automate's infrastructure, which sits on Azure. If Azure networking in the region hosting your tenant goes down, as it did on July 23, the flow itself may not execute, and even if it queues, it has nothing to report back to your CRM or ATS about the miss. Docusign's side of the chain never gets called, so there's no failed envelope, no failure log entry, no webhook bounce. There's just a workflow that should have started and didn't.

What is the blast radius when your trigger path depends on one vendor's infrastructure? #

The honest answer is: every workflow that has a Power Automate flow anywhere upstream of it. That includes flows most teams don't think of as "the integration," like a scheduled flow that batches contract renewals, or an approval flow that only calls Workflow Builder after a manager clicks approve inside Teams (which was also degraded during the outage).

The risk compounds because the failure is silent by design, not because anyone built it badly. Power Automate has no obligation to notify Docusign of a flow it couldn't run, and Docusign has no way to know a trigger it never received was supposed to arrive. The single point of failure isn't Docusign's platform or your CRM. It's the automation layer standing between them, and on July 23 that layer's own vendor confirmed it went down for close to five hours.

If you're new to why this dependency chain exists at all, our complete guide to document workflow automation covers how these trigger chains typically get built, and where the fragile links usually sit.

How do you detect a Docusign workflow that silently failed to trigger? #

Start by reconciling the source event against the Workflow Builder run list, not the other way around. If your CRM shows 40 deals moved to "contract sent" between 10:44 AM and 3:41 PM ET on July 23, but your Workflow Builder run history shows fewer than 40 runs starting in that window, the gap is your missed triggers. This only works if you're already logging the source events somewhere durable, which is a habit worth building before the next outage, not after.

Second, check whether the payload that should have reached Workflow Builder ever left the source system. Our piece on seeing the exact payload that triggered a Workflow Builder run explains what a healthy trigger payload looks like end to end, which makes it faster to spot the runs that are simply missing rather than malformed.

Third, once you've confirmed a gap, don't rebuild the records manually. If the underlying data is still correct in the source system, look at whether you can replay the failed Workflow Builder runs instead of re-keying them, which preserves your audit trail.

What can you do today to reduce this single point of failure? #

You don't have to rip out Power Automate everywhere. The fix is to stop routing your Docusign trigger path through infrastructure that has no reason to be involved in "webhook comes in, Workflow Builder run starts."

That's the specific job Baton does. Baton is a webhook relay that sits between your source platform and Docusign Workflow Builder directly: your CRM, ATS, or procurement tool fires a webhook, Baton verifies the signature, matches the payload to the workflow's parameters, and starts the run. There's no Power Automate flow in the middle, and no dependency on the Azure region that had the bad maintenance job on July 23. Baton's Command Center gives you a run-by-run log, so instead of reconciling deal counts against run counts by hand, you can see directly which triggers came in and which workflows they started.

If you're wiring this up for the first time, start with the general primer on what a webhook relay actually is and why Docusign needs one, and our Docusign API integration guide for the mechanics of calling Workflow Builder directly. If your trigger path still runs through Power Automate for good reasons (you need a Teams approval step, a Dataverse write, or another Microsoft-only capability upstream), keep that step, but move the last hop, the one that actually calls Workflow Builder, onto infrastructure that doesn't share a fate with Azure's West US networking.

If you want a broader view of where Docusign IAM trigger paths tend to break beyond this one incident, the Docusign IAM resources library and fluidlabs cover the platform side of that question in more depth.

FAQ: what should you check first after an upstream automation outage? #

What caused the July 23, 2026 Microsoft 365 outage? A bug in Microsoft's automated network maintenance request system removed IP routes from more devices than intended in Azure's West US region during routine maintenance, cutting network traffic to that region for close to five hours.

Was Power Automate actually affected, or just Teams and SharePoint? Power Automate was on Microsoft's own published list of affected services for this incident: flows failed to load for the duration of the outage, alongside the Microsoft 365 admin center and Copilot Chat.

How do I check if my Docusign Workflow Builder triggers were affected by an outage like this? Reconcile source-system events against your Workflow Builder run history for the outage window. If the counts don't match, the difference is your missed triggers. Checking the automation layer's own logs alone isn't reliable here, since that layer was the thing that went down.

Does Docusign Workflow Builder retry a trigger automatically after an outage on the Power Automate side? No. If Power Automate never calls the "Start Docusign Workflow Builder workflow" action, Docusign's side of the chain never receives a request to retry. The retry has to happen upstream of Docusign, which is why the trigger layer's own reliability matters as much as Docusign's.

What should I check first after any upstream automation outage, not just this one? Check whether the layer that calls Docusign Workflow Builder was itself degraded, separately from checking Docusign's own status page. A clean Docusign status page doesn't rule out a missed trigger if the call to start the workflow never left the automation platform in between.

Is Baton affected by a Power Automate or Azure outage? Baton triggers Docusign Workflow Builder workflows directly from source-platform webhooks and does not route through Power Automate, so an outage in Power Automate or the Azure region behind it does not affect Baton's ability to receive a webhook and start a run.