Question
self employed
US
Last activity: 8 Jan 2020 19:13 EST
SLA refresh issue
Our application uses Windows Mobile Client to enable offline mode for part of the workflow where the users will be away from wifi. Because of that, we have to set the case type to "Optimistic Locking".
If an SLA rule fires while a user is working on a screen that has not yet been saved, the user is required to refresh the screen and loses data entered so far. When the "Refresh" error appears, <Save> no longer works - the case has apparently been updated by the SLA agent in the background.
Since the "Inspection" screen represents quite a bit of work for the user, it is a problem that has to be solved. We have temporarily extended our SLAs to at least 1 week to mitigate most of the instances
1. Create an Inspection case.
Our application uses Windows Mobile Client to enable offline mode for part of the workflow where the users will be away from wifi. Because of that, we have to set the case type to "Optimistic Locking".
If an SLA rule fires while a user is working on a screen that has not yet been saved, the user is required to refresh the screen and loses data entered so far. When the "Refresh" error appears, <Save> no longer works - the case has apparently been updated by the SLA agent in the background.
Since the "Inspection" screen represents quite a bit of work for the user, it is a problem that has to be solved. We have temporarily extended our SLAs to at least 1 week to mitigate most of the instances
1. Create an Inspection case.
2. Work on the case (completing the Inspection screen) when the case age is near the Goal or Deadline for the SLA.
3. SLA fires before i'm finished with the Inspection screen and before the data entered/modified on the screen is saved to the case.
4. "Refresh" message appears and data entered/modified is lost.
***Edited by Moderator Marissa to update SR Details***
Pegasystems Inc.
US
Coforge Technologies (Erstwhile Incessant Technologies)
GB
Hi Dennis,
As per Harish, the alternatives going with Default Locking is not possible as you are using offline capability for part of the flows.
Other work around you have already done by increasing maximum SLA duration which is not the right and optimal.
The final alternative could be to display a warning message to the users for the cases that are accessed are nearing deadline in next 30 mins. or whatever time you think better as processwise.
Hi Dennis,
It is expected behavior when you use Optimistic Locking.
With optimistic locking, Use performing Save or Submit action on the assignment which is already updated by SLA agent will result in similar “Case Updated by Agent” warning and had to refresh(current changes lost).
This can't be changed as the system ends up having stale data.
Eg:- Agent picks CaseAB and submits as CaseXY which is now the latest, but the user picked CaseAB before and submits as CaseABCB. Now the XY update is gone. Hence it's not allowed. When it comes to locking mechanism it is a trade-off between Usability vs Consistency.
The only alternative to overcome this expected behaviour is to -
1. Changing to Default locking -In this case, SLA can never update the case while CSR is filling up the data. Every update requires a Lock.
If optimistic locking was chosen as per your business requirement for a reason, then consider 2nd option.
2. Reset or Adjust SLA times in preprocessing activity whenever the user picks the assignment which is ready to be updated by SLA – Explore pxAdjustSLATimes OOTB activity. (This just minimizes the occurrences as user get to reset the SLA timer)
3. Increase the SLA agent processing time to a higher number based on "Maximum time a case user can go offline"
Hi Dennis,
It is expected behavior when you use Optimistic Locking.
With optimistic locking, Use performing Save or Submit action on the assignment which is already updated by SLA agent will result in similar “Case Updated by Agent” warning and had to refresh(current changes lost).
This can't be changed as the system ends up having stale data.
Eg:- Agent picks CaseAB and submits as CaseXY which is now the latest, but the user picked CaseAB before and submits as CaseABCB. Now the XY update is gone. Hence it's not allowed. When it comes to locking mechanism it is a trade-off between Usability vs Consistency.
The only alternative to overcome this expected behaviour is to -
1. Changing to Default locking -In this case, SLA can never update the case while CSR is filling up the data. Every update requires a Lock.
If optimistic locking was chosen as per your business requirement for a reason, then consider 2nd option.
2. Reset or Adjust SLA times in preprocessing activity whenever the user picks the assignment which is ready to be updated by SLA – Explore pxAdjustSLATimes OOTB activity. (This just minimizes the occurrences as user get to reset the SLA timer)
3. Increase the SLA agent processing time to a higher number based on "Maximum time a case user can go offline"
I couldn't come up with anything better.