Flow Error w/ Save Conflict - Any way around it?

[ampierce]

We have a flow in place to set a field in a SharePoint list item on create. However, the user sometimes reopens the item immediately and makes a change, resulting in a Save Conflict error on the flow.

Has anyone dealt with this? Will the retry settings help us in this? I read that they only retry on certain errors, does this error apply?

Any help appreciated!

Thanks,

Amanda

[Brad_Groux]

In these kinds of scenarios you have a few of options:

1. Have the Flow run on a schedule
2. Have the Flow process the entire list each time
3. Utilize the When an item is created or modified trigger
4. Utilize Flow Logical Expressions in a condition 

Which route you go kind of just depends on preference and workload, such as how often the list items are being updated, how many people are updating the list, and how many items are on the list. Personally, I'd likely utilize option 4, and have the field set action run only if the condition is met.

There are a few condition options, such as doing something time-based, so if Modified time doesn't equal Created time, don't run the flow. Or, if the Modified By isn't equal to Created By then the condition doesn't pass. Here's an example:

If this reply has answered your question or solved your issue, please mark this question as answered. Answered questions helps users in the future who may have the same issue or question quickly find a resolution via search. If you liked my response, please consider giving it a thumbs up. THANKS!

[ampierce · Accepted solution]

@Brad_Groux  thank you for the reply, I'm not sure how I follow that any of the options would actually prevent the Save Conflict error that occurs. Our flow is currently running with a condition to check if the field we are trying to set is empty. So it will only fire on Create when that is true.

1. We could try this but it still leaves the chance that a user is modifying the record when we are running a flow on it, right?

2. This is a huge list, updated all the time by users, its basically their ticketing system, i could limit by view however I still feel like this leaves it open to the Save Conflict error

3. If we fire on create/modify this increases the amount of flows run, not sure I want to waste them on each time its modified

4. We are using a condition for the flow, I'm not sure how I follow to use the Create/Modify time comparison with this one

Again, the issue here is that the user is interacting with the SharePoint item at the same time the Flow is running on it.

I think we could handle if the retry settings actually applied to a 400 error, "Retry Policy

A retry policy applies to intermittent failures, characterized as HTTP status codes 408, 429, and 5xx, in addition to any connectivity exceptions. The default is an exponential interval policy set to retry 4 times."

But I do not believe its even retrying in this case.

[Brad_Groux]

If you are getting a SaveConflict error frequently, then you may have an issue in your SharePoint environment. The SaveConflict error indicates the item was changed since the item was initially loaded by Flow and the update attempt was made. That means people are editing it within a few seconds of submitting it and while Flow had it open for 1-2 seconds - that should be pretty rare.

If it isn't rare in your case, just put in a short delay for the Flow to run. You can delay a set time (seconds, minutes, hours or days) or until a specific interval after the item was created, or the last time the item was modified (example: delay until modified date >= 5 minutes). 

Responses to your previous items: 

1. No, have the schedule set for off-peak hours and/or at the end of the day. You're updating a single column value, is it really a big deal if that value isn't updated immediately?
2. If it is a large list this likely isn't ideal, but you can also filter with OData
3. This is why you would run on a schedule
4. You can use literally any condition that is relavent to your environment and workload, and you can also nest conditions inside of each the yes and no actions, so you can do multiple conditional checks to fine tune until you get the desired results that work within your environment's constraints

If item locking is truly that big of a deal, then your workload is likely meant more for a transactional database, and not a SharePoint list. SharePoint lists are fairly stable, but if you have hundreds or thousands of changes made per hour (the only real way locking SaveConflicts would occur regularly), that is beyond what they were meant for. You're expecting transactional from a connector that only allows for 10 calls per second.

If that is the case, and a database isn't an option, you can akso have the users "submit" to another list, and then you copy/migrate the the items to a new list where the Flow can run without conflicts. You can then sync changes between the lists, so you have a "working" list and a "production" list.

Finally, you never want to set a trigger to a Flow that you don't inherently have control over. If other users can affect your trigger beyond what you need or intend, then you need to find a new trigger. There is an answer for how best to work within your environment, but only you can know that.

If this reply has answered your question or solved your issue, please mark this question as answered. Answered questions helps users in the future who may have the same issue or question quickly find a resolution via search. If you liked my response, please consider giving it a thumbs up. THANKS!

[ampierce]

@Brad_Groux  Thank you! It doesn't happen all of the time, which is good. I think we are going to try the Delay option and send ourselves a notification on error.

Appreciate the assistance.

Amanda

[Rajatk912]

In my case , I had to convert the newly arrived mail to pdf . 

so what worked for me is that everytime i had to delete the output of 'create file'  from onedriver after converting my .eml file to pdf.