Actions for a Process Instance

In the Process Explorer, running, failed, cancelled, or finished instances can be processed further – without switching to the process designer. This article explains when each action is useful and what the difference is between the standard and the "with edit" variants.

Available actions

Which actions are shown depends on the current status of the instance.

Action	Visible for status	Effect
Cancel	running	The running instance is stopped.
Retry	failed, cancelled (with resume point)	The instance is resumed at the failed activity.
Resume with edited message	failed, cancelled (with resume point)	Like "Retry", but the activity's input message can be edited first.
Continue with next activity	failed, cancelled (with resume point)	The cancelled activity counts as done. The instance continues with the next activity and a checked message.
Restart	failed, cancelled, finished	A new instance is created with the original start data. The old instance stays untouched.
Restart with edited message	failed, cancelled, finished	Like "Restart", but the start message can be edited first.

When to use what

Cancel

A running instance should be stopped – for example because it is waiting for an external response that will never arrive.

Retry

A service task failed with a temporary error (e.g. network issue). The data is still correct, the step just needs to run again.

Resume with edited message

A service task failed because the input data was wrong (e.g. missing field, invalid value). The input is corrected and the instance continues with the fixed data.

Continue with next activity

The cancelled activity should not run again – for example because the email was already sent and the error only happened afterwards, or because the step was meanwhile done by hand. The activity is skipped and the instance continues with the activity after it.

The message editor always opens first. The message is the state the instance continues with – as if the activity had succeeded:

If a result of the activity is already known, it is filled in. For multi-instance activities the editor shows how many runs succeeded, and their results are included.
Otherwise the message is the state before the activity. Whatever the activity would have delivered and is needed later can be added here.
The editor also shows where the activity writes its result and which saves to data schemas are not executed.
For a cancelled user task, the form data belongs in the message.

If a gateway follows the activity, it decides on this message how to continue. In the activity list the skipped activity appears with the status Skipped and the person's email address under "Skipped by". The action is not offered for end events and activities without a following step.

Restart

The original run is finished or failed – the whole process should be executed again from the start with the identical start data. Useful for example to resend a confirmation email.

Restart with edited message

Like "Restart", but the original start message (the initial JSON) can be edited first. Typical use case: a finished process should run again with slightly different input data.

Difference: Retry vs. Restart

Retry continues the same instance at the failed step. Previous steps are not executed again.
Continue with next activity continues the same instance after the failed step. The failed activity itself does not run again.
Restart creates a completely new instance with its own ID. All steps run from the beginning.

Edited message – what happens technically?

For the "with edit" variants an editor opens where the current input message (JSON) can be modified.

The original message is kept (audit trail).
A new version of the message is stored.
The instance is resumed or restarted using the new version.
An indicator with editor and timestamp appears in the overview.

This makes it traceable that and when an input was changed manually.

Note

The actions are only visible for authorized users. Which permissions are required depends on the role configuration of the tenant.