This tutorial will illustrate the following features in Intalio|Cloud BPM:

• Attach documents to a task
• Reference online links within a step
• Sequential or nested process design using sub-processes
• Model expected and acceptable resource use in a process
• Monitor actual resource use during execution
• Define escalation events and notifications

You should already have completed the First BPM Process tutorial, and be able to design, model, and run simple processes.

The sample process

The sample process used in this tutorial is a fragment of a common Request for Proposal (RFP) process, which starts with the receipt of an inquiry. If the opportunity is qualified, a proposal is prepared and sent to the prospect for acceptance. The process ends if the opportunity is qualified out or if the proposal is rejected. If the proposal is accepted, the RFP process can potentially trigger a separate production run process.

Participants in the process are Account Manager who interacts with the prospective customer, Sales Manager who reviews the business case and helps close the deal as necessary, Production Manager with project and staff management responsibility, and Delivery Manager with the end-to-end delivery responsibility.

The skeleton RFP process that we will flesh out in this tutorial is attached here. Please download and import the process, and follow along.

Short modeling enhancements

Add Link to Step

Online information or applications that are needed or useful to complete steps in your process can be associated with individual steps in the form of resource links. For the RFP process, when an inquiry is received, the Account Manager needs to register the opportunity in the company's CRM application.

Right-click on the "Receive Inquiry" step and choose "Step Details" from the pop-up menu. Below the "Tasks" section that you're familiar with, is the "Resources" section. Click the green plus "+" icon in that section to add a resource.

For online URLs, the "Resource Type" should be "Link". Other options, such as Forms, Web Services, and Mashups are not covered in this tutorial. Fill in the "Name" and "File/URL" fields, and the optional "Description" field if you wish. Click "OK", and the link will be visible to anyone reviewing or using your process template and instances.

Using subprocesses within a step

Subprocesses are commonly used to separate different levels of detail in business process tasks. For example, a step may be called simply "Prepare Proposal", but the tasks implied by that step may be complex enough to need their own business process. Rather than model that complex diagram as part of the RFP process, it can be modeled as a subprocess to the step, and can be modified or improved independently of the overall RFP process.

Subprocesses are also how you can define a sequential series of tasks within a single step. When a subprocess is added to a step, all tasks are removed from that step, and you will have to re-implement them within the steps of the subprocess. To add a subprocess to a step, right-click the step and choose "Create Subprocess". Note that this can only be done with normal Steps; Decision Steps cannot include a subprocess.

In the RFP process, the tasks for the Prepare Proposal step need to be executed in a particular order. For example, we need to obtain product requirement details before scoping out the project and defining a staffing plan. This subprocess is very simple. Remember that the power of subprocesses comes from being able to create complex execution that doesn't clutter the diagram, or affect the functionality, of a more general process.

Each of the three steps has their own set of tasks, which must be completed as expected before the subprocess will continue to the next step. Once all three steps have completed, the subprocess will be complete, and so will the "Prepare Proposal" step in the parent process.

To finish modeling the subprocess and return to the parent diagram, click the 'step return' icon near the top of the diagram.

Back in the parent process, the step now displays a plus "+" icon to indicate it contains a subprocess.

Planning step duration, effort, and expenses

Intalio|Cloud BPM allows you to plan and track three resources in each step of a process and its subprocesses:

• Duration: the amount of time users have to complete their tasks for a particular step.
• Effort: the maximum amount of time users should spend completing their tasks.
• Expenses: the amount of money budgeted to complete the tasks in a step.

While 'expenses' are self-explanatory, let's take a moment to explain the difference between 'duration' and 'effort'. Duration refers to the overall schedule for a step in a business process. Effort refers to the amount of time users should spend completing just those tasks. For example, you could explain the duration and effort in a step to your employees like this:

You have one week to finish these tasks, but don't spend more than three hours doing them.

In that example, the step's duration is one week, while the expected effort is three hours.

Modeling planned resources

To add planned resource amounts to a step, open the "Step Details" dialog and go to the "Plan" tab. You'll see entry fields for the three resources we explained, as well as a "Schedule" section. For the "Duration" and "Planned Effort" fields, the duration format can be accurate to the minute. Hover your cursor over either field to reveal a tooltip reminder of the expected duration format, e.g. "3w 2d 5h 30m". In both cases, a week actually means "work-week" and is equal to five days.

