At this point in the process design phase, a good exercise could also be to get all the stakeholders and SMEs in a room and pass around a piece of paper which represents the form. Have them pass it back and forth in the order in which that form needs to travel. Have the business analyst document the order and the interactions, the "who" and the "when." Look for where the process could be improved, where things could be given to more than one person at a time for approvals. Look for redundant steps. Look for where the same person has touched the form multiple times, could these be combined or reordered to reduce redundancy? If data is missing and filled in later, could it be found and incorporated into the process earlier to streamline the process?

During this exercise, the SMEs may realize that they do not know the process as well as they thought. And that no one person knows the process from end to end. That is why these meetings are critical, so that all the information and requirements can be gathered in order to automate the complete, and correct, business process.

Complimentarily to the whiteboard approach, you are in effect designing the activity flow of your process. You start drawing boxes and lines as you start breaking down your business process into logical components. Each block corresponds to an activity in K2. We will define these terms in more detail a little later, but for now, when you are drawing boxes think of them as activities. You can start defining your process at this high of a level, but the more detail that you start capturing in your design, the easier it will be for all your stakeholders to buy into the fact that the process design is correct.

From the whiteboard, it is important to document your process into a diagram. There are several types of diagrams that are used for defining business processes. While your organization may have a template or a preferred method, we will introduce these diagrams to add into your automation toolbox.

The process diagram shown in Figure 8-1 depicts a typical block diagram representing a business process. The type of process represented by the diagram is not important. The manner in which the process is documented makes all the difference in the world to those employees involved.

Figure 8.1. Figure 8-1

Many organizations use the BPMN (Business Process Modeling Notation) standards for creating process flow diagrams. An example of a BPMN diagram is shown in Figure 8-2. While this may have more detail than the block diagram shown in Figure 8-1, it is still just boxes and lines, with some start and endpoints defined. It is still generalized, and still places people a distance from the process, as if they were outsiders looking in.

Figure 8.2. Figure 8-2

By placing more significance on the people who are involved with the process rather than the activities in the process, you can achieve a greater level of buy-in from the stakeholders. By recognizing that processes involve people, and that people are a business's greatest asset, you can place the same level of importance on the actors in the process as on the actual tasks they are performing. These processes now become people-focused, or human-centric, instead of task-based.

The pawn diagram shown in Figure 8-3, places a focus on the process participants and the roles they play within the process. This diagram approach replaces the typical block diagram shapes with a symbol to which all business users can easily relate: a person.

Figure 8.3. Figure 8-3

While you were defining your process by drawing blocks and lines on the whiteboard, you started to define the process using either a serial or parallel process without even recognizing it. These types of process definitions just define how the activities are routed, and we will discuss them in depth next.

Serial Process Definition

A serial process is the simplest form of routing data. Serial routing is defined as a combined set of sequential steps executed in order; one right after the other. Data passes through the process one step at a time and cannot skip steps. Serial processes should be the default approach to process definition. A serial process is shown in Figure 8-4.

Figure 8.4. Figure 8-4

Parallel Process Definition

A parallel process differs from a serial process because data can be simultaneously routed to multiple destinations within a single step in the process. A parallel process is often more complex to implement than a serial process because parallel processes require complex data manipulation to split and merge data according to specific business rules. Do not let the complexities of the parallel process definition hinder your intent to implement such a process. K2 blackpearl technology is designed to handle complex data manipulation with ease. An example of a parallel process is shown in Figure 8-5.

Figure 8.5. Figure 8-5

There are multiple types of parallel processes. Each parallel process is designed to improve the flow of the process in a unique way. Many times, a parallel approval activity can be handled using the built-in capabilities of the Destination Rules, which will be discussed later. For now, as you are drawing your diagram, keep in mind those steps that need to happen in order and which can be split and handed off to multiple people for action at one time.

The happy path is defined as the route the request takes through the process if everything were to run perfectly, and there were no errors or alterations. Essentially, your goal is to identify the most commonly used process path. In Figure 8-6, we've added "start" and "end" identifiers, as well as arrows to describe the happy path.

Figure 8.6. Figure 8-6

