Ticket
Whenever a service request or similar is received by email or an agent creates a process, a so-called ticket is created. Tickets are comparable to a type of index card on which a process is mapped in its entirety.
Tickets can be created for a wide variety of topics: e.g. for the repair of a machine, a printer has run out of toner, the elevator is defective, spare parts orders are required and much more.
Different teams are responsible for the different task areas. To ensure that the ticket is assigned to the team in whose area of responsibility the process falls, it can be created automatically when the email is received or manually by an agent in a specific team folder. All tickets are saved in a team folder (queue) one after the other. This creates a kind of queue in which the tickets are sorted according to priority and age.
A ticket initially contains the topic/subject of the process and the contact information for the customer, such as contact person, email, telephone, etc. In addition, each ticket has a responsible employee and a processor, which can be the same person. When the ticket - and thus the process - is processed, further information is created in the course of the process, which is added to the ticket as articles e.g. e-mail correspondence with and without attachments, own notes, notes from other agents, data sheets, etc. In this way, the "index card" becomes an entire "folder" in which the entire process is mapped. Once the process has been completed, the ticket is also closed.
In the submenus of the menu, you can make the basic settings for tickets. You can create teams so that the tickets can be assigned to the corresponding task areas. You can create ticket priorities, types and statuses so that the tickets can be marked with properties. And you can create text modules to relieve the agents of some of the paperwork. All the settings you make here are available to the agents when they process tickets, and KIX generates all evaluations, tables, overviews, etc. according to the settings configured here.
Important
There are no cache dependencies between the base objects (status, priority, etc.) and business objects (especially tickets). Changes to the base objects therefore require a manual clean-up of the cache so that the changes are displayed correctly. To do this, execute the command Console::Command::Maint::Cache::Delete in the Console menu.
Note
When creating tickets via the API (e.g. with Insomnia), the request must contain the mandatory fields on the ticket.
If the ContactID is missing, the ticket creator is set as the contact and its PrimaryOrg as the organization. If no contact is assigned to the user, a message is displayed.
In this configuration key, you can make global settings for the module.
Parameters | Description | ||
|---|---|---|---|
addQueueSignature | Defines the conditions under which the team signature is included in outgoing emails.
Migration notice Please note that the existing configuration is not automatically migrated and requires a manual addition . We recommend creating the default value and setting the desired flags to | ||
ticketColors | Defines the display of tickets in the ticket lists based on their status
| ||
ticketRouteConfiguration | Defines the display of information messages regarding missing authorizations
| ||
organisationDeterminesContact | Defines whether only the contacts of the selected organization are available for selection on the ticket Standard:
|
You can use this configuration key to extend the agents' basic authorizations to former tickets.
The configuration key is initially disabled (invalid).
You can enable the configuration key if required. To do this, locate and open the configuration key in the → menu and set its validity to valid.
If enabled (valid): Agents can access a ticket that was at any time in one of the teams set under My teams (agent's personal settings), even if this ticket is now in a team to which they otherwise have no direct access.
Important
At this stage, the agent must have read and write access to the relevant team, which should be visible in the history.
Simply subscribing to the teams you want under My Teams is not enough.
The parameter Permission defines which rights the agents have to the respective (former) tickets. Possible values are
READ: read-only authorizationRW: Read and write permissions
Notice
This configuration only affects the basic authorizations. It has no influence on other authorization levels.
Warning
The ticket history must be checked for the authorization check, which can lead to a deterioration in system performance.
Defines the prefix with which the tickets are marked in the ticket detail view. For example:
Ticket#20251110170001411 - Printer does not print
Case no.: 20251110170001411 - Printer does not print
Process#20251110170001411 - Printer does not print
Standard: Ticket#
Defines which module is used to generate the ticket numbers. The selected module determines how the ticket numbers are structured.
DateChecksum (default): Inserts the counter as a checksum after the date and the SystemID. The checksum rotates daily.
Date: Generates the ticket number from the current date, the SystemID and the counter.
AutoIncrement: Increments the counter continuously. The SystemID and the counter are displayed in the format "SystemID.counter".
Random: Generates random ticket numbers in the format "SystemID.Random"
Checks the SystemID when recognizing ticket numbers in queries.
Default: 1
Use "0" if the SystemID was changed after the system was used.
Activates the SysConfig key for the ticket counter, if "Date" or "DateChecksum" is selected as TicketNumberGenerator.
Activated (default): 1
Deactivated: 0
Defines the minimum ticket counter size if "AutoIncrement", "Date" or "DateChecksum" was selected as TicketNumberGenerator.
Default: 5 (the counter starts at 00001, e.g. 2022113017000011)
Example: 3 (the counter starts at 001, e.g. 20221130170011)
Automatically sets the editor of a ticket as responsible for the ticket. The prerequisite for this is that the configuration key is activated (valid).
This only works for manual actions by the logged-in user. This does not work for automated actions, e.g. automation, postmaster and API.
Determines whether the observers of the initial ticket are retained.
When merging tickets, the watchers are transferred to the target ticket. For a better overview, the list of observed tickets is cleaned up by removing the tickets with the status "merged" from the observation.
The behavior when removing from the watch list can be configured in this key.
Possible values:
0 (default): After merging, the outgoing ticket is no longer monitored.
The action is available again at the exit ticket.
1: After merging, the observers remain on the initial ticket.
The action is available at the exit ticket.