In an evolutionary fashion, new concepts have been added to K2 in addition to concepts being changed and refined.  To the developer, it means adopting these new and changed concepts to model business processes better.  With that in mind, this article addresses a point of confusion that has crept up to which I have fallen prey to.  When should you use outcome rules over line rules and how do actions relate to this?  The pitfall so easy to fall into occurs when modeling a multiple branching scenario from an activity.  If the new K2 concepts have not been understood then where one would expect multiple branches to be followed only one is followed.  This is the issue that this article addresses.

Collectively, the three concepts “actions”, “outcomes” and “lines” form the basis of abstracting lower level programming concepts and moving towards higher level concepts that an end user would understand.  I am often asked to explain (to both developers and non-developers) the benefits of using a workflow modeling solution like K2 versus just coding it up directly.  This article is not meant to be an exhaustive exposition on this matter but I would like to highlight one point to elucidate the “abstraction” concept.  The point can be summarized as follows: 

In any solution that models a business process, on one end of the spectrum there is the raw code that is written by developers.  On the other end, we have business requirements written by business analysts.  In the case that we are modeling business processes, the requirements are likely Visio diagrams. 

Which is easier to understand (by an end user)?  Which is easier to modify?  It is of course the business requirements[1]. 

With these extremes mapped, I would say that K2 sits on the spectrum somewhere close to the business requirements (Visio diagrams) with the opportunity to drop down to the code level if needed; something to please the business analyst and something to please the developer.  This is made possible because the concept of a “step” in a workflow has been brought up from the code level to a tangible concept understandable to the computer and something that can be modeled by a business analyst.  This is made possible because of abstraction.

Those of you who have worked with K2.net 2003 know that lines and more specifically line rules are not new.  They are the logic that represents many lines of code that directs the flow of execution from one step (activity) to another step.  In the same tradition of abstraction, there are two new concepts that have been teased out of the code.  They are Actions and Outcomes. 

Actions

From the workflow, the steps that involves human interaction requires that the human do something or “action” that step.  Actions are the options, typically surfaced in a form like “Approve” or “Reject”, that a human can act on a step he/she is assigned that will advance the workflow.  .  In K2 parlance, actions are defined on each activity that has a client event.  This seemingly simple abstraction allows for the following:

·         Actions are surfaced up to the K2 workspace which allows a user to action a step right from the workspace, if so desired.

·         Actions can be secured.  Each action can be assigned a specific access rights from the K2 workspace UI.  This allows certain actions to be assigned to some people and restricted from others.

·         Actions need not be hardcoded into the “actioning” form.   This means that the list of possible actions can be retrieved from the system rather embedding it in form. The advantage of this approach is that the actions in the workflow can change without necessarily requiring the forms to be updated.

Outcomes

Outcomes are a natural extension of actions.  Outcomes are formal definitions of a K2 activity that defines the end result of an activity once it has been “actioned”.  In many cases, outcomes are one-to-one to actions but they need not be and it is when it is not that things can become confusing.  The interesting point is that by design there can be only one outcome followed for an activity.  In the one-to-one case, because the user selects one and only one action, it will correspond to one and only one outcome. 

In the case that it is not one-to-one, consider the example of a K2 activity:

Actions defined:

·         Complete

·         Incomplete

 Outcomes are not one-to-one and defined as:

1.       Complete1: Action = Complete

2.       Complete2: (Action = Complete) And (ProductType = Widget)

3.       Complete3: (Action = Complete) And (ProductType = Doodad)

For each outcome above there is a line that branches the workflow; lines have no rules so that workflow can branch off in three different directions when the user actions “Complete”.

Because there can be only one outcome, only the outcome “Complete1” will activate.  The other two will not be evaluated because an outcome has been found to be “true”.

The first line will be followed, the other two will not. 

Outcome definitions must be defined such that only one is evaluated to true.  They must be mutually exclusive.  The extra clauses (ProductType = Widget, ProductType = Doodad) that I have above that make the outcomes not mutually exclusive should not be defined here.  These rules are what control the flow of the process out from the activity.  As such they should be defined in the lines coming out of the activity. 

To fix the above scenario, there really are only two outcomes, Complete and Incomplete, because this is the set that is mutually exclusive.  In this case, because there is no branching with the “Incomplete” outcome it can be removed.  The extra clauses that control the branching need to be defined as line rules.

For the branch “Complete1”:

The “Outcome” green variable is a new activity level field that is accessed from the Context Browser:

For the branch “Complete2”:

And for the branch “Complete3”:

When the process is changed so that lines have the rules that control branching then the “expected” behaviour follows. 

Summary

This article addresses the issue of when to use outcome rules and when to you use line rules.  When this is understood, you will not fall prey to creating a multiple branching scenario that does not seem to follow the defined multiple branches, despite having defined the branching logic. 

To summarize the rule of thumb, outcome definitions must be mutually exclusive as there can only be one outcome.  Any rules that define the branching from the activity are meant to be defined on the lines and not part of the outcome definition.