Please make note of the following unique aspects. First, not all actors may be required in order to represent the happy path. Some actors may serve supporting roles in alternate flows, and others may simply be discarded when you pose the question, "How would you like the process to flow?" Be careful to understand the value of each actor. Now is the appropriate time to identify a process that is driven by exception, rather than a predictable or optimal flow.

Second, you'll notice that the same actor (Shipping Manager) is shown twice in Figure 8-6. This is by design; in this process the request has to go back to the Shipping Manager for completion at the end of this process. By showing where each actor participates in the process, and by using a different color (or in this black-and-white example a different shade or fill) per actor, you can easily see who plays a role when in the process. In this example, having the Shipping Manager touch this request twice, once at the beginning and once at the end, can facilitate additional discussions. Why is this necessary? Can the tasks be consolidated so that the Shipping Manager only has to touch a request once? This can drive efficiencies by recognizing redundant work by an actor in a process.

Alternate paths are those steps where the workflow branches. For example, the happy path as shown in Figure 8-6 assumes that each actor approves the request. Well what happens if a person declines the request? Or sends it back for rework? Or what if the request is over a certain amount and must go through multiple levels of approval? The alternate paths are designed to capture this information and route the request appropriately.

In order to identify an alternate flow, at each step in the process, ask what other options could occur? For example, if the Order Fulfillment role in the process above cannot fulfill the order, what happens? How do they handle that exception?

Properly defining the alternate paths is critical in fully defining the business process. However, many times these exceptions are handled on a one-off basis. Therefore, until the automated process is actually used, some of these highly unlikely cases may not be discovered. This is why we use an iterative approach when designing process-driven applications. Capturing the happy path and the most common alternate paths will meet the business need 80% of the time and the less likely alternate paths can be added at a later date. K2 handles this flexibility in adding alternate paths through actions and outcomes, which will be discussed in detail later.

One of the first alternate paths that usually comes up in discussion is the scenario where an approver is presented a form with data, and they decide not to approve the content. Usually, the actions available to the approver are Approve and Decline. If an approver declines the data in a specific step within the process, usually the status of the request changes and the request goes back to a previous step, perhaps for rework. Other times, a decline action may end the process. One example of the decline scenario is shown in Figure 8-7.

Figure 8.7. Figure 8-7

In this example, the request would go back to the Order Fulfillment actor, perhaps to rework the data or for data to be revalidated before continuing on.

Another common alternate path is if a request needs to be canceled. For example, if the business rules affecting the process or other external factors render the current request no longer applicable, the request should be canceled in its current state. Upon cancellation, data can be restored to a specific state, the status can be changed, or a secondary process can be started. Either way, a cancellation brings the current process to a conclusion. Figure 8-8 displays a cancellation component.

Figure 8.8. Figure 8-8

Notice that the alternate path lines are a different line type (and when viewed in color, a different color). This is to strongly denote the differences between the happy path and an alternate path. Also note that status descriptions have been added to all lines in this process. These statuses can be used as a process field in order for the stakeholders in the process to know exactly where the request is in the process. These statuses should be descriptive, such as "Awaiting Review" or "Declined by Booking Agent" so that, at a glance, the status of the request is known.

The first step in the modeling process is to identify the actors that will be participating in the process. You have already done this by abstracting the blocks into people or roles. There may not be a one-to-one correlation between blocks and actors. There can be more or less actors than blocks. There may also be steps in the process that are not done by a person, but rather by a system or an automated task, such as looking up information from the order system.

Figure 8-9 represents a set of actors participating in an example process. Notice that each actor is a different color (or in this black-and-white example, a different shade or fill type) and includes a title. Additionally, you could have an actor that is the server or code, for those activities that do not require a person to intervene, but are a logical component of the process.

Figure 8.9. Figure 8-9

How do actors in a process translate into users in K2? K2 relies on user providers to bring user information into the context of the K2 platform. K2 configures Active Directory and SQL user providers, but other user providers can be added. The default user provider is Active Directory and uses the "K2" security label. The SQL user provider uses the "K2SQL" security label. Labels are used to identify user providers.

User providers can display users from various systems, such as Active Directory, SQL Server, or any custom user provider that has been developed to work with K2. Once the user provider has been defined, those users are displayed in the Object Browser under the User Browser tab and can be given permissions on processes.

