This tutorial will introduce you to Intalio|Cloud BPM, using a simple process to illustrate core features and present the basic functionality. At the end of this tutorial you should be able to use Intalio|Cloud BPM to model and run simple business processes.

The process we will implement is a very basic generalization of how a sales executive might handle the end of a quarter. After reviewing the reports from each of their sales representatives and managers, they calculate whether sales targets exceeded expectations. If so, they arrange a press release and celebration for their team. Finally, regardless of results, they must arrange a meeting to plan increased efforts for the following quarter.

You can download the exported process we'll be recreating here.

Model the process

Creating a new process

From the Dashboard, open the "Processes" section on the left side of your browser window. The tools in this section are all part of Intalio|Cloud BPM, and we will start designing our process with the "Processes" tool.

To create a new process, click the "Create New Process" button near the upper left corner, and give your process a name in the dialog that appears.

Creating process steps

In Intalio|Cloud BPM, there are only three necessary modeling components: Steps, Decision Steps, and Legends. You won't find a tool palette like in Intalio|BPMS Designer or other BPM modeling tools. Instead, right-click anywhere on the canvas to select one of the three components from a pop-up menu.

Using the right-click menu, add four Steps and one Decision Step to the canvas. You can also add Legends, which are used to document the diagram itself but do not have any impact on the process execution.

Steps and Legends can be dragged anywhere on the diagram after they're created. To edit the Step name or Legend content, click on the text you want to modify. Label the four Steps as:

• Read Quarterly Sales Reports
• Create a report letter for shareholders
• Organize a sales team celebration
• Schedule meeting to improve next quarter!

…and label the Decision Step as:

• Did sales exceed targets by >20%?

Connecting process steps

To connect two Steps, move your mouse over the 'source' step, or the step you want to flow to another. A chain-link icon will appear in the lower right, which you can drag to any other Step on the diagram to create process flow.

Note that steps aren't required to have only one incoming or outgoing connection. A regular Step with multiple outgoing connections creates a parallel flow, where each 'branch' executes independently. A Decision Step with multiple outgoing connections creates conditional flow, where one or more of the branches are executed independently. Steps with multiple incoming connections can merge those branches and return the process to a single running thread.

To attach a label to any connection, right-click the connector and choose "Edit Connector".

In the dialog, type the label and click "OK". You can also specify which sides of the source and target steps the connector should attach to, which overrides the automatic algorithm.

Label the connector from the Decision Step to the "Schedule meeting…" Step as "No…", and the connector to the "Create a report letter…" Step as "Yes!"

Specify the Participants

Now we'll add Participants to our process. A Participant is simply a placeholder for someone who will be handling one or more of the steps in our process. They are equivalent to a Role (from the user management platform in Intalio|Cloud), but you can specify specific Teams or Users that you have in mind for completing certain tasks during your process. Each Participant can be designed with an equally flexible "substitute" user in mind, and all Participants can be changed when the process is started or even during its execution.

To view and modify the Particpants, look for the "View: Flow" menu in the upper left, and change to the "Participants" view.

Click on the "Add Participant" button to select a Role that will participate in the process. Highlight the Role (or Roles) in the left list that you want to add as Participants, then click the right-pointing arrow between the lists to move those Roles to the right list. Each Role will be added as a separate Participant; in other words, exactly one Role becomes exactly one Participant in your process.

You can also choose a default User or Team for each Role (depending on more detailed process settings, one or all Users in a Team may be given tasks to complete). Remember that the specific Users can be changed when the process is started, or during its execution if needed.

Add a Participant for the "Sales Vice President" and "Sales Representative" roles, and assign them users. They can both be your own user account for purposes of this tutorial. When you're done, switch back to the "Flow" view to start associating these Participants with the Steps in your process.

Create user tasks for each Step

For each Step in our diagram, we will create one or more user tasks that must be finished, before the Step itself completes and our process continues executing. We should also assign an owner for each Step, identifying who will ensure that all the tasks are finished. The owner will also be responsible for choosing an outcome in Decision Steps.

To create all these details, right-click on an existing Step or Decision Step, and choose "Step Details" from the pop-up menu.

Set owners for each Step

