You can use the powerful workflow capability in K2 to build different types of workflows. This article describes some common workflow execution models and design patterns that you can build with K2. This is not intended as an exhaustive list of all supported models and patterns, but rather examples of some common ones you can build using the K2 Workflow Designer.
You can download a deployment package containing these sample workflows from here: https://help.k2.com/files/16237. Deploy the package to a K2 environment, and then use K2 Designer to edit the workflow and understand how the workflows are built at design-time. You can also use the K2 Management site and K2 Workspace to run the workflows and understand how the workflows behave at runtime. The text above the workflow screen-shot is the name of the workflow in the package.
Workflow Execution refers to the way in which steps in a workflow run, mostly in serial or parallel fashion. Below are four examples illustrating how different execution models behave.
The Sequential (or Serial) workflow step model is typically the most common workflow execution model. In this model, steps in the workflow flow from one to the other, based on the lines that connect the steps and the logic that determine how the workflow flows from one task to the next, and steps wait for the preceding step to complete. Sometimes, steps may execute rapidly in sequence such as for a series of server-side steps, and sometimes steps may cause the workflow to wait for something to happen, such as during a user task where the workflow waits for a user's input, or a wait step that pauses the workflow for some amount of time.
Essentially, in this workflow, each approval step waits for the preceding step to complete.
The workflow starts and the First Approval step is reached. If rejected, the workflow goes to the End step. If Approved, the workflow continues to the Second Approval. If Second Approval results in Rejected, the workflow goes to the End step. If the Second Approval is results in Approved, the workflow goes to Third Approval. If Third Approval results in Rejected, the workflow goes to the End step. If the Third Approval results in Approved, the workflow sends an email to the originator and then goes to the End Step.
The Parallel steps model is mostly used when a workflow might have multiple paths active at the same time. In this pattern, the workflow splits at some point into separate paths, each of which may contain multiple steps. At some point, these paths may merge back together again. At the merge point, you can decide whether the workflow should wait for all preceding paths to complete, or whether the workflow should continue as soon as the first path reaches the merge point and expire any other active paths. You can even build more advanced logic to determine what should happen at the merge point in the workflow. To implement this model, you would use the Split and Merge workflow steps.
This workflow splits into two parallel paths of tasks, and the workflow waits for the two paths to complete before it continues.
The workflow starts, and it splits into two paths: Parallel Path 1 and Parallel Path 2. Both paths contain a user task step and an email step. Suppose the user in Parallel Path 2 completes Parallel Path 2 Task. The workflow sends an email in Send Path 2 Email, and then reaches the merge point. Since the merge point was configured to wait for all followed paths, the workflow waits for Path 1 to complete. At some point, the recipient for Parallel Path 1 Task completes their task, and the workflow sends an email. The workflow reaches the merge step again and now that both parallel paths have completed, the workflow continues to the End Step.
You can combine both Serial and Parallel execution in one workflow, where one part of the workflow executes in in parallel, while another part of the workflow executes serially.
This workflow contains two parallel paths, but the second path contains steps that execute serially and based on a decision made by a user in Path 2.
In this example, the workflow starts and immediately splits into two parallel paths. Path 1 contains a single user task and when this task is completed, the workflow proceeds to wait at the merge step for Path 2 to complete. Path 2 starts when the workflow splits, and there is a user task. Depending on the decision made by the user in Path 2 Task 1, the workflow might go to Path 2 Task 2A or Path 2 Task 2B (This is the serial part of the hybrid workflow). Once the relevant task has completed, the workflow sends an email. When both Path 1 and Path 2 are complete, the merge step succeeds, and the workflow ends.
You can use the Call Sub-Workflow step to build parent-child workflows (sometimes called Main and Sub workflow). When configuring the Call Sub-workflow step, you can tell K2 whether the parent workflow should wait for the child workflow to complete before it continues, or whether the parent should just continue after starting the child workflow (sometimes referred to as Fire and Forget). In either approach, you can pass data from the parent workflow to the child workflow. If the parent workflow waits for the child workflow to complete, you can also pass data back from the child workflow to the parent workflow.
The parent-workflow model is sometimes used to separate a very large workflow into mutiple, separate workflows, or to build patterns like the Façade Pattern.
There are two workflows in this example. The parent workflow starts, sets a value for a variable (which is sent to the child workflow later), and sends an email to confirm that the parent workflow is started. Next is a user task where the task recipient can decide whether to start the child workflow. If they decide not to start the child workflow, the parent workflow sends an email to the originator and ends. If the task recipient decides to start the child workflow, the parent workflow calls the child workflow with the Call Sub Workflow step. Part of the step configuration is to tell the parent workflow to pass the value for the Parent String Datafield variable to the child workflow’s Child String Variable variable. The parent workflow is set up to wait for the child workflow to complete, and therefore the child workflow can pass its value for Child String Variable back to the parent workflow’s Parent String Datafield variable.
The child workflow is very simple. When it starts, it sends an email to the originator of the parent workflow, waits for 10 seconds and then completes. Once the child workflow completes, the parent workflow sends an email to the originator and ends.
You can also use the Call Sub-Workflow step to build single parent - multiple children workflows. In K2 Five 5.2 and K2 Cloud Update 6, the Call Sub-Workflow Step was enhanced to allow you to decide whether to start only one instance of the child workflow, or multiple instances. You would have to provide a list of items when configuring the Call Sub-Workflow step, for example a Reference that contains a list of items. At runtime, you can then pass an identifier of some kind from the parent workflow to each child workflow, so that the child workflow has some context of which specific item in the list it relates to.
In this example, we have a parent workflow with a Call Sub Workflow Step which is configured to start multiple instances of the child workflow based on a list of items. In this example, the parent workflow starts, send an email, then calls the Process Definitions SmartObject to retrieve a list of workflows deployed in the environment, saving the results as an Item Reference. In the Call Sub-Workflow Step, we use the Item Reference and tell the parent workflow to pass the Process ID into the child workflow. This step is also configured so that the parent workflow will wait for all the children workflows to end before the parent workflow will continue. In each child workflow, the workflow will use the Process ID passed in from the parent workflow to retrieve more information about that specific item, send an email, wait for 10 seconds to simulate some long-running task, and then complete. Once all the children workflows have finished, the parent workflow will send a completion email and end.
Workflow Design Patterns refers to several common types of workflow patterns you may encounter when planning workflows, such as looping steps, rework loops, multi-level approvals and many more. In this section, we'll look at some common workflow design patterns that you can build with the browser-based workflow design tool in K2.
Sending requests back for rework is a common workflow pattern (for example in document review and approval workflows). You basically create a "loop" in the workflow to send a task back to someone (typically, the originator or a reviewer) to update or provide more information before it can be approved. The loop may run several times until the approver decides the request is approved or rejected. The key point here is that instead of sending the workflow back to the ‘Start’ step, you create a user task step in the workflow and send the workflow back to the same user task step. You may also want to leverage the comments and attachments feature in the workflow task panel to keep track of the review/approval/rework history.
In this example workflow, the workflow starts and goes to the Approval step. The approver can decide whether the request is Approved, Rejected, or they can send it back for Rework. If they select Rework, the workflow goes to the Rework user task step, where the originator can adjust the request as needed, and Resubmit it for approval (in this example, the originator can also decide to Cancel the request completely if they don’t want to resubmit it). If the Originator resubmits their request, the approver can send it back for rework as many times as necessary, until the approver takes an Approved or Rejected action. In those cases, the workflow sends an Approved or Rejected email, and the workflow ends.
You may need a workflow that loops/iterates over a number of items in a list or collection, and perform one or more tasks for each item in the collection. Consider something like a sales order workflow, where you have a sales order that contains multiple items. Perhaps you need the workflow to perform some steps for each item in the sales order, such as assigning a manufacturing task for each item in the order.
The looping pattern is the appropriate mechanism to use for this scenario. You use the Loop step in conjunction with a Reference to a list of items and configure the loop to perform specific tasks for each item in the reference. Once all items are processed, the loop exits. You can also define your own condition determining when the loop should exit.
This sample workflow starts and sends an email to the originator. In the Create Reference to list of items step, you call a SmartObject method to retrieve a list of all workflow definitions deployed to the current environment, which is an example of retrieving a list of items. Be aware that in some K2 environments, there may be hundreds of workflow definitions, so you may want to use caution before you run the sample workflow in your environment.
Once you have a list of Workflows in the reference, the loop step iterates over each workflow definition and performs tasks for each item. The first task is to decrement the value of a workflow variable. The workflow waits for one second to simulate something else happening, and then sends an email to the originator with the details of the current item being processed, such as the workflow name and ID, as well as the value of the variable. The loop returns to the loop step, the next workflow definition is picked from the list, and the steps repeat. You should see several emails come through as the workflow processes each workflow definition in your environment.
Finally, when there are no more items left to process, the workflow sends an email to notify you that it is complete, and the workflow ends.
You may have solutions that require a workflow with an indeterminate (but finite) number of approval steps. For example, you may have an approval workflow that requires a request to pass one, two or three approvals. These decisions may be made by users (for example, approver 1 requesting a second approval) or by the system (for example, if the request amount exceeds a certain number, always send for second and third approval). Further, you may need to have each approval step distinctly separate in the workflow, and you want the workflow report to show how many levels of approval were required for any given request.
In cases like these, you can consider using the N-Level Approval pattern. Here, you use a sequence of user task steps, and decision steps between them to decide whether a subsequent approval is required.
Our sample workflow represents an N-level Approval, where a request goes through at least one, but potentially up to three, levels of approval before it is approved. The participant at each approval step decides whether to approve or reject the request, or whether another level of approval is required. The workflow executes based on the decision in each step, and finally sends an approved or rejected email to the originator based on the final decision.
Some workflow designs can get quite large and complex once you have added all the system and user steps to a workflow. This can make it harder to understand the flow or current state of a workflow, especially when the workflow includes many system-only tasks that do not mean anything to a business user.
You can use the Business Façade pattern to create a simplified workflow model that hides the underlying complexities from your business users. With this Façade pattern, you separate the sections of the workflow that do not make sense to business users into sub-workflows, and then use the Call Sub Workflow step to call these other workflows. When the business user looks at the workflow in their reports, they see a simplified version in which the business process progresses as they understand it, while the more complex parts of the workflow occur behind the scenes.
Our sample solution consists of three separate workflows. The Main workflow is the façade, and calls the underlying sub-workflows. The main workflow starts and sends you an email. Then, it creates a User Task where you can tell the workflow to continue, to simulate some user decision in the simplified business process. The workflow then calls the first sub-workflow, which does some system processing and returns a few seconds later. (For the purposes of this explanation, it doesn’t matter what the sub-workflows do, but they would typically be more complex than the simple sub-workflows shown here). Once the sub-workflow completes, the main workflow resumes and reaches the Approval Task. At this point, you can decide whether to approve the request (in which case K2 starts the second sub-workflow to perform additional processing) or reject it. Once the second sub-workflow has completed, or if you rejected the request, the main workflow sends an email and the workflow completes. From the business user’s perspective, they only need to see the report for the main workflow to get an overview of the overall business process. They don't need to concern themselves with the underlying system tasks performed in the two sub-workflows.
The Spider/Controller pattern is often used when a workflow is not well-defined as a sequence of steps. In other words, it is not always the case that certain steps always follow one another, and steps in the workflow may or may not be required. In this case, you may find the spider pattern useful. At the core of the spider pattern is the Controller step which makes the decision as to which subsequent step or sequence steps should be run.
Consider something like an case management or incident investigation workflow. In this case, subsequent steps of the workflow may not be required, depending on results from another path. Perhaps the workflow can skip some steps in the workflow and go straight to the final processing steps. Or, perhaps the workflow does not need any human interaction at all and can complete right away. The point is, trying to model all the possible ways this semi-structured workflow could potentially execute would result in a complicated workflow model. The spider pattern might is a good solution to this problem.
Our sample workflow contains a variable that is randomly set to a value between 0 and 4 by the Randomize Path to Take step. The workflow starts and sends you an email, and then the randomizer will assign a value to the variable. The workflow continues to the Controller step, and based on the value of the variable, the controller tells the workflow to go down Path 1, Path 2, Path 3 or Path 4. If the variable is outside bounds (for example, it is 0), the workflow goes down the ‘Escape” path and sends you an email to tell you that it has completed.
The point is, you cannot predict which steps are required, in what sequence the steps run, or even if any task paths are followed at all. Essentially, the path this workflow will take is left up to chance.