Because we have been careful when defining our actors in the process as generic job titles rather than specific individuals, we have not been defining the individual users who participate in a process, but rather the roles.

Users can be added to processes directly as destinations but a more flexible approach is to add users to roles and use the roles as destinations. This way, when responsibilities change, the role membership can be modified without having to redeploy the process definition. Much like groups or roles in other K2 systems, such as Active Directory, roles in K2 blackpearl are groups of users. Unlike other systems, roles in blackpearl can be dynamic if based on SmartObject queries, and they can include users from multiple systems, which is particularly useful if your process involves external participants.

Roles are set up using the Management Console in K2 Workspace, and can be used across business processes. Therefore, it is important when you are designing roles for use in your process that you be specific about the roles. For example, naming a role "HR" is too broad and may confuse other processes designers. A better name would be "HR New Hire Approvers," as this describes both the department and the function being performed, in this case approving new hires.

As mentioned, roles can span user providers, meaning that roles can contain users with different labels. Role membership can also be configured to exclude users. This is useful, for example, when an Active Directory group contains individuals who should not receive notifications or worklist items.

A new role is given a name and one or more role items. These items can be based on the following entities:

As shown in Figure 8-10, all users are included in the Role1 role, except Mike. SmartObject methods can also be included or excluded from the role.

Figure 8.10. Figure 8-10

Users can be added to processes directly as destinations but a more flexible approach is to add users to roles and use the roles as destinations. This way, when responsibilities change, the role can be modified without having to change the process. Chapter 15 will go into more detail on creating and maintaining roles. Destinations will be discussed in more detail later in this chapter.

When role membership changes, users removed from a role will no longer see worklist items associated with the role. Conversely, users added to a role will see worklist items associated with the role after the refresh interval. A refresh interval is the time period associated with a role to query for new role items. The refresh interval is set on a role after it has been used with a process. For example, Figure 8-11 shows Role1 being used in a process with a refresh interval of 10 minutes. This means that every 10 minutes the K2 server will query for changes to the role membership and will adjust the tasks that users see accordingly.

Figure 8.11. Figure 8-11

User and role permissions are resolved using a concept called the context grid, which allows for the definition and management of user permissions. For example, a role can be used in the destination rule for an event and all users in that role will see worklist items related to that event. The context grid allows actions to be assigned to users based on their role membership.

Let's discuss the context grid in terms of a scenario. We have an expense report process that allows a form to be submitted for approval by an employee (the originator of the request). The process is configured to route the expense report to the originator's manager. This manager has several actions, such as Approve, Decline, and Rework. The originator may view the form at this stage in the process, as can senior management. Assuming that the manager has not actioned the item in 48 hours, the senior management should now be able to Approve or Decline the request.

Think of the context grid as a way to map the task (in this case, the Manager Approval) and the action (in this case, Approve, Decline, or Rework) as well as who (the user, group, or role) can perform the action (in this case, the manager, or senior management)

A user who has been assigned a task can delegate it to another user, meaning that they can allow their delegate to act on their behalf. This is available from the K2 Worklist, from the worklist item, as shown in Figure 8-12.

Figure 8.12. Figure 8-12

The delegator can determine which actions a delegate can perform. The work item will appear in both the delegator and delegate's worklist. The first user to select the work item will process the item.

This can be very useful for managers to delegate work to their subordinates, but control which actions they can do. For example, in an expense claim process, a manager can delegate a task to the project manager for review, but since that project manager has no direct approval authority, the manager can restrict the actions to only reject or rework. If the expense claim should be approved, the project manager can notify the manager, at which time the original manager can approve the claim.

Also from the action menu from the worklist item is redirect. This allows a user to send the selected worklist item to someone else to action. The worklist item will be removed from the original user's worklist, and will appear in the redirect's worklist.

This can be very useful for items that should go to another manager for approval. For example, perhaps you have an expense claim process that requires the employee's manager to approve. If the employee has been working on a project run by a project manager and has expenses related to that project, the manager can redirect the expense claim request to the project manager for approval.

In the context of K2 blackpearl, a process is built using activities and events. A Process Wizard is basically a template for a Process that uses that particular feature. Process Wizards give you a jump start on configuring the workflow.

