How to avoid data conflict - concurrency check
Mikkel_Madsen
Customer Advanced IT Monkey ✭✭✭
Hi
Our Support team has a work process that uses the affected user app to create the request and then immediately open the newly created request to provide more info.
This gives a problem with the workflow changing the status from new to in progress/submitted in the background so the analyst gets this data conflict error.
Isn't there a way to merge data - it will never conflict because is always just the status of the request that has changes and the user just providing text to actionlog og attaching files to the request.
Thanks.
Mikkel
0
Comments
Cireson, any thoughts or a response on this? We have a very similar situation where we have some automation setup to adjust certain fields, anytime that takes longer than 5-10 seconds, analysts get the data conflict error for altering other fields.
Thoughts?
This behavior has gotten better in newer versions of the portal. You can however disabled the concurrency check all together in Admin Settings -> Setting Items. The key is called RunConcurrencyCheck. You can set it to false.
@Justin_Workman Are there any downsides to disabling concurrency check?
Agree, what are the downsides of disabling the check?
I have to imagine that the risk here is around Status. Since SCSM has a natural order of operations (out of box workflows) to the effect of:
The risk would be you create the Work Item (it's New for about 30 seconds), you go to it while it's still new, edit some information, and in that time it's flipped to another status behind the scenes. You'd commit the record with a status of "New" and the process would start over. It's probably only made worse with Activities since those would not reset probably effecting the overall flow of things. The end result is workflows running more than once for the same Work Item. Depending on how often that happens, you could be generating a lot data (EntiyChangeLog data/ECL records).
It sounds Feature Request worthy to have that dialogue menu above show you a difference, then you can choose what you want to keep.
One of the discussions that we had internally is if two analysts are working on a ticket, by disabling this the system would not notify whoever was trying to save last and the previous analyst entry/work would be lost. Is this also a possibility?
Your Feature Request idea to give the analyst receiving the data conflict the option of what information to save sounds brilliant. Thanks Adam.
by disabling this the system would not notify whoever was trying to save last and the previous analyst entry/work would be lost. Is this also a possibility?
Yup
@Jason_Meyer A quick test shows that comments added to the actionlog will retain for both the analysts but all fields will hold the value that is submitted last. e.g. Title, Description, Urgency etc.
@Adam_Dzyacky Our experience is that if you open a service request with a status of New and the workflow in the meanwhile changes the status to submitted and you then save the request and thereby set the status back to New again it wil be stuck in that status and it seems like you brake the workflow.
In other words workflows does not seem to repeat if you set the status to an earlier state. Instead it will brake the out of box workflow functionality. At least that is our experience with New/Submitted. It can only be "New" once.
A quick test shows that comments added to the actionlog will retain for both the analysts but all fields will hold the value that is submitted last. e.g. Title, Description, Urgency etc.
Oh. Duh! That makes sense because the Action Log is a relationship that is always being created. Good catch @Mikkel_Madsen