“It worked yesterday”: why Power Automate flows break, and why they die when their author leaves

The scenario: HR onboarding flow that slowly dies

Imagine a typical HR onboarding flow:

• Trigger: When an item is created in a SharePoint list OnboardingRequests
• Actions:
  • Create an entry in Dataverse
  • Send approvals to manager and IT
  • Create accounts and add licenses
  • Post a message to a Teams channel

It’s owned by one HR analyst using their work account. It runs fine for months.

Then:

• The analyst leaves.
• Their account is disabled and later deleted from Entra ID.
• The flow starts failing on every run.
• Power Automate detects repeated failures and eventually turns the flow off.

Everyone else sees: “It worked yesterday.” Behind that sentence are a few specific mechanics that matter a lot for production flows.

Why flows break: the main technical causes

There are many ways to break a flow, but a handful account for most “worked yesterday” incidents.

1. Owner’s account or connections are gone

In our HR scenario, the original author:

• Created the flow in My flows (personal scope)
• Used their own connections for:
  • SharePoint
  • Dataverse
  • Outlook / Teams

When their Entra ID account is disabled or removed:

• Their user-bound connections become invalid
• Any action using those connections starts returning errors (typically auth/401/403-type errors)
• The flow keeps triggering, but almost every run fails

Key points:

• A cloud flow always runs under a connection. If that connection is tied to a user that no longer exists, the flow does not magically switch to a new account.
• Even if the flow is shared with other users, the owner and their connections matter unless you’ve explicitly changed them.

2. Trigger conditions or schema changes

Flows that depend on schema stability are vulnerable to “worked yesterday” problems:

• SharePoint list columns renamed or deleted
• Dataverse table columns changed from single line of text to lookup
• JSON payload shape changed in custom APIs

If your trigger or actions reference fields that no longer exist or changed type:

• Expressions like triggerBody()?['Department'] start failing
• Dynamic content tokens resolve to empty or error

This often shows up as:

• Flow triggers fine
• First or second action fails with “item not found”, “property does not exist” or type conversion errors

3. Environment, plan, or license changes

Power Automate behaviour is affected by:

• Environment type (Default vs. other environments)
• Capacity and limits (API calls, concurrency, service protection limits)
• License changes (per-user vs. per-flow vs. seeded licenses)

Typical breakage patterns:

• Flows moved between environments without updating:
  • Connections
  • Dataverse table references
  • Custom connectors
• Flows that suddenly hit API limits due to increased volume

These usually don’t disable the flow immediately, but they do cause repeated failures that can eventually lead to the flow being turned off.

4. External service changes

Flows that call external services are brittle when:

• API endpoints change
• Authentication method changes (e.g., basic auth removed, OAuth required)
• Permissions tightened on SharePoint sites, Teams, or mailboxes

Again, the pattern is the same: the flow continues to trigger, but actions start failing consistently.

What repeated failures and automatic turn-off really mean

Power Automate monitors flow health. When a flow repeatedly fails, the platform can change how it runs and eventually turn it off.

Two behaviours matter here:

1. Degraded behaviour under service protection limits:

   • When a flow has a high error rate or hits service protection limits, the platform may:
     • Reduce its effective throughput
     • Limit retries
     • Prioritise healthier flows
   • You see more delays and backlog, especially for high-volume triggers.

2. Automatic turn-off after repeated failures:

   • If a flow fails for a sustained period, Power Automate will turn the flow off.
   • The exact thresholds are not published and can vary by connector and trigger, but the pattern is:
     • High failure rate detected
     • Flow marked as unhealthy
     • Flow turned off to protect the system and avoid useless retries

In our HR scenario:

• The owner leaves
• Their connections fail on every run
• The flow keeps triggering on new onboarding items
• Every run fails for days
• The system eventually turns the flow off

From the team’s perspective, it “worked yesterday” and now nothing happens. From the platform’s perspective, it just stopped running a flow that has been unhealthy and failing repeatedly.

How to recognise a flow that’s dying

For flows that are already in trouble, there are a few reliable signals.

1. Run history pattern

Open the flow and check Run history:

• Look for:
  • Many consecutive failures
  • Identical error messages across runs
  • Increasing delays between trigger and run start

In the HR flow example, you’d see:

• Status: Failed for almost every run
• Error details: authentication or permission errors on actions using the departed user’s connections

2. Trigger health and analytics

Use the Analytics tab for the flow:

• Check:
  • Error rate over time
  • Average duration
  • Distribution of success vs. failure

This tells you whether the flow has a systemic problem or just occasional edge-case failures.

3. Flow turned off automatically

When Power Automate turns a flow off:

• The flow’s status is turned off
• The owner and admins may get notifications (depending on settings)

For a critical business flow, any unexpected “off” state should trigger investigation.

Governance patterns that prevent “author leaves, flow dies”