The owner is set with a drop-down menu in the "Details" tab. Note that only the Participants we defined earlier are available. (As mentioned before, the default users' names are listed alongside the role, but can be changed at run-time.)

Add tasks to Steps

To add tasks, click the green plus "+" icon near the upper right corner of the "Details" tab. A new row will be created in the list below, and you can add a task description and owner by clicking on the empty fields.

These tasks will all be issued simultaneously to their owners when the process reaches this step, and can be completed in any order. Modeling a series of dependant tasks is possible by creating a sub-process, and is described in the Request For Proposal tutorial.

Add the following owner and tasks to the "Read Quarterly Sales Reports" Step in our diagram:

• Step: Read Quarterly Sales Reports
  Owner: Sales Vice President
  • Read Jim's report
    Owner: Sales Vice President
  • Read Sally's report
    Owner: Sales Vice President
  • Read Emily's report
    Owner: Sales Vice President

Documenting changes

When you click "OK" to save your task and owner changes, you'll be presented with a dialog box asking for the reason behind your changes. Specifically, changing the owner of a step is what causes this dialog. If you choose, you can enter a short bit of text explaining why you made the change. This text is for auditing and review purposes; it's another form of documentation and communication on large processes where there may be many people working to improve the process.

You won't need to enter any text for this tutorial. Click "OK" to dismiss the dialog, and then go to the other four shapes in our diagram and add the following owners and tasks to each.

• Step: Did sales exceed targets by >20%?
  Owner: Sales Vice President
  • Calculate total sales
    Owner: Sales Vice President

---

• Step: Create a report letter for shareholders
  Owner: Sales Vice President
  • Write report letter for exceptional sales quarter
    Owner: Sales Vice President
  • Send Sales VP a quote for the quarterly report
    Owner: Sales Representative

---

• Step: Organize a sales team celebration
  Owner: Sales Representative
  • Arrange a convenient time
    Owner: Sales Representative
  • Reserve location
    Owner: Sales Representative
  • Order catering
    Owner: Sales Representative

---

• Step: Schedule meeting to improve next quarter!
  Owner: Sales Vice President
  • Schedule quarterly prep meeting
    Owner: Sales Vice President

Changing decision logic

We also need to change two things about the decision happening in our process. First, we will deactivate the decision flow connectors so that neither path is automatically followed at run-time. It's possible to make automated data-based decisions in your process, but that's outside the scope of this tutorial. Instead, the process owner (the Sales Vice President) will be expected to come back and manually set which branch to follow.

Right-click both the "Yes!" and "No…" connectors, and choose "Deactivate Connector" so that they are not automatically followed at run-time.

Next, open the "Step Details" dialog for the Decision Step in our diagram one more time, and make sure the "Activate at most one dependent step" checkbox is marked. This restricts the run-time logic of the decision so that only the "Yes!" <b>or</b> "No…" execution branches can be followed, not both.

By default, the owner of a Decision Step can activate as many of the outgoing connectors as they wish, creating multiple simultaneous executing threads from the different branches. This is a totally valid design in many cases, but not for our example. Questions with 'yes' or 'no' answers, or where only one answer can be right, should have this checkbox marked so that only one outcome of the decision can be acted on by your users.

With these 'final touches', our process is ready for execution.

Turn the process into a template

When your process is complete and ready to be run, you'll need to change a single setting for your process as a whole. Until now, our process could be described as "under construction". Now that we're finished, we want to turn it into a "template", that users can make a copy of to actually execute and complete. Go to the "Settings" menu in the toolbar, and choose "Process Details".

Here, locate the "Status" drop-down menu and change the value from "Under Construction" to "Template". That's all! This makes your process available to any authorized users to create an instance of. You can still modify and improve your process, and any changes you make will be used by new instances of the process, but not existing instances.

Here's an example of why the "template and instance" pattern is useful. The process we've created could be made more generic by removing references to specific salespeople, and just sticking with the Roles we designed. Now, two or more Sales Vice Presidents from different regions (e.g. America, APAC, EMEA) want to use your process. Each of them can instantiate, or create a running copy of, your process. Then they modify their own instance to add a few details, such as the sales rep reports they need to read in our first step, and mark themselves as the owner and Sales VP in the process. The Sales VP in each region has their own copy which doesn't conflict with the others, and furthermore your generic process is still available for others to copy next quarter.

Remember that you are still free to modify templates, but any changes you make won't be inherited by running instances of your process. Therefore, it's not a good idea to simply change your process into a template the moment you have basic functionality working. Nor do you need to be worried that once you make the template available, that your process is permanently finished, and that all mistakes or flawed logic is un-fixable.

Test your template

From the modeler

To instantiate a process immediately, click the "Start" toolbar button and enter an "Instance Name" and "Instance Owner". You can also modify the user or group assigned to each role in the Participant list as needed. These Participants do not have to be the same ones you designed the process for, since flexibility should be a strength of business processes.

For our testing purposes, make sure to change the Sales Vice President to your own CRM user before clicking "OK".

After a moment, a notification will briefly be shown in the lower right corner of the window, confirming that your process has been successfully created.

From the template list

Most users will start their instances a different way. Switch to the "Instances" module, and you (and any user) will see a list of all the process templates you're authorized to run. Clicking the 'run' button for your process will also let you create a new instance in the same way as the "Start" button in the process modeler.

Completing tasks

When our process has started, you should receive three new tasks from the first Step we created:

• Read Jim's report
• Read Sally's report
• Read Emily's report

You can view and mark them as 'completed' from the Tasks application in Intalio|CRM. You can go there using the "Shortcuts…" menu, and most users will also have a spot on their Home dashboard for their tasks.

Note: depending on your view settings, some or all of your assigned tasks may not be immediately visible. You can use the "All Tasks" view to ensure that the tasks are being properly assigned to you.

Open the first task and set its Status to "Completed", then save the task. This is all the information your process needs to confirm the task as finished, and will either continue to wait for other tasks in the current Step to be completed, or move on to the next Step in the process.

Set the other two tasks' Status to "Completed" also.

When all three initial tasks have been completed, you will find a fourth task newly created waiting for you. This is the single task we assigned to the Decision Step in our process, indicating that the process has continued to execute properly. Mark this task as completed also.

Now we'll go back to our process to see how to resolve a manual decision path, and to monitor the process' over status.

Resolving decisions at run-time

Now that we've completed all the tasks our process has given us so far, we need to provide it with some input on which connector to follow from our Decision Step. To do that, switch to the "Instances" module, and click on the template we're using.

In this list, all the running and archived instances of our template are shown. At this point there should only be the single running instance we created earlier. Click on that link.

The current process state is displayed in a very similar layout as the process modeler, although you can not modify the shapes or design flow in a running instance. Notice that the first two Steps in our process are colored green, indicating that all their tasks have been marked as complete, and the Step has itself been completed. White shapes in the diagram indicate that some tasks are still outstanding for that step, and gray shapes have yet to be activated or their tasks assigned to participants. Faded or transparent shapes are not expected to run in this process, based on the expected outcome of earlier Decision Steps. Shapes can also be yellow or red, indicating mild and serious issues with that task, such as not being completed on time. (Time and resource constraints on steps are covered in the <a href="rfp.jsp">Request For Proposal tutorial</a>.)

Because we disabled the outgoing connectors from the Decision Step, we need to activate one of those connectors in order for our process to continue. We do this the same way we disabled them - right-click on the "Yes!" connector, and choose "Activate Connector". The following Step should turn white, and the remaining two Steps after it will turn gray. You can now find the included tasks in your Task list, as we saw earlier, and continue completing tasks as needed until the process completes.

Reviewing and monitoring process instances

We've already seen how to monitor individual process instances: the diagrams and list details in the "Instances" module provide an overview of the steps in a process instance. Within the diagram, you can go further and get specific details on each step. Right-click the step and choose "Step Details". In the "Step Instance Details" window (which will look identical to the one we used while modeling our process) click on the "Status" tab. Expected amounts for effort and expenses (covered in later tutorials) are compared to actual amounts, and a history of milestones for that step are all shown.

We can also get a more general look at step status for all> instances created from a given process template. From the "Instances" module, choose "Status Dashboard" from the pull-down menu for your process instance.

In this diagram, each step in the diagram displays a summary of all the statuses in every process instance. Here's a brief reminder of what the various colors mean:

• 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

This information is especially useful for process designers, because it can show areas where the process needs refinement. For example, steps that often go over the expected budget (yellow or red) can be reviewed to make sure those expectations are reasonable. Steps that are rarely or never executed (gray) should be confirmed as uncommon or exceptional flow, or else your process design may be missing important steps somehow.

This concludes the introduction to modeling, creating, and completing simple business processes with Intalio|Cloud BPM.