The "Schedule" section gives you an estimate of the start and finish dates for this step, relative to when the process was begun. Based on the flow of your diagram and durations of previous steps, these values will automatically update. All steps are initially set to one day of duration, and no effort or expense. For some steps, especially those after manual decision steps, this section may be blank as the modeler doesn't have enough information to calculate when this step can expected to be active. You can simulate this during design by temporarily activating the expected connectors.

For a process-wide total of planned resources, open the "Process Details" window (where we publish the process as a template). The total planned expenses, effort, and duration are displayed here. (Similar to individual step schedules, these numbers may be less accurate if some connectors are disabled.)

For a later demonstration, modify the "Proposal Accepted?" decision step and set the duration and planned effort both to "3d".

Create event handlers and notifications

When designing your processes, you can have steps do more than distribute tasks to users. Those additional actions include sending email notifications when a step is activated, completed, or exceeds the planned resource use.

Escalation notifications

For the RFP process, we will set up an escalation notification when a proposal is not accepted within the expected time. Although the Account Manager is responsible for most of the oversight in this process, we want to alert the Sales Manager if the customer doesn't accept the proposal in a certain amount of time, so that they can step in and help close the deal.

Right-mouse click on the "Proposal Accepted?" decision step and choose "Events and Notifications".

In the "Events and Notifications" window that appears, click the "Add Event" button in the toolbar and choose "Escalation Notification".

You can set escalation conditions based on the activation or status change of a step. You can also set notifications differently based on which metric is exceeding the planned amounts (duration, effort, and/or expenses). For our demonstration, mark "Step turning red" and "Step turning yellow", and all three of the trigger filters.

For the notification, we will send an email to the Sales Manager using one of the provided notification templates. Fill out the "Send To" and "Subject" fields, and leave the default body of "HTML Template" as is. Click "Finish", and then on the "Events and Notifications" window click "OK".

Workflow notifications

Workflow notification are another way of letting users know how a process is coming along. You can use workflow notifications to keep users without tasks informed about activity in the process, or send notifications to users with tasks to help make sure their responsibilities aren't overlooked. We'll add a workflow notification to the "Opportunity Qualified?" step to alert the Sales Manager that his input is needed for the process, even though it's not presented as a normal task.

Right-mouse click on the "Opportunity Qualified?" decision step and choose "Events and Notifications".

In the "Events and Notifications" window that appears, click the "Add Event" button in the toolbar and choose "Workflow Notification".

In Workflow Notifications, you can set which predecessor tasks must have been active prior to the current step, before the notification is sent. For our simple RFP process this step is not needed, and you can click "Next" without changing anything. This feature is useful in complex processes with multiple branches and merges in the flow.

For the notification, we will send an email to the Sales Manager using one of the provided notification templates. Fill out the "Send To" and "Subject" fields, and leave the default body of "HTML Template" as is. Click "Finish", and then on the "Events and Notifications" window click "OK".

We're almost ready to see the effects of our planning and escalation modeling. Next, we'll take a quick look at some settings you can make when creating an instance, and finally use that instance to demonstrate the process features we've implemented.

Per-instance excess settings

To instantiate the process, click the "Start" button in the diagram's toolbar. (If you have not set the process as a template yet, you will be reminded to do so.)

When you start the new instance, set the "Instance Name", "Instance Owner", and assign all Participants to users or groups as usual. (For demonstration purposes, it might be useful to assign yourself to all Participant roles, so that you receive all tasks and notifications.) Before you click "OK" to start the instance, though, click the "Options" button to reveal the process instance settings. We want to modify two fields in particular: "Critical Expense Excess" and "Critical Effort Excess".

We briefly described the various status stages of a step during execution in the previous tutorial. Remember that a yellow status indicates minor problems with a step, and red indicates a major problem. To relate this knowledge back to the settings we're seeing now, a step will turn yellow when it exceeds the planned duration, effort, or expense at all. If you plan a step to take one hour, and the last task is completed sixty-one minutes after the step started, the step will turn yellow in the instance monitor. However, the amount of excess that is considered critical and would turn the step red, can be set at process start time with the fields we're looking at now.

