Reopen activities

Introduction to reopen activities

Once a case is technically closed, i.e., it reaches an end node (see End nodes) in the workflow, it cannot be edited in any way and there are no activities for this case. Depending on the business process, it might be required to reopen such case. This can be modeled using a reopen activity.

Example use cases for reopen activities are:

• The system receives an email related to a closed case. Instead of creating a new case with a relation to the closed one, the closed case should be reopened.

• The customer is not satisfied with the solution given in the case. He wants to reopen the case in CM/Track.

When using a reopen activity, the case does not return to the start node, but re-enters the process at the location defined by the outgoing connections of the activity. Reopen activities do not have any incoming connections. They are visible in the scope where they are located and in any sub-scopes of this scope.

Process logic of reopen activities

The case is reopened as soon as the reopen activity is executed. The further processing depends on the outgoing connections of the reopen activity. The process logic of reopen activities is the same as for regular activities (see Process logic of activities).

Please consider the impact of reopening closed case on the workflow as a whole. The following list shows some examples of areas which might need adaption when introducing reopen activities.

• Automatic actions on case closure

  If the workflow contains automatic actions which are performed when a case is closed, you might need to adapt them for reopened cases to avoid executing them more than once. It might even be required to undo some of these actions when a case is reopened.

  Example: An FAQ ticket is automatically created when a ticket is closed with a solution. Now, the original ticket is reopened because the solution did not work as expected, and the FAQ ticket needs to be updated accordingly.

• Case relations

  If the workflow implements a specific behavior regarding parent-child relations, reopening a case could require changes to other cases as well.

  Example: A parent case can only be closed if all its child cases are closed. Now, a child case is reopened and the parent case needs to react on this change.

• Reports / dashboards

  If the number of closed cases is analyzed in reports or dashboards, you need to decide how to handle reopened cases. Otherwise, the report data might be inaccurate for reopened cases, e.g., because the same case is counted more than once.

Use a script in the reopen activity or place an automatic activity containing a script after the reopen activity in order to add the required logic.

Available settings for reopen activities

The following settings are available for reopen activities:

• Path:
  Read-only. The path to the reopen activity within the workflow. Used to reference the activity in scripts.

• Technical name:
  Mandatory. The technical name of the reopen activity.

• Label:
  Optional. The localized name of the reopen activity which is displayed in the list of workflow activities (only activities exposed to users or customers) and the case history in the Web Client.

• Description:
  Optional. The localized description of the reopen activity. For activities exposed to users or customers, this description is displayed when hovering the activity in the list of workflow activities in the Web Client and CM/Track.

• Script:
  Optional. Script which is executed when the case passes the reopen activity.

• Visibility script:
  Optional. Only available for manual reopen activities. Script which is executed to determine if the reopen activity is displayed in the Web Client or CM/Track. The script has to return true or false. It is executed after the previous activity has been performed. If the script returns true, the activity is displayed, if it returns false, the activity is not displayed.

• Overlay:
  Optional. Select the overlay which should be displayed on the case icon after the case passed the reopen activity. You can choose one of the default overlays or upload you own overlay (PNG file, 16 x 16 px).

• Overlay range:
  Optional. Only displayed if an overlay has been selected. Determines how long the overlay is displayed on the case icon:

  • Activity: The overlay is displayed while the case waits behind the activity. As soon as the next activity is executed, the overlay is removed from the case icon.

  • Scope: The overlay is removed when the case leaves the scope.

  • Process: The overlay remains at the case icon for the rest of the process.

  • Next overlay: The overlay remains at the case icon until a new overlay appears. In that case, the old overlay is removed and the new overlay is shown.

• Expose to users:
  Optional. If selected, the activity is displayed as a workflow activity in the Web Client.

• Expose to customers:
  Optional. If selected, the reopen activity is displayed as a workflow activity in CM/Track. Visibility scripts and activity forms also work in CM/Track.

• Sort index:
  Mandatory. Only available for reopen activities exposed to users or customers. Defines the position of the reopen activity in the list of workflow activities in the Web Client.

• History visibility:

  Mandatory. Defines on which detail levels the execution of the element is shown in the case history in the Web Client.

  The possible values are:

  • Default
    The display of the execution depends on the global setting (see Case history) for the respective activity type:

    • Manual activity or activity with overlay executed
    • Activity executed after escalation
    • Automatic activity executed

    This is the default value.

  • Only high detail level
    The execution is displayed if High is selected.
  • Medium and high detail level
    The execution is displayed if Medium or High is selected.
  • All detail levels
    The execution is always displayed.
  • Hide on all detail levels
    The execution of the activity is never displayed.

• Skip update event:
  Mandatory. Defines whether the case is updated after executing the workflow element. By default, an update event is triggered to update the case. If there is a chain of elements, you should avoid triggering an update operation after every single element. Select this checkbox for all elements except for the last one to update the case only once, after the last workflow element.

A reopen activity which is neither exposed to users nor to customers can only be executed by script.