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:
- 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?
- If it is a large list this likely isn't ideal, but you can also filter with OData
- This is why you would run on a schedule
- 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!
