Ticket Actions

Ticket actions allow different interactions with a ticket. in doing so, it is, for example, possible to send an e-mail directly from a ticket or to modify information contained in the ticket subsequently.

For ticket actions, a distinction is to be made between direct and indirect actions. Direct actions are displayed below the Actions tab in the ticket. In case of an indirect action, it will be displayed at different places within the ticket,

In order to have a ticket action performed by a user, different conditions need to be met:

  • The user has to have the required rights on the ticket schema of the respective ticket.
  • The ticket has to have a certain status configured in the ticket action.
  • The executing user needs to be configured in the action either in the appropriate group or for this status on himself.

In the following, the common configuration of a ticket action will be explained. The special configuration of individual actions is dealt with in the Actions description.

Note: General behavior when assigning tickets to owner groups

When setting a new owner user of a ticket (applies to Actions and plug-ins), the owner group is set by priorities in the following order:

  1. If the new owner user is a direct member of the current owner group, the owner group is not changed.
  2. If the new owner user is not a direct member, there is a check, whether the user's main group is part of the current owner groups hierarchy. If so, the owner group is set to the user's main group.
  3. If 1. and 2. don't apply, the new owner user's closest sub group membership to the current owner group's hierarchy is determined and set as new owner group.
  4. If 3. doesn't return any sub group, the new owner group is set to the new owner user's main group.

Additionally, if there is a restriction to the ticket action Assign ticket, like e.g. Assign to this group and its sub groups, only this group and it's sub groups are taken into account. The ticket cannot be assigned to users, who are not part of this specific group's hierarchy.

Chapters:

  1. Tab Ticket statuses

  2. Tab Configuration

  3. Tab Expression clause

  4. Tab Visibility

  5. Actions description

 


 

  1. Tab Ticket statuses

On the Ticket statuses tab can be defined for every single action, in which ticket statuses it is to be visible and usable. The action will then be usable in the ticket during which this ticket has the respective ticket status.

It is possible to select the designated status, in which the action is to be available, under Status. Users and/or groups who are supposed to perform the action later on can be stored in the table below. If an action is to be available for the same users in other statuses as well, a new status can simply be selected and the previously configured status can be set in the next field Take over from. By clicking on OK afterwards, the configuration will be adopted for the new status.

As users, the following ticket roles can be used for an action:

Owner of the ticket: Only the current owner of the ticket can use this action. Unless a ticket has been accepted, the user will not be the owner. The action is available for the Owner group if Owner of the ticket is selected as an option. In this case, the specific ticket has no owner, but an owner group.

Owner group: The owner’s entire group (e.g. a support group) can access the action.

Creator of the ticket: Only the user that created the ticket can access the action.

Affected user of the ticket: Only the affected user of the ticket can use this action.

Affected group: All members of the affected user’s group can use the action.

Responsible user of the ticket: The action can be performed by a user listed in the ticket as responsible.

Responsible group: All members of the group of the user listed as responsible in the ticket can execute the action.

Task executor: A user handling a task created from the ticket can execute the action.

Task executor group: All members of a group which the task executor belongs to can execute the respective action.

Team member: Only members of the team can use the action.

Select user: Allows selecting a user or a group via a user browser The User Browser is a dialog window that displays a selection of users or groups for selection. This allows you to fill in ticket fields, for example., which can always see and execute the action, using the search function.

 

If a user role is to be added to all previously configured statuses, the option "Apply to all statuses" can be used. This option, however, will only affect already configured statuses. When another status will be edited later on, the user or group will not be added there automatically.

To remove a user role from the list, select it in the table and choose the "Delete" option from the Actions menu. If you want to remove the selected user role from every configured status, select "Delete from all statuses".

 

  1. Tab Configuration

Under Configuration, several configuration options can be found depending on the actions, which will be explained in the following sections.

 

  1. Tab Expression clause

It is possible to enter an additional expression which can restrict the visibility and usability of an action. The third possibility of displaying a ticket action under certain circumstances only, is, next to ticket status and added users, the Expression clause.

The expression may return nothing but True or False (Boolean). If the expression is True, the ticket action will be displayed for the configured user/users as soon as the ticket has reached a certain status.

 

  1. Tab Visibility

In several ticket actions, an additional tab Visibility can be found. On this tab can be determined the visibility of the objects to be created. The default configurations for the visibility are set in the ticket schema dialog. Via the settings in the ticket actions, they can be overwritten.

A grouping function can be used in the Visibility tab for the following ticket actions. This grouping allows different ticket actions of the same action type to be combined in the Actions menu of the ticket:

Action marked as Direct:

  • External link
  • Extract ticket from container
  • Reactivate ticket
  • Send e-mail
  • Show form
  • Start workflow

Action marked as Indirect:

  • Change additional affected users
  • Change affected user
  • Change geographical position
  • Create KB article from ticket
  • Convert ticket
  • Duplicate ticket
  • Forward mail
  • Link ticket with KB article
  • Take over ticket

Configuration:

No grouping: If activated, the action will be shown on the first layer inside the action menu in the top menu of the ticket.

Grouping: A name can be put in, which will be used to group related ticket actions of the same type.

Example:

There are three actions of the action type Start workflow configured for a ticket.

  • Workflow A
  • Workflow B
  • Workflow C

Workflow A and Workflow B have the same grouping name Workflow group.

Workflow C has no specific grouping settings.

  1. On the first layer of the top ticket action menu a group Start workflow get's created.
  2. On the second layer there is the ungrouped action Workflow C, as well as the configured group Workflow group.
  3. On the third layer, inside the Workflow group, actions Workflow A and Workflow B will be displayed.

Further ticket actions with visibility settings can be marked internally or externally. For example, an additional ticket action Internal Comment can be added, for which the visibility will be set to Internal. Consequently, all comments created via this action will be marked as Internal, irrespective of the default settings configured in the ticket schema.

Note:

In various actions, you can find the option Covered statuses on the Configuration tab. Due to these actions causing a status or workflow change, you can determine via this option, which statuses are to be marked as Achieved by the SLM nevertheless.

 


  1. Actions description

Add comment External link
Add ticket to container Extract ticket from container
Book expense Forward mail
Cancel successor tickets and tasks Hide successor tickets
Change affected user Link ticket
Change creator Link ticket with KB article
Change geographical position Manage CIs
Change service Mark ticket for ranking
Change status Move e-mail to another ticket
CI downtimes Reactivate ticket
Close ticket Reject ticket
Convert ticket Reject ticket (with user browser)
Create container Reply e-mail (reply all)
Create KB article from ticket Reply mail
Create schedules Save solution
Create successor ticket Send e-mail
Create task Send message
Duplicate ticket Show form
Edit escalation priority Show user defined HTML page
Edit escalation time Solve ticket
Edit expense default values SQL list
Edit ticket Start Workflow
Edit ticket fields Take over ticket
Edit ticket timing Ticket assignment
Edit ticket wizard page Ticket dispatching
Edit ticket wizard section Upload file