<< Click to Display Table of Contents >> Navigation: Standard Features > Ticketing > Overview Standard Ticket Form and Functions > Ticket Section: Ticket Relations |
This section displays whether parent or child tickets exist for the current ticket (parent or child ticket relationship). New links can also be created via the corresponding buttons to the right of the fields ("+" button: selection of an existing ticket from the database. "Asterisk" button: "Creation of a new ticket with direct parent-child ticket link").
Since tickets can be nested as deeply as desired, the "topmost" ticket of the hierarchy will be displayed additionally. If there is no parent ticket, the current ticket will be displayed as the top ticket. Tickets can be linked in this section, in the action menu of the ticket list, or in the quick actions on the form. If there is no relationship in the ticket yet, the section will not be displayed at first, the first relationship can then only be established via the action menu/quick action.
Depending on the relationship, the ticket is then "remotely controlled" by a superordinate or subordinate ticket, i.e. the state of the ticket can no longer be directly influenced.
The synchronization of the ticket states takes place until the state "Completion" and is then aborted. This means that if a ticket is reopened, the synchronization will not be continued and has to be performed manually, as this can often have ticket-specific reasons.
Furthermore, the information is displayed which ticket relationship function is currently available (parent ticket handles child tickets or child tickets handle parent tickets or no relation rule).
The relation rules are always transferred from the parent ticket to the child tickets so that no "dead ends" with conflicting rules can occur.
Application example ticket relations: A typical scenario from the ITIL® framework is the linking of incidents to a mass incident or further to a problem and change ticket: If many tickets are created in a short period of time for a specific cause of the incident, it is advisable not to process these tickets individually, but to combine them under a "parent ticket". For this purpose, one of the existing tickets becomes a parent ticket by assigning the subsequently occurring tickets to it ("child tickets") or a new superordinate ticket is created for this purpose. Only in the "parent ticket" the troubleshooting is processed and a solution is documented. If the administrator has set this accordingly, all assigned subordinate child tickets will automatically be completed as well when the parent ticket is completed, and the registered users will be informed. This also works with different ticket types.
In the same way, it is possible to assign many incident tickets that have the same cause to one problem ticket. In the problem, the corresponding cause is analyzed and resolved or (again as a higher-level ticket) linked to a change ticket and, if necessary, again to a release ticket that documents the necessary system changes. The system supports this arbitrary nesting and the administrator can optionally define for each of these relationships how the system should behave: If all subordinate tickets are completed, for example, the parent ticket should also be completed automatically or vice versa. |