Process editor

A process always consists of at least one activity and a unique process name. A ticket that runs through the process is always in exactly one activity at a time. This activity determines the current rules for further processing of the ticket: which actions are currently possible and which activities can become active next.

Edit process

The dialog for editing a process shows the sequence of activities on the left side, automatically arranged from left to right and from top to bottom. Each process always has exactly one start activity, indicated by the house icon. Further activities always describe a task block, which the user processes. A process can also have one or more activities that end the ticket or leave the process. The latter are marked by the finish flag. All activities are connected to each other by connecting lines.

On the right side of the dialog is the list of all activities in this process. At any point of the dialog, activities can be hovered over with the mouse pointer to highlight all references of this activity. Especially with very extensive processes, this simplifies the search for multiple references of the same activity. In the process graph, the activities can also be highlighted. If the mouse pointer remains longer on an activity, the entire path is highlighted.

The menus in the dialog allow to:

  • Set the zoom level for the process graph
  • Activate the full screen mode for editing the process
  • Hide the list of activities
  • Add a new activity

Clicking on the activity opens it for editing. Editing the connections between activities is done through a menu opened by clicking on the button in the connection line, which becomes visible when the mouse is moved over it.

Note: An activity - including its subsequent activities - can be used multiple times in the graph. A special feature here is that a reoccurrence of an activity in a link path causes it to link back in the process.

Note: If an activity with follow-on activities is removed, this structure can be completely reinserted into the process at a later time.

Activities

Process activities form the core of a process and are independent task blocks. The names of the activities can be freely assigned and it can be decided whether it should represent a state, e.g. "Customer informed", "Test started", "Test completed" or a procedure, e.g. "Inform customer", "Test product".

In activities, mandatory fields can be defined, which must be set additionally. to allow the change to this activity. In addition, ticket fields can also be set directly by the activity as soon as the process switches to this activity. For example, a resource can be defined that is responsible for the ticket as of this activity. Restricting allowed actions within an activity is also possible.

Note: A ticket field cannot be set as a mandatory field in an activity at the same time and additionally be preassigned with a value.

Process Activity

Activity Functions

The following properties are set in an activity:

Ticket Actions

The list of Ticket Actions specifies which actions are enabled by this activity. The list of these actions further narrows down the choices for the user.

Ticket fields that must be set

The fields specified here must be set before or while switching to this activity. They extend the general mandatory field settings, which remain.

Note: Mandatory fields are only evaluated for supporters, not for end users.

Note: Mandatory fields cannot be defined in the start activity.

Note: Mandatory fields are not considered if the transition is triggered indirectly, e.g. by reactivating a ticket by receiving an email.

Ticket Properties

In the Ticket Properties, values can be preset for ticket fields that will be set in the ticket when switching to this activity. For example, the activity can determine the resource responsible from now on.

Furthermore, the following rules apply:

  • If the activity's connection action is Weiterleiten, the new activity must determine a resource.
  • If the connection action of the activity is Autorisieren, the new activity can determine a resource. This eliminates the need for the supporter to select the resource during ticket processing.

Note: Setting a property automatically will not prevent users from changing that property again in the ticket. If the change is to be prevented, then the corresponding Actions must be restricted.

Start next process

If the current process is left by an activity, another process can be specified here, which is to be started afterwards. The execution of another process now allows that the ticket has to be processed further with fixed rules.

Connections between activities

To get from one activity to the next there are so called connections. These consist of an action and an optional name. As soon as a user executes this action, the ticket moves to the next activity. For the connection applies:

  • Any actions can be used for the connection, which are executed regularly and then move on to the next activity.
  • A connection action can only be executed if the current state of the ticket allows it and the user is allowed to run the action.
  • Connection actions do not have to be explicitly allowed in the Ticket Actions of the activity.
  • The "Weiterschalten..." action can only be used for activity transition. This also applies to new tickets, but not to closed or deleted tickets. It can only be run by supporters.
  • The activity transition can also be triggered indirectly or automatically.
    • Example: An incoming email closes a ticket through a JavaScript trigger. An activity switch is performed if it is configured with the End action.

