Are there any issues with multiple user writing to sharepoint list simultaneously, concurrency issue

%3CLINGO-SUB%20id%3D%22lingo-sub-1681765%22%20slang%3D%22en-US%22%3EAre%20there%20any%20issues%20with%20multiple%20user%20writing%20to%20sharepoint%20list%20simultaneously%2C%20concurrency%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1681765%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20All%2C%3CBR%20%2F%3EI'm%20in%20the%20process%20of%20putting%20together%20an%20app%20using%20powerapps.%20Are%20there%20any%20issues%20with%20multiple%20users%20writing%20to%20a%20sharepoint%20list%20at%20the%20sometime%20when%20using%20powerapps.%3CBR%20%2F%3EThis%20issue%20does%20exist%20when%20users%20are%20using%20the%20out%20of%20the%20box%20sharepoint%20list.%3C%2FP%3E%3CP%3EIf%20they%20are%20in%20powerapps%20are%20they%20was%20to%20avoid%20this%3F%3CBR%20%2F%3E%3CBR%20%2F%3EThanks%20in%20Advance%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1681765%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EPowerApps%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESharePoint%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1681961%22%20slang%3D%22en-US%22%3ERe%3A%20Are%20there%20any%20issues%20with%20multiple%20user%20writing%20to%20sharepoint%20list%20simultaneously%2C%20concurrency%20i%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1681961%22%20slang%3D%22en-US%22%3EThere%20are%20no%20mechanisms%20to%20commit%20transactions%20so%20overstep%20can%20occur.%20You%20can%20however%20put%20in%20logic%20to%20your%20updates%20etc.%20to%20refresh%20your%20data%20just%20before%20making%20an%20update%20or%20do%20some%20other%20tricks%20but%20there%20is%20no%20guarantee%20method%20for%20it.%20I%20like%20to%20publish%20to%20an%20audit%20log%20just%20in%20case%20that%20journals%20all%20the%20updates%20and%20additions%20but%20you%20also%20can%20turn%20on%20version%20history%20on%20the%20list%20to%20retrieve%20things%20from%20that%20if%20needed%20too.%20%3CBR%20%2F%3E%3CBR%20%2F%3EI%E2%80%99ve%20never%20had%20issues%20but%20I%20also%20don%E2%80%99t%20have%20any%20high%20transaction%20apps.%20Most%20processes%20are%20isolated%20and%20multiple%20people%20don%E2%80%99t%20usually%20work%20on%20same%20item%20at%20sams%20time%20as%20it%20follows%20a%20logical%20workflow%20or%20status%20process%20flow.%3C%2FLINGO-BODY%3E
Highlighted
Contributor

Hi All,
I'm in the process of putting together an app using powerapps. Are there any issues with multiple users writing to a sharepoint list at the sometime when using powerapps.
This issue does exist when users are using the out of the box sharepoint list.

If they are in powerapps are they was to avoid this?

Thanks in Advance

5 Replies
Highlighted
There are no mechanisms to commit transactions so overstep can occur. You can however put in logic to your updates etc. to refresh your data just before making an update or do some other tricks but there is no guarantee method for it. I like to publish to an audit log just in case that journals all the updates and additions but you also can turn on version history on the list to retrieve things from that if needed too.

I’ve never had issues but I also don’t have any high transaction apps. Most processes are isolated and multiple people don’t usually work on same item at sams time as it follows a logical workflow or status process flow.
Highlighted
Thanks Chriss.
The one issue i'm facing now is when a user is in edit mode working on a record and another user at the same time clicks and edit an item
The record gets locked and the user has to close the window which means they would have to re enter there data again as they wouldn't be bale to save the record.
This issue is common with out of the box sharepoint list.
Does this occur in power apps?
If it occurs and have to put a logic to avoid this what would it be in powerapps?

Highlighted
It anything, it'll overwrite with whoever updates last and you could see the previous data via version history, but this isn't ideal.

One way you might approach it is by creating a similar locking mechanism that set's an "inUse" bit on the list, that you set to 1 or true when you open an item in the app. Then remove it or set it false when you save or cancel / navigate away. The only issue I see here thou would be if someone closes the app without navigating away, you would need some form of "Unlock" or you could have a timer, say, IF inUse is true AND inUseTimeStamp is more than 15 minutes ago, allow the edit form to come up and reset the timestamp. You could even inUseuser as well. Anyway, you get the idea, you would have to just use a few fields and build it into the navigation etc. so you set flags right then and there quickly to prevent others from opening and when opening the items you get the current data at the time of open.
Highlighted

@Chris Webb Thanks for the reply.
i have actually created such a mechanism already using another list to track the users when they are in edit mode.
But tracking how the exit the page is a tough one (currently if they click the back button or click a specific link to go back its all good and it works) as they can just closed the browser (So i like the idea where you suggested to have a timer and if exist after certain time it automatically removes the user)

Thanks for the idea :)

Highlighted