Did you know that there’s a database operation that occurs with each activity in a K2 blackpearl workflow process?
In short, the more activities you have in a process, the more database writes occur within each running instance of the process.
For better performing process instances, try to limit the number of activities you have within them.
Had this happen today: The business contacted me because they had a worklist item they couldn’t release.
Question for you:
Say you have a process with 3 activities, and you create 10 instances of that process.
Then you modify that process to add another 3 activities and deploy it. So your process now has 6 activities.
Then you create another five instances after the deployment, so you have 15 process instances in total.
How many instances should be completed after all 6 activities?
Let’s say a person actions a Process Instance in your workflow, but the item seems to “disappear” unexpectedly — routed to a special queue for workflow administrators because of an error condition. It would certainly be nice if the “actioner” was notified about the problem too, right?
I had a question today about how to determine which action was taken in a specific Process Instance.
K2 blackpearl has a nice way to automatically escalate activities. Say you have an activity which contains a SmartForms Client Event. Because events are fired sequentially within an activity, client events bring a process instance to a standstill until the client event is completed. (The example below contains four events, which are called sequentially. The green backgrounds indicate events which have completed; the blue background indicates the Get Approval Client Event is in progress, and the white indicates the Call Review event has yet to be called.)
K2 was clever to bake in some simple escalations, which can be based on an arbitrary value for elapsed time. If your approver hasn’t taken action in a timely manner, you can have K2 do things like send the process instance to a separate activity, or to nag the approver with reminder messages.
Recently, I was asked if we could shut off the escalation for a specific activity. Several hundred people were about to receive reminders about their applications when the delay was actually on our side, not theirs. Sadly, because the process instances were tied to a specific version of the workflow, deploying a new version with the escalation action deleted or modified would only affect processes instantiated after the new version was deployed. It wasn’t going to do anything to help with the current situation.
The conundrum led me to think about how we could handle a situation like this in the future, and at will. Here’s what I came up with.
I was recently asked if one can determine whether a specific person has a specific process instance in his/her worklist. The answer is yes — an administrator can do this from the K2 Workspace if some attributes about the process instance are known.
Start Rule 
You must be logged in to post a comment.