These wizards set the stage for the process type, and enable K2 blackpearl to integrate tightly with the underlying technology, either InfoPath or SharePoint. You can use one of the above Process Wizards to start off, or you can start with just a blank K2 process and begin designing your process using the building blocks of activities and events.

Activities act as the containers for events within a process. An activity within a process can potentially contain Client Events, Server Events, or Interprocess Communication (IPC) events. The business logic includes concepts like: "who must be involved in the activity," and "are there any prerequisites that must be met before workflow participants can start with the activity." Activities are the logical grouping of related events. For example, let's use an example of "Pull from Inventory" as an activity. In the "Pull from Inventory" step in the process, there are actually several tasks that need to take place, such as "Check Inventory Levels at Local Store," "Lookup Inventory in Warehouse," "Decrease Available Inventory by Request Amount," and so forth. The activity groups the related events together.

Activities are also important components in the process because they represent points where decisions are to be made, data is to be delivered, or actions are to be carried out. One of the most important properties of activities is the business rules associated with the activity. These Activity Rules represent the tools used to build business logic into the activity. For an activity to be useful, it must have at least one event associated with it.

Think of activities as the boxes on the whiteboard. They contain the events and all the logic around what needs to happen. The way the activities are connected, or lines, dictates the path of the request through the process.

It is important while designing your process to recognize that activities can group events together, but only events that should be performed by the same entity. For example, in the "Pull from Inventory" activity above, all of the subtasks are performed by the Server, via code. Because they all happen automatically by the K2 server, they can be grouped together. If a task requires a user to intervene, then it should be split into its own activity, so that the Activity Rules can be defined separately. Also, the order in which the events appear within an activity is the order in which they are performed by the K2 server. In Figure 8-14, the "Pull from Inventory" activity is displayed with the appropriate events. The order in which the events will occur is from top to bottom, with the "Check Inventory Levels at Local Store" occurring first, followed by the steps below.

Figure 8.14. Figure 8-14

Now that we know activities are containers for events with business logic surrounding the activities, let's look more in detail at what exactly are events.

Events are the tasks that can occur within an activity. So while an activity is a box that represents the steps in a process, an event is the item or substep within that activity. In the previous "Pull from Inventory" example, the tasks that take place are actually the events.

Events can be broken down into three key categories:

When you move from the design environment to the execution environment, you encounter a few new concepts that you need to understand. An understanding of these run-time concepts will also help you in the process design stage.

A workflow process is usually "kicked-off" by a user that completes some kind of form and then submits the form by clicking a Submit button. As soon as the user has submitted the form, the K2 server receives a message that tells the server to Plan or Start a new process. The K2 server will then do this by creating a new Process Instance. From now, the K2 server will push the Process Instance to the various activities by evaluating certain conditions like Line Rules.

As soon as the Process Instance arrives at an activity, the K2 server will create a new Activity Instance. If the activity has any events associated with it, the Server will also create an Event Instance for each event.

During the execution of a process, the K2 server maintains certain properties for each of the Instances that are created. The properties for a Process, Activity, and Event Instance will be discussed next. These properties are surfaced in the K2 Reports and also in the worklist.

One of the things you will notice as you build out your K2 blackpearl processes is where you actually set the actions that the User performs and how that action affects the outcome of your activity. So what exactly are actions and outcomes?

Actions and outcomes allow processes to separate what decisions, or actions, users are able to make from the implications, or outcomes, of those actions. Because actions and outcomes are defined outside of the form, maintenance of those decisions and routing logic is simple in K2 blackpearl. In short, actions are the decisions that the user can make about the process step. Outcomes are K2's way of taking the business decision and deciding where the process moves to next.

Let's discuss a simple example. You have a standard expense claim in your organization that goes through the Finance department. Ask yourself two questions:

K2 blackpearl allows you to decouple the user interface from the process design. The K2 server will tell the form which actions are available based on the process, and will also tell the form which actions are available to the user. Remember, this concept is called the context grid, where only items that the user has permission to see are displayed.

Based on the action chosen by the user, the outcome of the activity is decided by the K2 server. Regardless of who did what on the form, the process only cares that this outcome evaluates to True, therefore, this is the path to follow. We will talk about configuring lines and rules in a little bit, but the concept that is important here is that you can add new actions without reconfiguring the user interface or the line rules, greatly reducing the development time and maintenance of your process.

