My sampleK2Process project on has an implementation of this approach in a ready to go package.  However, the code is squirreled away and not convenient to get to, so I’m going to post here as many of you may have not noticed the flexibility and power that K2 provides in the error event handlers.

I have to give kudos to “Dr.” Bob Maggio as he, in fact, is the one who showed me how to do this in the first place 🙂

Either as you are creating or once you realize that a particular activity or event in your K2 process is going to be prone to error, you will want to do something logical with that error instead of leaving it for an administrator to catch risking a slip through the cracks.

I typically architect my processes with transactional events together within one activity, so I’m spoiled to almost exclusively using activity level exceptions events.  However, you should be aware that you can catch and handle exceptions at the process, activity and event level in K2.

Two important things to consider:

1) You have to have an activity to go to.  I usually configure 1 or more client events with access to a form where routing and destination information can be updated to temporarily account for a problem with the data itself.  Then couple one of the outcomes of the client event with an activity/event that issues a “goto” to send the process back to the event that experienced the error.  (note the 3rd set of ******* in the code below)

2) The Goto() method now has the ability to either cancel all other activities like it did historically or just affect the current path being followed through the process.  By adding the “false” overload in the Goto() below,  multiple other client events can continue to function in the same process and not be affected by one path being in an error state.  Currently, if you have parallel paths and one path generates an error, your other path’s client events and reporting are affected until the error is resolved.  This granular goto wasn’t available when I put together the SampleK2Process and SampleK2Form projects on K2Underground’s blackmarket a few years ago, so keep that in mind if you decide to use them as a starting point for your support process.

  • Click on the ! yellow triangle icon in your activity details
  • Check the “enable..” checkbox and “View Code” ( you will want to revisit this wizard later when you are done coding and make sure that it saved those settings )
  • Add the following code to the method stub provided: replacing the two lines that are there.  Note that if the boolean “handled” doesn’t compute to true at the close of the method, you get the default behavior back.

K2.AddToErrorLog = false;
K2.AddToServerLog = false;

string strType = K2.ContextType.ToString();
string strActivityName = "";
string strErrorMsg = "";
bool bHandled = false;
Exception ex = (Exception)K2.ExceptionObject;

if (K2.ContextType == SourceCode.KO.ContextType.ServerEvent)

SourceCode.KO.ServerEventContext oServerEvent = (SourceCode.KO.ServerEventContext)K2.ContextObject;

strActivityName = oServerEvent.ActivityInstanceDestination.Activity.Name;

strErrorMsg = "There was an error in the process, <b>"
strErrorMsg += oServerEvent.ProcessInstance.Process.FullName + "</b><br>";
strErrorMsg += "<b>Activity: </b>" + strActivityName + "<br>";
strErrorMsg += "<b>InnerException.Message:</b><br>";
strErrorMsg += ex.InnerException.Message;

//******* Create process datafield to hold this errored activity’s name
oServerEvent.ProcessInstance.DataFields["strErrorActivity"].Value = strActivityName;

//******* Create process datafield to hold the error to display to the client
oServerEvent.ProcessInstance.DataFields["strLastErrorMessage"].Value = strErrorMsg;

//******* EDIT the name of the activity with a client event with update and retry options
oServerEvent.GotoActivity("RepairErrorActivity", false);
bHandled = true;

// if this wasn’t handled explictly then handle the normal K2 way
if (!bHandled)
K2.AddToErrorLog = true;
K2.AddToServerLog = true;