Question
Last activity: 18 Mar 2016 15:15 EDT
SLA action while work object is locked
we have a use case for SLA as System should trigger the escalation actions on time.
The concern with SLA and locking is the ServiceLevelEvents agent cannot act on a work object that is currently locked by different requestor,Let's say if user close the browser while case is being locked by user then SLA agent has to wait for 30 mins(default lock timeout) to act on a work object to trigger an escalation actions that defined on deadline event ,but the goal and deadline times (10 mins) are very short compared with default lock timeout ,a customer is waiting for a response. 30-minute delay is significant impact on the business use case.
Here neither reduce the lock timeout (<30 mins) nor configuring the optimistic locking .
Please share the feasible solution to trigger an escalation actions on time.
PRPC:7.2
I see a thread Re: SLA notifications, escalation when WO locked related to the same issue.
The suggested solution makes sense to me but I have the following concerns
Does it require to add a new case type to overcome this consequences ?
Wouldn't be affect the maintenance of work table by keeping these tracking cases.?.
Can we make the tracking subcase in generic way for all assignments of parent case that are configured with different SLA.?
Pegasystems Inc.
US
Hello, I didn't implement the mentioned solution but my understanding of its intent and mechanism would imply a new case type. There would certainly be elements of these items stored in the associated tables, I wouldn't anticipate much maintenance impact from said extra artifacts. I would expect the tracking subcase could be designed to have goal and dealine times coupled to parameters at instanitation that could meet the generic goal.
Pegasystems Inc.
US
This is a good design question, and depending on your ability to segregate the SLA actions info a separate work type, you might get different solutions.
The trade off is the loss of work if the user who may hold the lock when it's automatically released vs the delay of the SLA agent. Which is more important?
If you know most operators update their cases so should only hold the lock for 10 minutes, then you could likely live with an occasional loss when an operator exceeds this time and looses the lock.
If you use a sub case type for the SLA, and can segregate the SLA activity to the sub case type, you have essentially split the task, at the cost you have identified - a new case type (subcase)
I can imagine a design where the subcase is generic and comprehensive for all assignments of the the parent cases, add their "sla" info to a list in the sub case, however this might be harder to maintain, and more effort to implement. You are essentially duplicating the grouping the parent case provides. Perhaps using the parent case as a "manager" you could use that for the SLA activities, and only have the user lock the subcases.