A process always consists of at least one activity and a unique process name. A ticket that runs through the process is always in a single 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 be activated next.

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
• Filter the list by activity and ticket name
• Set advanced settings

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.

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 then must be set to allow the process to change into 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.

Note: The supporter needs permission for the action Change ticket fields.

The following properties are set in an activity:

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. To add individual new actions there is a corresponding selection list. At the end of this list is another entry to add "All Actions" to the list with one click.

Next to it is an additional menu to remove all actions or reset them to the default actions.

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 can be defined for the start activity of the main process, but not for start activities of parallel tickets.

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

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. There are two options for this:

• Fixed value: A fixed value is assigned for the ticket field.
• Take over value: Takes over the value of the selected ticket for the ticket field as soon as the activity is entered.

Furthermore, the following rules apply:

• If the activity's connection action is Forward ("Weiterleiten"), the new activity can determine a resource. This eliminates the need for the supporter to select the resource during ticket processing.
• If the connection action of the activity is Authorize ("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.

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.

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 action Advance Process (Prozess Weiterschalten) 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.
  • Example: The action Receive Email ("") is used as a connection action. Incoming emails switch the process on.

Note: If an action, e.g. Close ("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.

Parallel tickets are created by the active process and support parallel processing of tasks. They contain their own activities that are created and processed separately. A parallel ticket is started via its start conditions. The connections of activities in the process can also be controlled by parallel tickets when they are used and are then no longer restricted to the execution of an action. Furthermore, the same rules apply to the process of parallel tickets as to the main process.

Parallel tickets are created only if their start conditions are met. Thus, they are created on demand. This is always useful if it is not yet clear at the start of the main process which path will be traversed and whether the parallel ticket is needed at all. If no start conditions are defined for a parallel ticket, it will be created directly with the start of the process.

In the start activity of a parallel ticket, its properties, e.g. subject, request text, ticket owner, etc., should be defined. You can specify these values via free input or take them from tickets that are involved in the process. The following applies here:

• The request text of the parallel ticket can only be taken over from the ticket with the main process.
• Fields can be taken over from any parallel ticket, if they have already been started. If the parallel ticket has not been started yet, the field remains empty or retains the previous value.
• If a resource is specified in the start activity, the parallel ticket will be authorized automatically. Otherwise, it is a new ticket, which must first be processed by the dispatcher.

The (sub)process of a parallel ticket must always be closed with an action Close ("Beenden") or Delete ("Löschen"). Starting a subsequent process is not possible. Also, parallel tickets are terminated when the main ticket is closed or the process is removed from the main ticket.

Note: The name of the parallel ticket is used for referencing in the process editor as well as in the progress bar for parallel tickets that have not yet been created.

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

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 ("Beenden") or Delete Ticket ("Löschen") is set as ticket actions or used for a connection to a follow-up activity.

With the actions Reactivate ("Reaktivieren"), Receive Email ("E-Mail Empfangen") or User Comment ("Benutzerkommentar") as connection actions, tickets can be reopened and the process can be started from the beginning by linking back, for example.

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.

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.

The following messages appear when trying to save the process.

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.

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

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.

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

A process cannot be applied to new, not yet authorized tickets if, for example, Edit ("Bearbeiten") or other actions that are only allowed for authorized tickets are used as connection actions and no Authorize ("Autorisieren") 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 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.