By |

I freaked out a little in my first look at K2 blackpearl 4.6.9 — I didn’t see the Environment Fields node in the Object Browser.

What?! No Environment Fields Node in the Object Browser?!
What?! No Environment Fields Node in the Object Browser?!

Oh no! Why would they take away the environment fields? I RAVE about these things, and for good reason — they allow for string values to be injected into a process at runtime. I use this magic in the form of e-mail text and other data the business might want to tweak at will, because it saves me from having to recompile and redeploy the solution — a workflow process will grab the value when it needs it.

Fortunately, one of my team members was able to talk me down from the ledge: Environment Fields are still very much a part of blackpearl — the folder just won’t exist until you create an environment field.

Here’s how: Open your blackpearl project, and navigate to the object browser. Right-click on any of the existing nodes, and click on Add new field… .

Add New Field
Add New Field

You should see the familiar Add New Field dialog appear. Here’s the key: Select Miscellaneous Field in the Item Type drop down list. Name your field and give it a value. Fill in the Field Description field for extra credit and click the black OK button in the dialog’s lower right corner.

The Add New Field Dialog
The Add New Field Dialog

The Object Browser should refresh. A wild Fields node appears!

The Object Browser, complete with Fields node
The Object Browser, complete with Fields node

It’s super effective!

Expand the Fields node to see your field. Hover over the field to see the string value.
Expand the Fields node to see your field. Hover over the field to see the string value.

By the way, if you remove the single Environment Field you just created, the Fields node will disappear again.

By |

 

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.)

MakeEscalationsSmarter-1

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.

Continue reading →