There are some key points to remember regarding actions and outcomes:

Actions and outcomes are defined within the properties of a Client Event. While actions remain part of the event, the outcomes are actually defined within the scope of the activity. So, when a user selects the action in the form, K2 evaluates that action against all of the outcome rules. And, based on the outcome of the activity, the lines are evaluated, and those Line Rules that are True are followed.

We have not discussed lines in detail yet, so let's talk about the various types of lines and rules available in K2 blackpearl.

If you want to delay the start of an activity until certain conditions are met, you will define a Preceding Rule. The Preceding Rule is a logical expression that must evaluate to true before an activity can be created. Stated in another way: What conditions must be true before the activity is created for the instance? If the Preceding Rule evaluates to False, none of the other Activity Rules will be evaluated and an instance of the activity will not be created.

A Preceding Rule is not a "wait until this is true" type of rule. Every time a specific line is followed, the Preceding Rule is evaluated once, and if it returns true, then that activity will start (the only remaining question then is when it will start, and that then gets determined by the start rule).

For example, say your process splits into two parallel Activities A and B and then combines them at Activity C. You want both Activity A and B to complete before Activity C is started. You would create a Preceding Rule for Activity C. If Activity A completes, the Line Rule from A to C would evaluate to True, but the Preceding Rule for C would not be true; therefore, Activity C would not begin. Once Activity B completes, the Line Rule from B to C would evaluate to True, and then your Preceding Rule for C would also evaluate to True, and Activity C would begin. Figure 8-35 shows an example of a Preceding Rule based on the previous example.

Figure 8.35. Figure 8-35

Remember, a Preceding Rule is a property of the activity. To set, open the Activity Strip and click on the second icon, or open the activity properties and select the Preceding Rule tab. You can then add your rules based on variables from your process data Fields or SmartObjects, using Boolean logic (And, Or, XOr), and indenting rules to build extensive logic into your Preceding Rule, as shown in Figure 8-36.

Figure 8.36. Figure 8-36

The Start Rule is time-related and dictates when an activity can start. When you think about the Start Rule, think of time. The start of an activity can be delayed by a specified amount of Days, Hours, or Minutes after a base date. The base date can either be the Activity Start Date, or a date value that is kept in a process data or XML field. The Start Rule can only be evaluated if the Preceding Rule evaluated to True.

For example, if you have a business process that should start on the first of every month, use a Start Rule to dictate when the activity should begin. Figure 8-37 shows the Start Rule properties screen. Note that the K2 Object Browser has been expanded by clicking on the arrow on the right-hand side of the wizard. This can be done on any of the K2 wizards to make it easy to drag-and-drop fields onto the wizard screen.

Figure 8.37. Figure 8-37

If the activity involves a Client Event, which in turn has some kind of human interaction, the person or people who are responsible for that event must be specified. By stating who can action the activity, the workflow participants are stored in a Destination Rule. The Destination Rule determines who will receive the events defined in the activity.

We discussed destination users in an earlier section. However, when you set a destination for a Client Event, you are actually modifying the Destination Rule of an activity.

The Destination Rule generally uses the User Browser tab within the K2 Object Browser. This allows you to use users, groups, and roles that have been defined. By default, the User Browser integrates with the configured Security Providers, which out-of-the-box, are Microsoft Active Directory or SQL. Destination Rules can also be one of two types: static or dynamic.

Static

Static Destination Rules are explicitly defined by dragging a user or group to the destination, as shown in Figure 8-38. You can also mix users, roles and groups into the Destination Users for an activity. However, if you drag a single user into the Destination Rule, if you wish to update the Destination Rule you will need to modify the process definition, make the change, and deploy your process again. This is not a very flexible method, but is very easy when prototyping your process or testing the business logic and routing in your process. You can always go back into the Destination Rule and change to use a dynamic method later.

Figure 8.38. Figure 8-38

Dynamic

A Dynamic Destination Rule allows the "who will receive the task" to be defined outside of the activity. For example, you can use a process data or XML field as a Destination User. At run time, the value of this data field will be evaluated and the activity will be assigned to the appropriate person or people. This is shown in Figure 8-39.

Figure 8.39. Figure 8-39

