Stumbling Through: K2 Blackpearl (Automatic Workflows Part I)
One of the workflow tasks presented to me that required a proof of concept was to enable a workflow process that automatically assigns itself to the appropriate person annually, monthly, weekly or daily. As usual, I stumbled through a solution without actually doing any research on whether or not there is a 'correct' or 'recommended' way to do this, so please feel free to critique what I've done here or use it as a K2 blackpearl learning exercise in how not to do things. First things first, we need to create our process. Right click your workflow project and add a new process, I've aptly named mine 'AutomaticWorkflow':
What we want to do with our nice blank-slate workflow is define a client event that will put an appropriately named task onto a service account's task list which will escalate to the appropriate owner's task list at the correct time (after a year, month, week, whatever). The reason we assign it to the service account is simply so that the workflow task is alive and kicking, waiting for the appropriate time to become 'active' by assigning itself to a real user. We have to trust that the service account user will never go in and close, reassign or otherwise tamper with this activity while it is hanging around on their task list waiting to escalate. This workflow also needs logic to re-assign the workflow back to the service account when the 'real' user finishes it, resetting its internal escalation clock so it will escalate to the real user again at the appropriate time. Let's get started with this workflow by dragging out a 'Default Client Event' activity wizard from the toolbar to our blank canvas:
Doing so will begin the default client event wizard which will ask us most of the important questions about our little workflow. Click 'Next' to start the wizard, and we are presented with the 'Event Name and Forms' dialog. We don't really care what this event is doing or what it is named, so just make it a web page action that opens up, oh, I dunno, my company's homepage:
Click 'Next' and we can ignore the next dialog which I believe will e-mail the recipient of the activity if you check the box. Click 'Next' again and we come to the 'Configure Actions' dialog. This is where we specify the various things that the user can do to this workflow, which for our purposes we will only allow them to close it. This wizard has a handy feature that automatically adds the 'Complete Task' action if we don't specify any actions, so you can go ahead and click 'Next' without specifying anything, and answer 'yes' to the dialog that asks if it should create the default action:
We are then presented with the 'Configure Outcomes' screen, which details the various states the activity can be in. Since we chose to automatically create the default action, it ties a default 'Task Completed' outcome in to that action so we can go ahead and click 'Next' without fiddling with anything:
Now the wizard is asking for the 'Destination User' of this activity, which is the account to assign the activity to once it starts. We want to specify our blackpearl service account here, so that the activity is placed in its task list by default:
Click 'Next' and then 'Finish' to complete the wizard and your canvas should now look like this:
Connect the 'Start' box with our activity (rename the activity to 'Automatic Activity' so we can identify it when it appears on the task list) and connect the 'Task Completed' arrow back to the activity, like this:
What this means is that whenever a user completes this activity, it will revert back to its default state of being assigned to blackpearl service account with the escalation counter reset. Escalation counter, you say? What's up with that? Well, I was just about to get into that... an activity can have 'escalations' assigned to it, which mean that on or after a certain amount of time, the activity can perform a number of actions including being moved from the current destination user to a new destination user, effectively moving it from the current task list to another user's task list. To accomplish this, we need to run the 'Activity Escalations' dialog, which is available from the activity's 'activity strip', accessible by clicking the little dropdown arrow next to the activity's name:
In the activity strip, select the 'Activity Escalations' icon, which resembles a little clock. This brings up the following Escalations dialog:
One activity can have multiple escalations, but in our case, we only need one: Activate Activity. Click the 'Add' button and name the new escalation:
Click 'Next' and we are provided with a list of possible escalation actions. The action we want in this case is 'Redirect', which will redirect the activity to a different user:
Click 'Next' and we are presented with the 'Rule Details' dialog. This is where we specify when the activity should be escalated, and while we have a number of options here, for the purposes of this blog (where we demand results fast), we will make the activity escalate every 5 minutes:
Something to note here is that the time specified here is based on the tie time that the process started - so the way we have things set up, the process starts whenever the user closes the current activity. This can lead to some inaccuracies when trying to make annual/monthly/weekly repeating workflows, because if you set up the time to be every 7 days (weekly) expecting it to appear every Monday, if the user closes it once on a Tuesday then the next escalation of the workflow will be seven days from that Tuesday, which would be the following Tuesday. I didn't see any options to do things like we see in Outlook scheduler, like 'every week on Monday' or 'January 1st every year' which would be very useful (at least in the approach I am taking to the problem). Click 'Next' and it is now asking us for the 'Redirect Action', which is basically asking who do we assign this activity to when it escalates. In our case, this will be the actual user or group that needs to address the task, I've assigned it to myself because it will help prove that the escalation is working:
Click 'Finish' and then 'Finish' again to complete the escalation definition. We will now deploy the process to the server, and once that is complete, we'll need to use the Workspace to manually start up the process as we did not tie this process into any server events:
Immediately after starting the process, we should see it on the service account's task list:
Now, we will wait five minutes and we should see it removed from the service account's task list:
and added to the 'real' user's task list (note the user names at the top of the screen shots):
I will now complete the task:
which will remove it from my task list:
And put it back on the service account's task list:
We can wait another five minutes to prove that it will escalate to me again.
There you have it, a workflow that automatically assigns itself to a specific user at a somewhat specific time. I'd like to see more options on the escalation time spans, but the way we defined this workflow comes fairly close to addressing the business need. It looks as if there is a way to manually manipulate the code generated by the escalation, which is likely what I'd need to do to add more complex time spans to the escalation logic. We will take a look at that feature in my next post.