Applying Quick Tickets can be done in two different places in the ticket application interface:

1. a new ticket is created with the help of a Quick Ticket
2. a Quick Ticket is applied to an existing ticket.

The only, basic difference is that when creating a new ticket, a ticket owner, i.e. a user in whose name the ticket is created, must be selected first. The ticket owner can already be predefined by the Quick Ticket.

The button for selecting a Quick Ticket always displays the entire folder structure in which Quick Tickets are organized.

Note: Quick Tickets are available to dispatchers as well as supporters with write permission to a resource or users with permission to edit all tickets.

Applying a Quick Ticket - both to an existing ticket as well as a new ticket - is performed in a separate dialog. Here, the ticket fields as well as the ticket's request text are set. Ticket fields that are preset in the Quick Ticket definition will be transferred to the dialog and can now be changed.

Quick Tickets can preset fields with an empty value. In this case, an existing value will be removed from the ticket.

Note: The request text can also be pre-assigned in the Quick Ticket definition and is then placed in front of the request text of an existing ticket. The original request text is therefore always retained.

Each follow up step represents an editing step on the ticket. Depending on the ticket action to be performed, additional fields are offered and can be changed if necessary.

Additional follow up steps can not be defined here, nor can the sequence of existing subsequent steps be changed. However, it is possible to remove individual follow up steps.

Not all fields are shown by default, but can be made visible using the Fields button at the bottom of the dialog.

Note: Quick Tickets can set values to every field regardless of visibility.

In i-net HelpDesk, there are a number of fixed processes that are mutually dependent. For example, a ticket must be in a resource - i.e. dispatched - so that certain subsequent steps are possible. Likewise, a ticket that has already been closed cannot be edited again - it must be reactivated beforehand.

Before changes are finally made to a ticket by applying a Quick Ticket, a plausibility check takes place. Problems that are detected here lead to an error in the interface. Some of these problems, such as reactivation or dispatching, can be executed automatically after the supporter approves these ticket actions in a dialog.