Excel file locked by Power Automate: the six-minute connector lock

Your flow adds or updates rows with the Excel Online (Business) connector. A later step then tries to delete or overwrite the same workbook, and fails because the file is locked. Microsoft documents the reason in the connector's reference: an Excel file may be locked for an update or delete for up to 6 minutes since the connector was last used on it. Microsoft lists it as a known limitation, and the lock clears by itself within that time. This guide shows how to plan a Power Automate flow around that lock, and the other limits on the same page that make a workbook look locked when it isn't.

What are you seeing?

• Delete or replace fails A step after the Excel actions can't change the fileWait more than six minutes first.
• Fails while someone edits The flow and a person, or another flow, write at onceOnly one writer at a time is supported.
• 502 BadGateway The workbook is read-onlyTurn off read-only mode.
• New versions Version history grows though the flow only readsMicrosoft says this is by design.

What Microsoft documents

The connector's reference lists the lock under its general known issues and limitations. In our words: after the connector last used a workbook, the file can stay locked against an update or a delete for up to 6 minutes.

What the page doesn't say matters too:

• It doesn't list which actions count as an update or delete of the file.
• It doesn't give the status code or the message you'll see. Open the failed action in the run history and read its outputs, which include the status code and the error body (Azure Logic Apps' error handling page shows the shape of a failed action's result).
• "Up to" means the lock can clear sooner. Six minutes is the longest Microsoft mentions.

Two pages from Microsoft Graph help you read the outputs. The connector works with files in libraries that Microsoft Graph supports, such as OneDrive for Business and SharePoint. Graph's list of error responses defines 423 Locked as a resource that's locked. Graph's error handling page for Excel describes an accessConflict code for a request that conflicts with another client, for example one that has locked the workbook for editing, and says not to resend that request until the conflict is resolved. Learn doesn't say which of these a flow gets from this lock, so treat them as clues, not as the connector's documented behaviour.

1. Step 1The flow's Excel actions use the workbook
2. Step 2The file may stay locked for up to 6 minutes
3. Step 3A delete or replace inside that window can fail
4. Step 4A delay of more than six minutes waits it out
5. Step 5The same step after the wait can work on the file

Fix 1: wait before you delete or replace the file

When a flow reads or writes rows and then deletes or overwrites the workbook, give the lock time to clear between the two:

1. Find the flow's last Excel Online (Business) action.
2. Add a Delay action straight after it, before the step that deletes or overwrites the file. Microsoft's page on wait conditions describes adding a fixed delay before the next step.
3. Set the delay to more than six minutes, for example 7 minutes. Six minutes is Microsoft's figure; the extra minute is our margin, not Microsoft's.
4. Save the flow, run it, and check that the file step now succeeds.

The window starts again each time the connector uses the file. So group all the Excel actions first, then the delay, then the file step. A delay inside a loop that still writes to the workbook doesn't help.

A wait of a few minutes is well inside Power Automate's limit for one run, which Learn gives as 30 days.

Fix 2: retry the step that failed

Actions that support it have a retry policy. Power Automate's limits page gives the defaults, which depend on the flow's performance profile:

You can change the policy in the action's settings, up to 90 attempts, with delays from 5 seconds to 1 day.

The catch is which failures the policy retries. The page that Power Automate's limits page links to for retry policies, Azure Logic Apps' error handling page, says a retry is sent when the request times out or fails with a 408, 429 or 5xx response. It names no other codes, so don't count on the policy for a failure with any other code.

So check the failed action's status code first:

• 408, 429 or a 5xx code: a fixed-interval retry policy can cover it. Set the interval to more than six minutes, written as an ISO 8601 duration such as PT7M.
• Any other code: build the retry yourself. After the failed step, add a Delay of more than six minutes that runs only when that step has failed, then the same step again. Microsoft's error handling guidance for Power Automate covers the run-after settings that let a step run after a failure. This pattern is our design, built on those settings; test it with a copy of the file.

Fix 3: one writer at a time

The connector's reference is clear: it doesn't support the file being changed at the same time by other connectors or by hand. Microsoft says not to write to one workbook from several clients at once, naming Excel desktop, Excel for the web, Power Automate, Logic Apps and Power Apps, because that can cause merge conflicts and inconsistent data.

In practice, this means:

• Don't edit a workbook in Excel while a flow is writing to it.
• Don't point two flows, or a flow and an app, at the same file to write.
• Check the flow for parallel writes. Power Automate's limits page says a flow's concurrent runs are unlimited while Concurrency Control is off, which is the default, so several runs can write to the same file at once. Turning it on in the trigger's settings limits runs to between 1 and 100 (25 by default), and it can't be undone without deleting and re-adding the trigger. Our advice: set it to 1 for a flow that writes to one workbook.
• An Apply to each loop runs one item at a time by default. If you raise its concurrency, which the same page allows up to 50, each item running at once is another writer. For a loop that writes to one workbook, keep the default.

Other limits that look like a lock

The same reference lists other behaviours that are easy to mistake for a locked file:

For the connector's other writing limits (changes that take up to 30 seconds to show, only the first matching row updated, rows added twice after a timeout, throttling and file sizes), see List rows present in a table only returns 256 rows.

If many people and flows need to write the same data, a workbook will keep running into these limits. Our guide to List rows present in a table has a section on when to stop using Excel.

Sources

• Microsoft Learn: Excel Online (Business) connector: known issues, common errors and limits
• Microsoft Learn: Limits of automated, scheduled and instant flows: retry policy, concurrency and run duration
• Microsoft Learn: Handle errors and exceptions in Azure Logic Apps: retry policies
• Microsoft Learn: Employ robust error handling in Power Automate: run after settings
• Microsoft Learn: Use wait conditions to delay flows
• Microsoft Learn: Avoid anti-patterns: parallelism in the For each loop
• Microsoft Learn: Microsoft Graph error responses: HTTP status codes
• Microsoft Learn: Error handling for Excel APIs in Microsoft Graph