Reopen activities

Introduction to reopen activities

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

Example use cases for reopen activities are:

• The system receives an email related to a closed ticket. Instead of creating a new ticket with a relation to the closed one, the closed ticket should be reopened.
• The customer is not satisfied with the solution given in the ticket. He wants to reopen the ticket in CM/Track.

When using a reopen activity, the ticket 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 subscopes of this scope.

Properties of a reopen activity

Reopen activities have the following properties:

• name

  Mandatory. This is the technical name of the reopen activity. When a new reopen activity is created, you can edit the label and the activity name is generated automatically from the label (special characters are omitted). Afterwards, the activity name is never changed automatically but can be edited manually. Allowed characters for names are:

  • letters (small or capital), but no special characters
  • underscores
  • numbers

• label

  The localized name of the reopen activity. All languages which have been configured for the system are available and can be filled. In the Web Client, the label is displayed according to the browser locale. If it is not available, the label of the default locale is shown.

• description

  Optional. A localized description which is displayed as a mouse-over in the Web Client. This might help the engineer to understand what will happen when the respective reopen activity is executed.

  

  Figure 47: ConSol CM Web Client - Reopen activity in closed ticket with localized description

• sort index

  Defines the order of the activities in the list of workflow activities in the Web Client. The activities with a lower number are displayed first in the list.

• precondition

  Optional. A script can be entered using the script editor (see section Reopen activities). The script has to return true or false. It is executed when the previous activity has been performed, i.e., when it becomes possible to display the activity with the precondition. In case true is returned, the activity is displayed, in case false is returned, the activity is not displayed. An activity which has a precondition is marked by the icon exclamation mark.

  • Return value is true.
    The activity is displayed and can be performed by the engineer in the Web Client.
  • Return value is false.
    The activity is not displayed in the Web Client.

• script

  Optional. A script can be entered using the script editor (see section Reopen activities) which is executed when the ticket enters the activity.

• overlay

  Optional. Click into the orange space to define a standard ConSol CM overlay or one that has already been uploaded. Click the three dots button to open the file explorer of the operation system to upload a new icon. When the ticket passes through an activity the overlay is added to the ticket icon in the Web Client. Up to three overlays can be attached to a ticket icon. This mechanism can be used for several purposes, some examples are:

  • An escalation:
    The ticket has been created without any engineer taking care of it.
  • An email:
    The ticket has received an email.
  • A note for the engineer:
    E.g. another engineer has added a comment to my ticket.

  

  Figure 48: ConSol CM Process Designer - Properties editor: Standard overlays and one customer-defined overlay

  

  Figure 49: ConSol CM Web Client - Ticket icons with overlays

• overlay range

  Only displayed when an overlay has been set.

  • Activity
    The overlay is attached only as long as the ticket stands behind the activity or - if present - behind the last automatic activity which can be passed without manual interaction. As soon as the next manual activity is executed, the overlay is deleted from the ticket icon.
  • Scope
    The overlay is deleted when the ticket leaves the scope.
  • Process
    Once the overlay has been attached to the ticket icon, it stays there for the rest of the process.
  • Next overlay
    The overlay is attached to the ticket icon as long as no new overlay appears. In that case, only the new one is attached, the old one is deleted.

  In case you have to cover a use case where it is not sufficient to set or remove an overlay using the overlay range, you can use a workflow script. Please see section Working with overlays for details.

• history visibility

  Mandatory. This property defines on which display levels the execution of the activity is shown in the ticket history in the Web Client. The possible values are:

  • 2nd level and 3rd level
  • only 3rd level
  • on every level
  • default (default value)

    The activity is shown on the display level which is configured in the Admin Tool, navigation group Tickets, navigation item History. Depending on the type of activity, one of the following settings is used:

    • Manual activity or activity with overlay executed
    • Activity executed after escalation
    • Automatic activity executed
  • hidden on all levels
    The execution of the activity is never displayed in the ticket history of the Web Client.

  

  Figure 50: ConSol CM Web Client - Display levels in the ticket history

• disable auto update

  Defines the behavior of the ticket when an event has been fired or executed. Usually, after an event, a ticket update operation is performed automatically. In case a chain of events is used you should avoid triggering a ticket update operation after every single event. To avoid this, set disable auto update to true in all events except for the last one. Then, the ticket is only updated once, after the last event.

• expose to customers

  Boolean. If checked, the activity is displayed as a workflow activity in the ConSol CM portal, CM/Track. The activity is only displayed in CM/Track if no precondition script is set or if the precondition script returns true. If an ACF (Activity Control Form) is attached to the activity, it is opened when the customer clicks the activity. An example of an ACF in CM/Track is shown in section ACFs in CM/Track.

• expose to users

  Boolean. If checked, the activity is displayed as a workflow activity in the Web Client. The activity is only displayed if no precondition script is set or if the precondition script returns true. If an ACF (Activity Control Form) is attached to the activity, it is opened when the user clicks the activity.

Process logic of reopen activities

The ticket 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 tickets on the designed workflow as a whole. The following list shows some examples of areas which might need adaption when introducing reopen activities.

• Automatic actions on ticket closure

  If the workflow contains automatic actions which are performed when a ticket is closed, you might need to adapt them for reopened tickets to avoid executing them more than once. It might even be required to undo some of these actions when a ticket 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.

• Ticket relations

  If the workflow implements a specific behavior regarding parent-child and master-slave relations, reopening a ticket could require changes to other tickets as well.

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

• Reports/dashboards

  If the number of closed tickets is analyzed in reports or dashboards, you need to decide how to handle reopened tickets. Otherwise, the report data might be inaccurate for reopened tickets, e.g. because the same ticket 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.

Example for the use of reopen activities

Example 1: Reopen a closed ticket when an email is received

The default behavior when an email is received for a closed ticket is to create a new ticket and create a relation between the new ticket and the original ticket for which the email was received. If you would like to reopen the original ticket instead, you can add a reopen activity to the scope where the end node is located and execute this activity in the incoming email processing script.

Please follow the following steps:

1. Add a reopen activity to the scope or scopes containing end nodes.
2. Create a connection from the reopen activity to the activity where the ticket processing should continue.
3. Edit the NimhIncomingMailRouting.groovy script in the Admin Tool to add the logic to reopen the ticket.
4. Deploy the workflow and test it.

The following figure shows the part of the workflow with the end scope and reopen activity.

Figure 51: ConSol CM Process Designer - Workflow with a reopen activity

The following example shows the NimhIncomingMailRouting.groovy script from the Admin Tool. The lines highlighted in red have been added to reopen the ticket if the reopen activity is present.

Code example 6: NimhIncomingMailRouting.groovy adapted to reopen a ticket if an email is received