The fundamentals of taking a work process and creating an IssueNet workflow to manage it are straight forward. This article will describe the procedure using the example of a common process which requires the completion of several activities by multiple individuals; the process of reviewing and fulfilling a hardware or software requisition.

The workflow will regulate the review, approval, implementation and closure of the issue. This workflow will also demonstrate the interaction between multiple tasks required to resolve the issue, the implementation of workflow rules based on custom issue properties, and other workflow features such as e-mail notification.

In this scenario a user will be able to submit a hardware or software requisition request and have the initial review of the request performed by a member of the IT group. A resource in IT will review the request and fill out required fields specific to the issue type. In particular, the IT rep will be required to specify if the requested item is on an approved list of hardware and software, if fulfilling the request requires a purchase, and if applicable, the cost of fulfilling the request. If the cost to fulfill the request is $25.00 or less, the request needs no further approval and it is immediately sent to be fulfilled. If the request costs more than $25.00, the request will need to be approved by the project manager and then sent to purchasing. Once the item has been purchased and delivered, the request is then sent back to the IT group for installation and for final signoff by the requestor once the item has been installed.

As described above, part of the workflow process involves the evaluation of information specific to an IT requisition. In particular, the requisition will have a field the IT rep will use to indicate the cost of the requisition and the value in that field will be used in the workflow to determine if management approval is required.

Prior to starting work on the workflows themselves, an issue type with fields specific to this type of issue was created using the IssueNet Architect.

Because the IssueNet workflow model is based on the concept of resources working on tasks linked to an issue, the best way to start a workflow design is to break the overall workflow process down into a series of specific tasks. Once you have identified the tasks involved in the process, you can design a workflow for each task and link the individual workflows together. Once the basic workflows are in place, the third step is to add actions and conditions to the workflows to automate and enforce the desired business process.

Let us first look at the task breakdown. In this example, the process will potentially involve five different tasks assigned to different resources, so five workflows were created, one for each task:

• A task for IT to initially review the request
• A task for management to review the request
• A task for purchasing to purchase the item
• A task for IT to install the item
• A task for the requestor to sign-off on the installation of the item and close the issue

The next step was to add states and transitions to each of the workflows to define the decision-making process for each task in the workflow. The basic design of the state and transitions followed a couple of basic principles:

1. States and transitions that support the types of actions and conditions used in the workflow. Based on the transition the user takes to complete the task different workflow actions will be executed. For example, rejecting and closing the issue as opposed to creating the next task in the process.
2. Keep the names of the states and transitions as consistent as possible across workflows. You will notice, for example, that all of the workflows have a Not Started and a Completed state. Maintaining consistent terminology simplifies reports by allowing users to run, for example, a report for all Not Started tasks regardless of their workflow.

Now that the basic workflows are in place, actions and conditions that further define and enforce the workflow process can be added. Actions and conditions are added to workflow elements by selecting a workflow element and clicking in the properties window to add the action or condition. There are some simple rules for how actions and conditions are added to workflow elements and how they behave.

1. Actions and a condition can be added to the workflow diagram. Actions added to the workflow diagram are executed when the workflow is executed. A condition added to the workflow is evaluated when the workflow is executed and will prevent the workflow from executing if it evaluates to false.
2. Entry and Exit actions can be added to states. Entry actions are executed when a workflow is transitioned into a state and, similarly, exit actions are executed when a workflow transitions out of a state.
3. Actions and a condition can be added to transitions. Transition actions are executed when the transition is used to promote a task from one state to the next. A transition condition will prevent the user from completing the transition if the condition returns a false value. A condition transition is evaluated before the actions are executed and a condition can be provided with message text that tells the user why the transition failed or succeeded based on the associated condition.

Instead of walking through the workflow elements step by step, let’s examine some of the more important and common action and condition types used to complete the workflow. There are many different action types. However, in this workflow the most important are:

