Actions in the Process Inspector

You can use actions in the Process Inspector to administer process instances and their components.

Process Inspector. When you select a process instance, the details panel includes the actions that you can perform on that instance. Similarly, if you select an activity or a task, the details panel includes the actions that you can perform on that activity or task.

Process instance actions

The following table lists the actions that you can take on a process instance. The list of actions that you see depends on the state of the process instance and whether the action policy contains your user ID or group.
Table 1. Process instance actions
Action Description
Delete Deletes a completed, failed, or suspended process instance. After a process instance is deleted, the row is gone and can be recovered only by using a backup. There is no way to revive a deleted process instance.
Delete orphaned tokens Deletes orphaned tokens from the process instance to allow processing to continue.

Orphan tokens occur when an instance migrates from one snapshot to another and there is an activity in the old snapshot that contains a token but the activity does not exist in the new snapshot. Deleting orphaned tokens does not recover the orphaned tokens, but allows the process to resume so that the remaining process tokens can proceed. An orphaned token is a pointer (token) that is associated with an activity or event that has been removed from a process.

Edit data Expands the Data section so that you can review the instance data.
Modify due date Changes the due date to the day and time that you specify.
Refresh Reloads the process data.
Resume Starts a suspended process instance.
Retry failed steps Resumes or restarts a failed process instance.

Use this action on one or more process instances after a system problem is resolved. For example, if a process instance fails because the server might not access the database and the connection has been restored, you can restart the failed process instance by using the Retry failed steps action.

Note: For user task:
  • If it fails with exception, after the issue (which caused the exception, such as the environment issue or a code bug in customer's app) gets resolved, click Retry failed steps in Process Inspector. The instance becomes active and the task shows in the task list again. You can re-launch the user task from task list in portal, the Client side human services, and Heritage human services resumes the execution from the last successful save.
    • Confirm that the related code (such as nested service) is idempotent, means it can re-run multiple times and will not cause harm to the system.
  • If it fails with an error (the user task finishes with an error event) then retry failed steps will only cause the same error event to be re-thrown and the instance will remain in the failed state. After the issue is resolved you need to start a new task instance by moving the process token back. See POST (move token)
For system task:
  • If it fails with exception, after the issue (which caused the exception) gets resolved, click Retry failed steps in Process Inspector. The instance re-runs the system task. Confirm that the service (which is the implementation of the system task) is idempotent, means it can re-run multiple times and will not cause harm to the system.
  • If it fails with error (it means the system task finishes with an error end event), after the issue resolved, retry failed steps in Process Inspector. The bpd engine re-throws the same error reported earlier and instance remains in the failed state.
Suspend Pauses the execution of an active process instance.
Terminate Terminates the execution of a failed or suspended process instance.

Before you terminate a process instance, check if the instance has dependent relationships. If the instance depends on other instances, terminating the instance also terminates the instances that it depends on. You can wait for all of the instances to complete before you terminate the dependent instance. Or, if you want to keep these dependency instances, you can remove the relationship before you terminate the instance. If you still want the relationship to be visible, you can add an independent relationship before you remove the dependent relationship.

To terminate instances in a dependent relationship, you must have the authorization to terminate all the dependent instances. For example, instance A depends on instance B and instance B depends on instance C®. Terminating instance A terminates instance B and instance C. Terminating instance B terminates instance C. If you have the authorization to terminate instance A and instance B but not instance C, you must either remove the relationship between instance B and C or get a user with the appropriate access to terminate instance C, before you can terminate instance A.

After a process instance is terminated, you can only delete the process instance and only on the playback server and nonproduction workflow servers. There is no way to revive a terminated process instance.

Activity actions

The following table lists the actions and describes the transition that happens for the activity when you click the action. Some of the actions are not available for ad hoc activities. The list of actions that you see depends on the state of the process instance and whether the action policy contains your user ID or group. For information about the states, see Runtime states for activities in process applications

Table 2. Activity actions
Action Description
Disable Moves READY and WAITING activities to DISABLED state.
Start Moves READY and WAITING activities to WORKING state. If the action is repeatable, the process instance gains a copy of this activity and the copy is optional. For WAITING activities, clicking Start overrides the wait state on the activity.
Enable Moves the DISABLED activity according to whether it is automatic or manual and whether its preconditions are fulfilled or not:
  • Automatic activities that do not have preconditions or that have fulfilled preconditions move to WORKING state
  • Manual activities that do not have preconditions or that have fulfilled preconditions move to READY
  • Activities that do not have fulfilled preconditions move to WAITING state.

Task actions

The following table lists the actions that you can take on a task. The availability of some of the actions depends on the status of the task and its parent instance.

Table 3. Task actions
Action Description
Assign to user or Reassign to user Assigns the task to a specified user.
Return to team Removes the assignment to the user from the task and returns the task back to the team.
Edit data Expands the Data section so that you can review the task data.
Modify due date Changes the due date to the day and time that you specify.
Modify priority Changes the priority to the level that you specify.
Skip Skips the task to send the process instance to the next step in its flow. You cannot undo the skip action.

Timer actions

The only available action is Fire now. This action overrides the timer and sends the flow along the path that exits the timer. For example, a review activity has an attached timer (a boundary event) that leads to an escalation path.

Message event actions

There are no available actions for message events. The presence of a message event indicates that the instance is waiting for a message to arrive.