Another way of handling Dynamic destinations is by using roles. Although in the Destination Rule, the role will be explicitly defined, because the items that make up that role are defined outside of the process definition, changes can be made without having to export the process again. Roles are defined in the K2 Workspace, as shown in Figure 8-40.

For more information on how to create roles, please see Chapter 15.

Figure 8.40. Figure 8-40

Activity Slots

Slots determine how many worklist items can be simultaneously open for the activity. As soon as a user clicks on a worklist item, the status immediately changes from Available to Open and one activity slot is occupied. The number of slots can be limited to a specified number, or a slot can be created for each destination.

For example, creating a slot for each destination can be useful for a voting or collaborative work scenario, which requires all recipients to work on the item. On the Destination Rule Options page, select the "Create a slot for each destination" option, as shown in Figure 8-41. Then, the worklist item will appear on each recipient's worklist, regardless if others have opened it already.

Figure 8.41. Figure 8-41

If no special Succeeding or Line Rules are specified, however, the activity will complete as soon as all of the listed destinations has completed the client event, causing the work item to disappear from all destination users' worklists.

For more information on some of the advanced destination scenarios, please refer to Chapter 22.

The other option is to specify the number of slots to be created, as shown in Figure 8-42. For example, if you want to send an item to a group of five people, but only the first two that open the item may work on it, set the number of slots to be created to two.

Figure 8.42. Figure 8-42

As soon as the first two users open the work item on their worklists, it is allocated to those users and disappears from the worklist of the other three users.

There are some general guidelines to keep in mind when using multiple slots:

• Succeeding Rule: If the number of Slots = 1, then no Succeeding Rule is required. However, if the number of Slots > 1, then a Succeeding Rule is required in order to keep the activity from completing before all slots have responded. We will discuss Succeeding Rules in just a bit.

• Data Fields: Multiple slots will cause the value of a process data field to be overwritten each time a user completes a work item. Use activity data fields to store responses from each user.

• Line Rules: The Line Rules determine the required direction to follow in the workflow. The direction needs to be modeled around the activity data fields and slots for multiple responses. Line Rules will be discussed in more detail later, but you will need to modify the default Line Rules if you have multiple slots and want the behavior of the process to behave differently based on the activity data fields.

• Actions and Outcomes: Succeeding Rules and Line Rules are automatically generated and configured according to defined actions and outcomes. By default, all slots will need to select the same action in order for the outcome to evaluate to true. However, this can be changed by modifying the Succeeding Rule.

Scenario #1: First Response Does So for the Group

Figure 8-43 shows an example of Scenario #1. In this scenario, an actor submits a request to multiple destinations simultaneously (A). The first actor to respond to the request (C) does so for the remaining actors (B and D). In this situation, the first response returned from the actors is processed, and the remaining work items are no longer applicable.

Figure 8.43. Figure 8-43

The First Response approval is beneficial in processes where the request is sent to a destination consisting of a group of people; in our example above, the HR New Hire Role. With a single slot and the default plan (Plan Just Once), as soon as one person opens the worklist item and actions it, the request can continue on in the process without waiting for the others to respond.

Scenario #2: Process Collectively Unless Declined First

Figure 8-44 shows an example of Scenario #2. In this type of step, an actor submits a request to multiple destinations simultaneously (A). The process requires that each destination in parallel (B, C, and D), review the same items, and provide similar and congruent responses before the request is submitted to the next destination. As responses are received, they are held in a waiting state and verified against the business rule (for example, waiting for the Succeeding Rule to be true). If destination C responds with an action of decline, the entire request is declined and the responses from destinations B and C are nullified.

Figure 8.44. Figure 8-44

Scenario #2 is beneficial in situations where a unanimous approval is required. An example might be a purchase agreement that requires engineering, manufacturing, and finance to agree to the terms. Engineering would look at the technical specifications, manufacturing at the service and support terms, and, of course, finance at the financial terms. If any one of these reviews is unsatisfactory then the agreement will need to be renegotiated.

This behavior can be done in K2 blackpearl by adding multiple Destinations to a single activity. The Succeeding Rule would check the actions, and if a "decline" action was performed, the outcome would need to be set appropriately to route the request down the decline path instead of to the next step in the process. Succeeding Rules will be discussed in a little bit.