You can’t stop people leaving, but you can stop flows from dying with them.

1. Use service accounts or application identities for critical flows

For flows that:

• Run business-critical processes
• Need to survive staff changes

Prefer:

• A dedicated service account (shared mailbox / generic user) with:
  • Clearly defined permissions
  • Managed lifecycle (not auto-disabled when someone leaves)

Or, where appropriate:

• Application identities via Entra ID app registrations + custom connectors / HTTP with managed identity (for premium scenarios)

Rules of thumb:

• All connections in the flow that must stay alive should be based on the service account or app identity
• The service account must be:
  • Licensed appropriately for Power Automate
  • Excluded from standard HR disable/delete processes

2. Move critical flows out of “My flows”

Flows in My flows are tightly coupled to the individual user.

For team or organisational processes, prefer:

• Solution-aware flows in a dedicated environment
• Owned and managed by:
  • A team (e.g., HR IT) rather than one person
  • Admins with environment-level visibility

Benefits:

• Easier to transfer ownership
• Better ALM (solutions, source control, deployment pipelines)
• Admins can see and manage all critical flows centrally

3. Explicit ownership and documentation

For each critical flow, maintain:

• Business owner: accountable for the process
• Technical owner(s): people who can fix and update the flow
• Runbook with:
  • What the flow does
  • Trigger details
  • Key dependencies (lists, tables, APIs, accounts)
  • How to rotate connections if a user leaves

Store this where the whole team can access it (SharePoint, Confluence, etc.), not in someone’s personal notes.

4. Monitoring and alerts

Set up monitoring so you don’t discover dead flows by accident.

Options:

• Power Automate notifications:
  • Ensure owners receive email alerts on failures and turn-off events
• Power Platform admin centre:
  • Use analytics to identify flows with rising error rates
• Custom monitoring flows:
  • A separate flow that checks the status of critical flows via the Power Platform admin connectors

This is where Power Automate can monitor itself: one flow watches others and alerts when they go unhealthy or off.

Fixing the HR onboarding flow: a concrete path

Back to our HR scenario. The flow is off, the owner left, onboarding is stuck.

Here’s a pragmatic recovery path.

Step 1: Confirm what broke

1. Open the flow in Power Automate.
2. Check Run history for the last successful run and first failed run.
3. Review error messages:
   • Look for auth/permission errors
   • Identify which connector(s) are failing

If the owner’s account is gone, you’ll typically see errors like:

• “The user does not have permission to perform this action.”
• “The requested resource is not available.”

Step 2: Create or confirm the service account

Work with IT to ensure:

• There is a service account (e.g., hr-automation@company) with:
  • Access to the SharePoint list
  • Access to Dataverse tables
  • Permission to send mails / post to Teams
• It has the required Power Automate license

Step 3: Rebind the connections

For each connector used by the flow:

1. Go to Data > Connections.
2. Create new connections using the service account.
3. Open the flow and switch actions to use the new connections.

Be systematic:

• SharePoint actions (Get item, Create item, Update item)
• Dataverse actions
• Outlook / Teams actions

Step 4: Transfer ownership and move to solutions if needed

If the flow is still in My flows under the departed user, you may need admin help to:

• Export the flow (if possible)
• Recreate it under a team owner in a solution-aware context

For new builds and major refactors:

• Create a solution in the appropriate environment
• Add the flow there
• Share it with the right owners and admins

Step 5: Add simple health checks

Even without complex monitoring, you can add basic health checks.

Example: a separate flow that runs daily and checks whether there were any failed runs for the onboarding flow in the last 24 hours, then sends an email to HR IT if failures are detected.

You can implement this using:

• Power Platform admin connectors
• A scheduled cloud flow

The key is: don’t rely on someone noticing a missing email. Monitor the flow explicitly.

Designing flows that fail safely

You can’t avoid all errors, but you can decide how they behave when things go wrong.

1. Use scoped error handling

For complex flows, wrap risky sections in Scope actions and configure run-after settings:

• Group external API calls in a scope
• If the scope fails, run a fallback scope that:
  • Logs the error
  • Notifies the owner
  • Marks the item as “error” in the source system

This avoids silent failures and gives you a trail.

2. Don’t ignore repeated failures

If your flow is failing repeatedly:

• Fix the cause quickly
• Or temporarily turn the flow off while you investigate

Letting it fail for days is what pushes it into the automatic turn-off path.

3. Be explicit about dependencies

In the flow description and documentation, list:

• Trigger source (list, table, queue)
• External systems called
• Accounts and identities used

This makes it much easier to diagnose “worked yesterday” problems when something changes.

One practical takeaway

Treat every business-critical flow as infrastructure, not a personal tool. Give it a stable identity (service account or app), put it in a managed environment with shared ownership, and monitor its health. That’s what stops “it worked yesterday” from turning into “we only noticed it died two weeks ago when Power Automate quietly turned it off.”