One common use-case in Power Automate is to create and manage files in SharePoint. SharePoint also has an amazing feature where you can have additional properties to a file, like "status", "responsible" or anything that allows you to better work and classify a file, but that's a bit outside the scope of this article. Properties are amazing in SharePoint since they allow us to have extra information and they can even be used to trigger other Flows, like trigger a Flow once a file is "concluded" for example.

However, we can get a "Your changes conflict with those made concurrently by another user." which can be misleading since you may not have other people working on those files.

Let's understand the problem and how we can fix it.

The Issue

Actually, it's not a real issue in both Power Automate or SharePoint. It's something that happens because things are done asynchronously. Oversimplifying what happens is the following:

1. Power Automate sends the file to SharePoint to be saved.
2. SharePoint receives the file and saves it.
3. SharePoint reports back to Power Automate indicating that the file is saved and blocks the file
4. Power Automate continues since it got an OK from SharePoint that the file was created.
5. Power Automate tries to access that file again in the next action, but SharePoint didn't finish working on it.

SharePoint does a lot of actions in the backend to prepare the file, like indexing, metadata initialization, search indexing and more. Indexing is essential so that we can have quick searches when we try to find something but adds an additional overhead since the system needs to prepare to find that information, but Power Automate doesn't need to know about it. SharePoint can return to Power Automate the indication that the job is done and it can proceed. When Power Automate tries to access the file before SharePoint finishes, you get an HTTP 409 Conflict error—the "changes conflict" message.

Microsoft started integrating more and more AI services in SharePoint that only exacerbated the problem, or at least, made the file preparation time a bit longer, but this is a great tradeoff between the rare occasions where we want to access the file right away after and having quick searches and AI help in performing the tasks.

Solution 1: Add Delays Between Operations

The simplest solution is adding a delay between SharePoint "Create file" action and "Update file properties" action. A 5-10 second delay gives SharePoint time to complete backend processes before your update attempt.

I'm the first to admit that adding "Delay" actions is not a good solution because we would be:

1. Adding an action that counts towards our limits
2. Making our Flows running slower.
3. Having to "guess" what would be the sweet spot for the delay. 15 seconds would always theoretically work, but adding this will increase the processing times, while 2 seconds may not work for example.

This isn't elegant, but it's effective for flows where the delay doesn't impact user experience or need to finish as fast as possible.

Solution 2: Implement Retry Logic

Instead of blindly delaying, implement retry logic that attempts the update and retries if it encounters a 409 error. This approach only adds delay when necessary and you can control how much the delay would be.

I have an "Advanced Error Handling Patterns in Power Automate" article if you want more details, but the idea is to configure properly the "Configure run after" feature to add actions that run when "Update file properties" action (or any other action after the file creation) fails.

This pattern is more sophisticated than a simple delay and provides better performance on average—successful updates happen immediately, while conflicts get retried automatically.

I recommend using "Exponential interval" where we can try a few seconds later (usually fixing the issue), with increasing delays between retries for persistent conflicts.

Solution 3: Try Catch Logic

The same "Advanced Error Handling Patterns in Power Automate" also shows you how to use the "Try-Catch-Finally Pattern" where the actions become clear. I also have a template that you can find here.

The try-catch pattern with scopes makes this cleaner:

Try Scope:
  - Create file
  - Update file properties
Catch Scope (runs if Try fails):
  - Check if status code = 409
  - If yes: Delay 5 seconds, retry update
  - If no: Treat as permanent error

This logic is quite nice because you'll see things being retried and you can perform actions if there's a retry, for example, being notified, or doing any other action. The disadvantage is that you have to take care of the branches and deal with the delays with the "Delay" action again, but it's recommended over a "simple" delay.

Final Thoughts

We'll see these types of issues increasing over time. It's something that we need to learn how to deal with. It's partly because the number of files generated is increasing (it's quite easy to generate large files using AI for example), organizations are centralizing more and more the processes, Microsoft launches new features that require pre-indexation of files, to name a few.

We also need to remember that SharePoint was created a while ago and it's been adapted over time for things like the Cloud and now AI. It's a lot and these pre-parsing strategies help a lot in making things easier for the user, but there are always tradeoffs.

As you've seen above, there's no perfect solution. If we add simple delays we can get around the problem but add time to every run. The retry logic with "Configure run after" provides smarter handling, but it requires you to do a bit extra work. The try-catch pattern gives you the most control and visibility when things retry, but it takes more effort to set up and maintain. If you're not sure where to start, go with delays for simple flows where a few extra seconds don't matter, retry logic for flows that need to be reliable, and try-catch when you want to know when retries happen or need to trigger notifications.

I'm sure that we'll figure out as a community of a perfect solution that will solve the problems, but in the meantime, I hope these solutions can help you solve the problems.

Photo by Tomas Sobek on Unsplash