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.

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.