Escalation Timers, Is there a RESET?

  • 25 January 2010
  • 5 replies
  • 2 views
J
Badge +2

From what I have verified in a simple test process,it appears that K2 Process escalation rules and possibly activity escalation rules are only set once, when either the process is created or the activity is reached. Meaning, if I set a due date for a process to complete and I want to be notified before it's due, the process escalation rule will be evaluated at creation time and will trigger once that threshold is reached. Here is a real world scenario.


Ex:


Start a task at 7 this morning, with a due date of 11AM. Have a default escalation rule that will notify (email) the assigned user a task is due within 1 hour of its expiration. At 9:30 am, the process originator wants to change the due date to to 5PM.


Result:


At 10AM the assigned user will get an email notification of the task. The due date will now say 5PM, however there will never be a 4PM notification sent.


So the question is, is there a way to make a K2 Process re-evaluate an escalation rule against a process variable "at will"?


 

5 replies

T
Badge +10

The short answer to your question is no.


When working with escalations in K2 its important to remember that escalations are set at the Process, Activity or Event level when its initiated.  Therefore the escalation clock will keep ticking until that escalation time or date is met and the escalation rule fires or the process/activity/event completes or is expired. 


Unfortunately, the only supported way to reset an escalation to be a different time or date is to expire the current activity or event and restart it with the new escalation time or date.  If its a process escalation the entire process would need to be cancelled and a new instance started.


To see the current running escalations you can look at the _Async table in the K2Server database.


I hope this helps.  Tim

J
Badge +2

well.. it does help, but it only helps in verifying this shortcoming of blackpearl. since in my case a process could be several activities deeper when a "due date change" occurs, killing a process and starting a new one is not an acceptable solution. It would require users that have already done work, to perform the same tasks again.


I tried to manually add items to the async table. It seems there are some other tables that depend on the escalation, as i can manually change the escalation time and date value in the table BEFORE the original escalation runs, and the changes will reflect.

J
Badge +9

I think the reason why the escalation is not done that way is because you need to poll the required field for changes before firing the escalation.


So if you configure a code based escalation to fire at regular intervals, you could do a check on the field before deciding if the escalation should fire.


However, it is basically bad for performance in any enterprise application as this is a polling mechanism design.  Just imagine thousands of instances doing this check every x interval.  It's a pretty good way to kill your server.


I would think that this applies to any non-K2 solution as well.

J
Badge +2

I think I understand what you are saying, as it applies to K2. I also agree that a polling system would be the wrong design pattern for a system with thousands of individual tasks. The BP API should have the ability to change an existing escalation however, and would be a very welcome addition to the next version. Imagine a world, where a shipper couldn't change the due date on a package. Or, where a change in a due date of a task upstream effects several due dates below it. That is the kind of functionality an "enterprise" solution is supposed to have. I don't really see how providing an API call into the BP server to re-evaluate the escalation date would impact performance, since the current mechanism does not. All it would need to do is run the same time delta, and plop the record into the same schema it is using currently.


thanks for your help with this matter. I am surprised this limitation did not surface earlier for me. I don't want to sound like a jerk, but this shortcoming may end up scrapping or re-engineering a project that has spanned almost a year. Building a flexible notification system that sits outside BP and looks in, would require intimate knowledge of the db schema and platform. It seems our only solution would be to mirror every process and it's supporting info outside of BP, and when a due date changes, we would have to kill the original process, and create a new one with the same data.

J
Badge +9

I can see where this might come in handy.  I have logged a feature request for this so hopefully this comes in a later release.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings