Building Cancellation into your Workflow Models

The Self Service and User Request templates can provide links that allow users to send cancellation messages to process instances that they started. For these links to appear, cancellation needs to be built into the process model.

If a process instance includes elements that can be cancelled by the user, Self Service and User Requests will automatically output a link to cancel it. The screenshot below shows a process in User Requests with a standard user task and a link to send the cancel message:

Building Cancellation into your Workflow Processes

Cancellation in a workflow process is handled using messages. These messages are sent to the process instance via an iCM form and "caught" by a message event. The message event can be attached to an activity in the workflow model, or to a structural element, like a sub process.

In this example the process is started by a single user-submitted form. It then passes the request to a user task in a sub process, carried out by a member of staff.

The sub process has a boundary message event attached to it. This will allow the original user to cancel their request (as long as they cancel before the staff members complete the sub process).

Boundary Message Event

The boundary message has the following settings:

• Name: The name of the form that will be used to send the cancel message
• Description: The description of the cancellation event
• Message reference: GOSS_StarterCancel. This is a special cancellation reference used by the Self Service and User Request templates
• Cancel activity: Checked, because we are using the message for cancelling, rather than another purpose

The Cancellation Form

The form we use to send the message must include the "Workflow - Message Action" field type. This field should use GOSS_StarterCancel as the value for the Message Reference (matching the message reference in our boundary message event). Other properties in this field can be used to record history and summary events.

The name of the cancellation form must match the name entered into the boundary message event. It is this name that allows the correct form to be shown to the user when they press the cancel button from User Requests or Self Service.

What Happens?

Messages can only be sent, and the cancel button will only appear, when the process execution is at an element to which the cancel message event is attached. In the example above, if there were activities prior to the sub process, they would need to be completed before the cancel boundary message becomes active. Similarly, once the sub process is complete and the execution moves on the to end point activity, the ability to cancel will be lost.

The Self Service and User Requests templates look for active message activities with the GOSS_StarterCancel reference and display the cancel button automatically if one is found.

When a message is received, the execution of your process instance follows the flow from your boundary message. In the example above, the sub process is cancelled (because the cancel activity box is ticked) and the process will write some history, then end. The flow leading to the end point activity is never followed.