Workflow processes often assign tasks to users. When we enlist a user to provide input, we are asking her to take an action there. The action could be “provide input”. Once this action is completed the outcome of that action in the context of the process is perhaps to get that input reviewed by someone.
We may ask the reviewers to perhaps make a Decision to approve or reject that input. Out of that activity a set of outcomes are possible namely, Approved or Rejected.
K2 provides a Client event to automate this scenario very efficiently. Actions and Outcome is a configuration element in K2 client events – Default, forms, etc – that helps you build this pattern in to your processes.
One key value of the Actions and Outcomes framework is that now the actions are part of the Object model and they are programmatically available for user interfaces that present the Action UI.
This means that the UI does not have to make any assumptions about the number of actions or the possible outcomes. It can just focus on aiding the user to work on that task. The process design may change and more actions may be added or changed and the UI is immune to this change as UI merely executes a selected action and K2 process decides what outcome to reach based on the action.
WorklistItem.Actions gives us the Action collection associated with the Task. When Action.Name.Equals(selectedAction) you can .Execute the Action and that will complete the Task.
K2’s actions are security trimmed – you only see the action you have access to. This is handy as actions can be delegated selectively. You can also mark actions as update actions or finish actions allowing partial updates to tasks.
UPDATE: here’s a detailed post by Gabriel Malherbe on the same topic that compares K2.NET 2003 with Blackpearl (also includes screenshots and code): http://nakedprogrammer.blogspot.com/2007/12/actions-leads-to-outcomes.html