If, however, you wanted different data to be displayed to each Destination (in this example, engineering, manufacturing and finance), you would need to have three separate activities with three separate Client Events, each mapping to the appropriate user interface.

Scenario #3: Merge All Responses Before Proceeding

Figure 8-45 shows an example of Scenario #3. In this type of step, an actor submits a request to multiple destinations simultaneously (A). The process requires that each destination in parallel (B, C, and D) reviews the request before the responses are merged together and routed to the next destination.

Figure 8.45. Figure 8-45

In this scenario, the process will remain in the step until all destinations have provided input. If one destination is lax in its response, this may delay this specific step and lengthen the overall duration of the process. A classic real-world scenario is an editorial review process where an author submits an article to multiple reviewers, who, in turn, pass along their recommendation to the editor for final review.

In the preceding scenario, you will need to store any data in activity fields rather than process data fields to prevent each destination user from overwriting the others' responses. The Succeeding Rule would wait for all destinations to respond, meaning all slots have responded, but regardless of the actions selected, the process would continue on to the next step.

Scenario# 4: Merge Similar Responses and Proceed Immediately

Figure 8-46 shows an example of Scenario #4. In this type of step, an actor submits a request to multiple destinations simultaneously (A). The process requires each destination in parallel (B, C, and D) to review specific data within separate sections of the request. Similar responses (for example, approvals) are merged together and routed to the next activity, while other actions (for example, declines) are routed to a different activity.

Figure 8.46. Figure 8-46

An example of this type of process is a procurement request. In this example, a hiring manager submits a request for a PC, a phone, and an office chair for a new employee. This request is routed to IT, Communications and Office Supply, where the PC and phone are immediately available and sent on for provisioning. The office chair is unfortunately on back order, and will have to be procured in another way.

While the Succeeding Rule would wait for all slots to respond, the process could go down multiple paths once it has completed this activity. This would be handled with Line Rules, which will be discussed in a later section.

Your organization might have a business rule that states a specific activity must be completed within eight (8) hours; if not, some special action must be taken. The Escalation Rule is used to specify when and how this special action takes place.

We will discuss escalations in a later section. However, when you set an escalation you are actually modifying the Escalation Rule of an activity.

A Succeeding Rule is a logical expression that must evaluate to true before an activity can be completed. Stated in another way: What conditions must be true before the activity is allowed to end?

The logic for when the activity is complete is stored in this rule. This idea ties to the outcomes that were discussed previously. The Succeeding Rule cares about what the outcome of the activity was, but not who actioned it or selected which option in a form. The Succeeding Rule defines the outcome of the activity, which is what the Line Rules that were automatically generated by K2 blackpearl use to evaluate which Line Rules should be followed.

Succeeding Rules are extremely important if you have multiple Activity Slots. A Succeeding Rule can be thought of as the following equation:

Succeed (Complete Activity) =
       (Conditions you define) OR (All Worklist Items = Complete)

For one slot the Succeeding Rule will evaluate to True as soon as the user completes his work item, regardless of the Condition you defined.

A Succeeding Rule can be used for multiple approvals. For example, a form is sent to three managers for approval. It is required that at least two managers approve, and none reject the form. If the first manager rejects it, the Succeeding Rule can immediately complete the activity, without waiting for the other managers to respond. If the first manager approves the form, the Succeeding Rule will wait for a second approval before completing the activity, leaving the worklist item available for the other managers.

In addition to the above rules, which are, in effect, properties on the activity, you can also create Line Rules. These are rules that are properties of the Line on the design canvas and can be used to route the business logic for the process. These Line Rules generally occur in a workflow process in a junction point, where the process can flow into one or more directions depending on certain conditions. These are indicated with lines, and conditions are constructed using Line Rules.

When we discussed actions and outcomes in an earlier section, we assumed that if an outcome resolved to True, then that path was followed in the process map. The way that K2 blackpearl handles this is by defining a Line Rule that basically says "If this outcome is true, then this line is also true." By default, K2 blackpearl will create Line Rules that map to each outcome in order to help you quickly design your process. This can be seen in Figure 8-47.

Figure 8.47. Figure 8-47