1. Create Object actions create each task in the overall workflow process. When a workflow is executed, a create object action will create a task, set properties, such as the resource assigned to the task, and bind the task to the correct workflow. If you were to click on the workflow diagram for the Requisition IT Review workflow, you would see an action that creates a task bound to that workflow. Similarly, other workflows have Create Object actions that create tasks and specify the workflow and other field values required by each task. As we will see, by using Create Object actions in various elements in the workflow and combing them with Conditional Actions, you can generate tasks based on decisions made throughout the workflow process.
2. Send Notification actions can be used at any point in the workflow to notify anyone of a particular workflow event. In the Requisition IT Review workflow, there is an Information Request transition which allows the resource assigned to that task to execute the transition to send a notification to the submitter indicating that more information is required without changing the workflow state. You can add a Send Notification action at any point in the workflow.
3. Conditional Actions allow you to execute actions based on the evaluation of a condition. The original workflow description specified that the issue only needed to be reviewed by management is the amount of the request exceeded $25.00. If the requisition was less than $25.00, the request would be sent directly for installation. To accomplish this, a Conditional Action was added to the Approved transition on the Requisition IT Review workflow. Based on the evaluation of a condition that determines if the value of the Cost property is greater than $25.00, the action will execute the Requisition Management Review or the Requisition Installation workflow. By using Conditional Actions we can easily determine which tasks are created, and many other types of actions, based on the current context.
4. Execute Workflow actions execute workflows and typically generate tasks based on the actions added to the workflow. For example, based on the conditional action added to the Accept transition of the Review IT Request workflow the conditional action Execute Manager Approval or Installation Workflow will execute one of two workflows to generate the appropriate task.

In the process we have defined so far, the Requisition IT Review workflow will execute the IT Management Review workflow only if the cost defined for the issue exceeds $25.00. This feature of the workflow was implemented using the conditional action Create Manager Approval or Installation Task as described previously. However, for the evaluation of the cost property to be accurate we need to ensure that the IT resource assigned to the Requisition IT Review task enters a cost estimate before approving the request.

To ensure that a cost estimate has been entered we will add a condition to the Accept transition that verifies that the cost is greater than zero dollars. The diamond symbol on the Accept transition indicates the Does Workflow Issue Have Cost Estimate condition. Because this condition is added to the Accept transition it is evaluated before the conditional action which will determine which type of task is created, and prevent the user from completing the transition until the cost value is supplied.

One other feature of transitions is the ability to add success and failure messages. If the condition on a transition is not satisfied, then it is important to provide the user with feedback on why the transition did not succeed. Every transition can have a success or failure message that presents the user with an OK dialog of the message based on the outcome of the condition. In this case we have entered the condition failure message, "You need to enter a cost estimate for the issue" which will be presented to the user if the condition Does Workflow Issue Have Cost Estimate returns a false value.

To finish the overall workflow additional Execute Workflow actions were added to certain transitions in each workflow. By executing workflows these actions created new tasks in the workflow process. For example, on the Approved transition in the Requisition Management Review an Execute Workflow action executes the workflow which creates the purchasing task in the Requisition Purchasing workflow if the requisition is approved by management.

Modify Object actions were added to update the issue status as various states in the overall workflow were completed. For example, on the Approved transition just described, an action was added to set the issue status to Manager Approved. A subsequent Send Notification action sends an issue status update to the submitter to inform the user of the update. Also, a Modify Object action was added to set the percent complete to 100% when the tasks were transitioned to the Completed state.

Once the additional actions were added to each workflow were added, it became ready to implement. In the IssueNet client simply add the Requisition IT Review to a project to make it available for use. Once the workflow is executed all of the required tasks and notifications will be generated based on the actions and conditions we have added to each of the workflows we created.

It is also important to add the required resource types to the projects which will use this workflow. As defined in the Create Object actions, each of the tasks created during the workflow is assigned to a resource based on resource role. Consequently, any project that uses these workflows should have the required resource roles added to it.

Although there are many different ways to design IssueNet workflows, the design of most follows a basic pattern:

• Define the tasks involved in the complete workflow process
• Design a workflow for each task with the desired states and transitions
• Add Execute Workflow and Create Object actions to automatically create tasks as they are required during the workflow process
• Add other types of actions and conditions to the workflow as necessary such as Send Notification and Modify Object actions
• Add the workflows to the projects they will be used for and verify that the resource roles referenced in the workflow exist for each project.

Once the basic workflow is in place, you can continue to add more actions and conditions to further refine your process.