By default, any excess (e.g. 1%) is considered critical. This default can be changed by a system administrator, but you can set your own values in the "Critical Expense Excess" and "Critical Effort Excess" fields. Change both values to 10, meaning that if a step is planned to take $10,000 and 10 hours, that it will not be considered in critical excess until it takes $11,000 or 11 hours.

We're finally ready to start the demonstration. Click "OK" to instantiate your process.

Process execution and user input

Completing tasks as a user

As users work on tasks, they update each step with the expenses and effort used. Behind the scenes, the process keeps track of these amounts and calculations, and triggers escalation notifications if they were included in the model.

Users can view and update the tasks assigned to them from inside the Tasks application in Intalio|CRM. You can see your tasks by using the "Shortcuts" menu at the top of the screen, and finding the "Tasks" application in the "Activities" group. Most users can also see their tasks right on the home screen when the log in. If you assigned all the participants in our demonstration process to your own account, you should go to the Tasks module. Otherwise you'll want to work with the person you set as the Sales Manager, in order to see the first task in your process.

In the task, you can quickly see the most important details, as well as open the step or entire process the task comes from. The "Subject", "Status", and "Due Date" were all set when the task was created, and the "Process Step" and "Process Instance" are clickable links that display the step and monitoring diagram in Intalio|BPM.

Click on the "Process Step" to open the Step Details dialog. From this screen, the user can attach documents to the process which will be available to all future participants. They can also make use of the resources we modeled into the step.

Furthermore, the user can update the actual expenses and effort the step used from the Status tab, which will be used (among other data) as the process decides whether an escalation notification should be sent.

When the user has finished their task, they simply set the Status to complete and save the task. Intalio|BPM will continue the process (or possibly wait for other open tasks in the current step) automatically.

Workflow notification emails

Since we defined a Workflow Notification on the "Opportunity Qualified?" step, that notification will be sent once you complete the first task and step in our process. The Sales Manager participant will receive the notification in their inbox soon after the step is triggered. (The outgoing email is created and queued immediately, but it may be slightly delayed by heavy activity from other users.)

Making manual decisions during a process

Since we designed the process not to take either path after coming to the "Opportunity Qualified?" step, a user will have to manually activate the appropriate path in order for the process to continue. In our demo process, the Sales Manager can easily do this from the "Qualify this RFP opportunity" task they're assigned. When they open the task, they can click on the "Process Step" link to open the Step Details dialog.

Click on the "Next" tab, and mark the appropriate paths for the process to take in the "Active" column. In our example, only one path can be activated (note the "Activate at most one dependent step" checkbox at the top) but other process designs might allow you to activate multiple paths to follow simultaneously.

For our demo, mark the "Active" box for the "Prepare Proposal" step, and save and close the dialog. The process will continue, passing through the subprocesses in the "Prepare Proposal" step, and issue a task as part of the "Proposal Accepted?" step.

Tracking resource use, and escalation events

To see the escalation notification that we defined earlier in action, bring up the "Step Details" dialog for the latest task that's been assigned to the Sales Manager. The task is called "Was this proposal accepted?", and again you can see the Step Details dialog by click the "Process Step" link in the task editor.

On the "Status" tab, you will find records of the planned and incurred effort and expenses that have been entered by other participants. You can add your own amounts to each running total using the text fields next to the total.

For our demo, enter an Incurred Effort of "5d", and save and close the step details.

Remember that we set our critical excess amount to 10%, and that our actual effort of five days is far more than the three days the process designer planned for in the model. Therefore, we have just triggered the escalation notification that was added to this step, and the Account Manager will receive an email shortly asking them to review this RFP.

Back in the task editor, you will see that the incurred effort has been converted to hours and displayed there for convenience.

Process monitoring

From the task editor, you can also monitor the state of the whole process instance. Click on the "Process Instance" link to bring up a diagram of the whole process, with color-coded shapes as explained in the previous tutorial.

• Red: seriously exceeds expected expenses or duration
• Yellow: exceeds expected expenses or duration
• White: tasks in progress
• Green: all tasks completed
• Gray: step not yet activated or reached

You can see for our demo that three shapes are green, indicating they were completed on time without problems, and that the "Proposal Accepted?" step is red because of the escalation event we just caused. The other steps are gray, indicating that they have not yet been active (and may never become active, depending on the process design).