End nodes

Introduction to end nodes

The end node represents the end of the process when the work on a case is completed. The case is closed in a technical sense once it reaches an end node, see Implications of closing cases. A workflow can contain one or several end nodes. If several workflows are linked using jump nodes to form a process chain, it is possible that a workflow does not contain any end node because the cases leave the workflow using a jump-out node (see Jump-in and jump-out nodes). You can define more than one end node to distinguish different resolutions in reports.

Available settings for end nodes

The following settings are available for end nodes:

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

• Technical name:
  Mandatory. The technical name of the end node.

• Label:
  Optional. The localized name of the end node. For manual end nodes, this label is displayed in the list of workflow activities in the Web Client.

• Description:
  Optional. The localized description of the end node. For manual end nodes, this description is displayed when hovering the end node in the list of workflow activities in the Web Client and CM/Track.

• Type:
  Mandatory. Determines how the end node is executed.

  • Automatic: The end node is executed immediately after the previous activity, i.e. the case is closed automatically.

  • Manual: The end node is executed by a user. It is displayed in the list of workflow activities in the Web Client and a user needs to execute the respective workflow activity to close the case.

• Script:
  Optional. Script which is executed when a case reaches the end node, i.e., immediately before it is closed. Therefore, the case can still be modified in this script.

• Visibility script:
  Optional. Only relevant for manual end nodes. Script which is executed to determine if the end node is displayed in the Web Client and 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 end node is displayed, if it returns false, the end node is not displayed.

• Expose to customers:
  Optional. Only available for manual end nodes. If selected, the end node is displayed as a workflow activity in CM/Track. Visibility scripts and activity forms also work in CM/Track.

• Sort index:
  Mandatory. Defines the position of the end node in the list of workflow activities in the Web Client and CM/Track. Only relevant for manual end nodes. You might want to position the end node at the bottom of the list.

• 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.

Implications of closing cases

Once a case is closed, most of the regular actions are not possible anymore. The following actions are not possible for closed cases:

• Users cannot edit case data.

• Users cannot perform actions in the case history (write comments or emails or add attachments).

• The case’s contact cannot be changed.

The following actions are still possible for closed cases:

• Users can view the case. The closed cases constitute a knowledge base accessible to all the users with the required permissions.

• The case can be reopened by an administrator, see Case administration.

• The case can be reopened by a user or contact using a reopen activity, see Reopen activities.

• Actions run with administrator privileges can be performed, i.e., workflow actions are still possible.

  Example: A time trigger is attached to the scope where the end node is located. The trigger continues running and any actions performed when the trigger fires are executed even if the case is technically closed. To avoid this, do not use time triggers in the scope of the end node.

• Task scripts, see Tasks, can modify a closed case.

• Another case can be linked to a closed case.

Sometimes, the workflow needs to consider process flows which require actions on cases, which were completed from the users’ point of view.

Example: A case is closed because the issue reported by the customer has been solved. Some weeks later the customer writes an email that the problem has appeared again, so the case needs to be reopened.

There are two ways to handle this kind of situation:

• Use an automatic reopen activity which is executed when an email is received for a closed case, see Reopen activities.

• Close the case from a business perspective without technically closing it immediately. The users execute an end activity with a time trigger connected to the end node. The case waits after the activity and is closed automatically after the configured time period.