These default lines will help you easily map your process, and if new actions and outcomes are added to a particular activity, you can generate lines for the newly added option. You can also add new lines, or edit these default lines, to add additional business logic. Basically, if we want the process to follow a specific route we would write a conditional statement that would evaluate to True. On the other hand, the same conditional statement must evaluate to False, if that route must not be followed.

Line Rules are configured by right-clicking on the line and clicking Properties. On the Line Rule Property page of the wizard, you will see the Line Rule that was automatically generated based on the outcome. You can edit or add new conditions to this Line Rule, as shown in Figure 8-48.

Figure 8.48. Figure 8-48

A Line Rule can consist of multiple statements connected with Boolean AND, OR, and XOR operators. Because of operator precedence you will, under certain conditions, want to group statements together with brackets. Consider the following Binary Operations table, and notice the difference in the results columns.

You can also indent the operators to create complicated logic statements. Be sure to test each branch in your process definition during the testing phase of your project, to ensure that the process follows the correct path based on the Line Rule logic. It is very easy to make a simple mistake in your Boolean logic that will cause certain branches in your process to never fire.

One great advantage of automating a business process is the fact that we can, with absolute precision, tell when a specific activity was started. This enables us to enforce a business rule that states how long the activity should take to complete. If the activity takes longer to complete than the expected time, we can use escalations to raise an alert of some kind. The Escalation Rule for an activity determines what must happen if an activity is not completed within a specified time.

The escalation principle applies to both a process and an activity, since an activity that is not completed will prevent an entire process from not completing. Therefore, escalations can be configured at process and activity level.

There are two types of Escalation Rules:

An Escalation Rule determines what to do if the process or activity is not completed within the allocated time. Multiple Escalation Rules can be configured for a single process or activity. An escalation is linked to time elapsed from the start of the process or activity. And, if working hours have been defined, escalations are linked to working hours as well.

Escalation Types

There are several types of escalations. For processes, activities, and events, the following escalation types are available:

• Default Escalation: Configures the default escalation.

• E-mail: Configures an e-mail sent to a recipient for the purpose of managing the process escalation. This can be used as a reminder e-mail that the worklist item is still waiting for action.

At a process level, you can also use an escalation to change the flow of the process:

• Goto Activity: Configures the process to expire the current activity and move onto the specified activity. For example, you can move the process instance from the Frontline Manager Approval Activity to the Department Manager Approval Activity.

At an activity level, two additional templates are available:

• Expire Activity: Configures the process to expire the current activity.

• Redirect Activity: Configures the process to redirect the activity to a different destination user.

You can also use .NET code to manipulate the rule or the escalation action. After you've defined the escalation, you can view the code, as shown in Figure 8-49. The action code can be manipulated using a Windows Workflow Foundation (WF) schedule. The Default Escalation will stub out an empty WF schedule for you to drop the activities you wish to customize the escalation. The rule code also will create a WF schedule, with the rule code embedded as C# code.

Figure 8.49. Figure 8-49

On each Client Event, there is an option to send a notification of the event to the destination user. By default, this notification is an e-mail message, but this can be configured to use other notification engines. This notification is important to factor in to your process design. If you choose not to send a notification to the destination user, how will they know they have a task item? Only if the user accesses their worklist, either through the K2 Workspace or the Worklist Web part, will they see the new worklist item.

Beyond notifying a destination user they have a worklist item, notifications can be important in two other aspects:

It is important to factor in notifications in the process design for several reasons:

Working hours can be defined at the K2 server level. This allows the K2 administrator to set up the hours in which to count for escalations and start rules. Remember that you can set escalations on a time basis, meaning that if a user has not actioned the item in a certain time period, an escalation can be performed. Working hours allow you to set up zones to determine when an escalation should be active. The zone also takes into consideration in which time zone the destination user resides.

For example, if your standard business hours are 8 A.M. to 5 P.M., if a request is submitted at 6 P.M. with a 2-hour escalation, the escalation clock does not start until 8 A.M. the following morning. This is important for businesses with set office working hours; for 24x7 Help Desks, this may not be as important.

When setting an escalation, you can choose which zone to use. It is important to remember what the destination of the activity is and select the appropriate zone accordingly.

Working Hours determine during which hours and on which days the "escalation clock" is ticking. Working Hours are configured through the Management Console using Zones.