Multi-page forms (no roles)

To create a multi-page form with a navigation toolbar, simply drag and drop forms from the palette into the flow. You can also drag in a New Form, edit it and create the form on the fly. Do not assign any roles to the activities as shown below. The content of the Name field for each activity is displayed in the toolbar. You can set it to whatever you want.

You can set Form and Document actions as usual. Click Finish and try the flow. 

Role-based workflow

In a role-based workflow, you will assign one or more roles to one or more steps (activities) in the workflow. A step (activity) with roles can only be performed by an authenticated user who belongs to one of the assigned roles. Your administrator will have to create the required roles in advance. Once this is done, you will see the list of available roles in the properties for the activity. Simply pick one or more roles as shown in the image below.

Sending a workflow step to a specific user

Sometimes, for example, when approving vacation requests or expense reports, you want the workflow to go to a specific person (the employee's manager rather than any manager). In this situation, roles are not appropriate since any user with the role Manager will be able to pick up and perform the pending request. In this situation, do not select any role and in the User field of the activity properties, enter a template e.g. {ManagerId} as shown in the image below.

You must have a control in any previous activity with the specified name, i.e. in the example shown, you must have a control in the Vacation Request form from the first step with name ManagerId. This control must be populated with the  user id of the specific person that you want to route to. At run-time,  will resolve the target user id using the data in the ManagerId control and will route the workflow to that specific user.

You can populate this control manually (via a drop down or by typing the user id) or preferably via a business rule that automatically pulls the information from a back end system. At this time,  does not automatically provide this information; you will have to write a rule. See automatically populating user information for more details.

Using dynamic roles: determining the role at run-time

In some cases, the role is not known in advance. For example, you may have a workflow where the first step is a Purchase Order or a Loan Request and the second step is an approval; however the approval must be performed by a Manager if the amount is less than $1000 and a Supervisor otherwise. In this situation, do not select any role from the list of available roles. In the Role text field of the activity properties, enter a template e.g. {ApproveRole} as shown in the image below.

You must have a control in any previous activity with the specified name, i.e. in the example shown, you must have a control in the Order form from the first step with name ApproveRole. This control must be populated with the name of the specific role that you want to route to. At run-time,  will resolve the target role using the data in the ApproveRole control and will route the workflow to that specific role.

You can populate this control manually (via a drop down or by typing the role) or preferably via a business rule that automatically sets the role depending on criteria such as order amount.

Looping between multiple users in a role

In some cases, you may want multiple actions taken during a step in the workflow. For example, consider an Issue Tracking workflow where the first step is an Issue entered by an employee or a customer and the second step is Actions taken by support staff. There could be multiple actions before the issue is resolved; however all actions are performed by a member of the support staff. In this situation, you should select the appropriate role from the list of available roles or you can use a dynamic role as described above. In addition, make sure that the Save to Role and Save/Load checkboxes are checked. You should also make sure that Save/Load is enabled for the flow as a whole.

At run-time, a member of the support staff performs this activity, takes an action and logs it in the workflow. While this user is performing the activity, other users in the Support-Staff role are locked out. When the user is done, he/she can click the Save button in the flow rather than the Continue or Finish button as shown below. This will place the step back into the Task List of all members in the Support-Staff role.

If you want to avoid users accidentally clicking the Continue/Finish button, place a Required control in the form such as a checkbox that must be checked before continuing to the next step. In this case, the Continue/Finish button will not be enabled until the checkbox is checked thereby preventing accidental clicks.

Viewing the status of an issue

Users can view the status of an issue using the Task List and its built-in search capabilities. You can search for any workflows that you have participated in. For all such workflows, you can view its history. The history can also contain annotations e.g. a brief summary of the last action taken.

Ad-hoc workflow: pass activities between arbitrary users

In some cases, you may want multiple actions taken during a step in the workflow but in an ad-hoc manner. For example, consider a workflow to review a proposal. The first step is the Proposal entry and the second step is the Reviews. However, a number of users may review the proposal in any ad-hoc order. In this situation, you should leave the roles blank and use a dynamic User as described above. In addition, make sure that the Save to User and Save/Load checkboxes are checked. You should also make sure that Save/Load is enabled for the flow as a whole.

At run-time,  will resolve the dynamic user id using a control in the form and the proposal will first be routed to that user. The user can make comments and decide to pass it on to a different reviewer. To do so, he/she selects the next reviewer from a control in the form e.g. a drop down and clicks the Save button in the flow rather than the Continue or Finish button as shown below. This will place the step into the Task List of the selected Reviewer.

If you want to avoid users accidentally clicking the Continue/Finish button, place a Required control in the form such as a checkbox that must be checked before continuing to the next step. In this case, the Continue/Finish button will not be enabled until the checkbox is checked thereby preventing accidental clicks.

Rejecting a step: sending it back to the original user

In some cases, a workflow needs to go backwards. For example, consider an Expense Approval workflow where an employee fills in an expense form in the first step. The next step goes to the manager for approval. However, the manager may decide that he/she needs some more details or corrections and needs to send the workflow back to the original employee for correction.

This is done using the  task list and its built-in modify task feature.

The manager clicks the modify button for the task in question in the Task List. This brings up a form which the manager can use to choose any prior step to which he/she can reset the task. In the example above, the drop down will only show the first (Expense) step. Select that step, fill in the rest of the form to customize the notification email sent to the employee and click Submit. The flow will be rewound to the desired step and placed back into the task list of the original employee to make any corrections.