Note: If an action, e.g. Beenden, is used multiple times for a connection and triggered automatically, e.g. by a JavaScript trigger, the first path - i.e. the first forwarding connection of an activity - is automatically executed in the process. This is due to the fact that the JavaScript trigger in particular only determines the subsequent status, but not the concrete action.

Completing process and ticket editing

There are basically two ways to complete the editing of a ticket with an active process:

  • A ticket in the process can be closed or deleted
  • The ticket reaches an end activity, signaled by the finish flag

Ticket is ended or deleted

A ticket can be closed or deleted in the process to mark an "end". In this case, no follow-up activities are necessary. The ticket remains in the process. This brings the advantage that the behavior can still be controlled during or after a possible reactivation.

For this, it is necessary that the activity Close or Delete Ticket is set as ticket actions or used for a connection to a follow-up activity.

With the actions Reaktivieren, E-Mail Empfangen or Benutzerkommentar as connection actions, tickets can be reopened and the process can be started from the beginning by linking back, for example.

Exit process

The process is regularly closed when it reaches an end activity. When this activity is reached, the process is exited and removed from the ticket. End activities are marked by a finish flag and have a green link line to the right in the editor to the EXIT PROCESS area. The ticket does not have to be closed at this point, but it usually makes sense to do so. The ticket will then remain without an active process.

The specifics of an end activity are:

  • The activity is run automatically, ticket properties are set and the process is exited directly afterwards.
  • No ticket actions can be defined.
  • Optionally, another process can be started.

Error handling

Both the process overview and the process editor give hints when a process can reach invalid states in which it is no longer possible to make progress without administrative help. These occur, for example, when actions contradict each other or the ticket can reach a state in which it is no longer possible to terminate the ticket.

Invalid states are checked for when the process is opened or saved during editing. If an invalid state is detected, this will display a corresponding message with further details.

Common error messages when editing a process

The following messages appear when trying to save the process.

Activity "<name>" must define at least one follow-up activity or allow the ticket to be terminated.

If only one activity is used in the process, e.g. to define mandatory fields or set specific ticket fields, termination of the ticket must also be allowed. Otherwise, other activities should be defined.

The ticket and the process cannot be terminated. There must be either a way to terminate the ticket or via an end activity "Leave process".

Open ends after an activity are invalid states. An activity must satisfy at least one of the following configurations:

  • The ticket can be terminated or deleted.
  • There is a connection to a follow-up activity.
  • The process can be exited with this activity.

All transitions to subsequent activities must have unique names. The name "<action name>" in activity "<name>" is already used.

All outgoing connection action of an activity must have a unique name to be unambiguously recognizable during ticket processing. The name of a connection action can be customized in the "Change connection" menu.

It is possible that a ticket gets stuck in activity "<name>" without any further possible actions after the action "<action>" has been executed. Please change the allowed actions in or to activity "<name>".

This message is displayed if the set actions and connections allow a state from where the ticket can neither be ended nor the end can be reached by EXIT PROCESS.

This is possible if, for example, a connection action Close is used and the follow-up activity Reactivate is allowed, but not the action Close itself. The ticket can be reactivated in this activity, but cannot be terminated afterwards and thus remains open. It must now be decided whether the reactivation should be prohibited or the subsequent close should be allowed, if necessary.

Common error messages when starting a process

The following messages appear when trying to apply the process to a ticket.

This process can only be applied to authorized tickets

A process cannot be applied to new, not yet authorized tickets if, for example, Edit or other actions that are only allowed for authorized tickets are used as connection actions and no Authorize is possible in the process.

If this behavior is not desired, the ticket can be authorized first to start the process afterwards. Alternatively, the process can be customized and the Authorize action can be included in the ticket actions of the start activity.

This process can only be applied to new, unauthorized tickets

This process can only be applied to new, unauthorized tickets if exclusively Authorize is possible as a connection action.

This state may well be desired in order to be able to apply the process to new tickets only, for example to specify a fixed workflow for the dispatcher. Alternatively, another action must be stored in the start activity.