This section shows whether the current ticket is linked as a parent or child ticket (main/sub-ticket). Links can be created using the buttons to the right of the fields (‘+’ = select existing ticket, ‘★’ = new ticket with direct main/sub link). If there is no relationship yet, the section is initially hidden; the first link is created via the action menu or the quick action.
|
Note: The status reconciliation runs (depending on the model) until ‘Completed’. After reopening, no automatic further reconciliation takes place; further processing is triggered manually or again in accordance with the rules. |
Basic principle of ticket relationships in OMNITRACKS
1.Hierarchical structure
oA ticket is either a master ticket or a slave ticket – not both.
oMulti-level hierarchies are not supported (exactly one level).
2.Relationship fields
oRelationships are represented by ‘subordinate tickets’ and ‘superordinate tickets’.
3.Behavioural model control
oThe behaviour model is specified in the ‘Master-Slave Link’ drop-down menu.
oValues: ‘None’, ‘Main ticket completes sub-tickets’, ‘Sub-tickets complete main ticket’.
4.Determination of the relevant behavioural model
oIf a parent ticket exists, its value in the ‘master-slave link’ is considered authoritative.
oIf there is no parent ticket, the value of the current ticket is considered authoritative.
5.Synchronisation trigger
oSynchronisation is triggered when relevant data changes in the context of the relationship, e.g.
▪Status change on the master when ‘main ticket completes sub-tickets’,
▪Completion of a slave in ‘Complete sub-tickets, main ticket’.
Overall process (applies to all behavioural models)
1.Set behavioural model
oBefore creating the ticket: When a ticket is created with a type, the behaviour model is taken from the type.
oAt the moment of saving, after an existing ticket has been changed: If it was initially created without a type and a type is assigned later, the behaviour model is then set.
oThe initial assignment is final; the type specification is a prerequisite for processing.
2.Set role indicator (internal)
oFrom the first modification onwards, and only when changes are made to ‘Parent Ticket’ or ‘Child Tickets’, the roles are updated internally.
3.Checking for synchronisation-relevant behaviour
oNot applicable if the relevant behaviour model is ‘None’.
oOtherwise, it will be checked whether
▪a main ticket exists and ‘Main ticket completes sub-tickets’ is applicable, or
▪a sub-ticket is available and ‘sub- tickets complete main ticket’ applies.
oIn addition, the status or category must have been changed.
4.Prepared for escalation
oIf the conditions are met, processing is started by escalations.
Model-specific processes
A) ‘Master ticket resolves sub-tickets’ (master → slaves) Escalation from sub-ticket: ‘Master solves slaves’
Starting conditions:
•Ticket status ≠ ‘Completed’,
•Authoritative behavioural model = ‘Main ticket completes sub-tickets’,
•parent ticket exists,
•No active error flag in the sub-ticket.
Procedure (sequence):
1.Set Category – Adjust the category of the partial ticket to the main ticket if necessary.
2.Set State – if main ticket status ≠ ‘Completed’/‘Closed’ and differs from sub-ticket → Adjust sub-ticket.
3.Set Solution Data – if main ticket is ‘Done’ or ‘Closed’ → Transfer completion category, solution description, internal solution description, status to sub-ticket.
4.Completion mark on sub-ticket – successful processing is marked internally.
Error handling for unfilled mandatory fields (in the sub-ticket):
•In case of incorrect status transition (mandatory fields missing): desired target status is noted internally, notification email is triggered, internal error marking prevents repetitions.
•Form behaviour (sub-ticket):
oWhen opening the form: status is displayed at the top of the form, mandatory fields are marked.
oWhen saving after adjustment: original status is restored, internal markers are cleared.
oThe escalation then continues automatically and sets the status.
Escalation from the main ticket: Resetting the processing status
•Start conditions: Main ticket with sub-tickets marked as processed.
•Action: Internal processing status on the main ticket is reset (no open requirements).
B) ‘Sub-tickets complete main ticket’ (slaves → master) Escalation from the main ticket: ‘Slaves solve master’
Starting conditions:
•Main ticket ≠ ‘Closed’,
•at least one partial ticket available,
•Authoritative behavioural model = ‘Sub-tickets complete main ticket’
•Sub-tickets are available for processing.
Procedure (sequence):
1.Set State Classification – Set main ticket to ‘Classification’ if all sub-tickets are in ‘Classification’.
2.Set State In Progress – Set main ticket to ‘In Progress’ if all sub-tickets are in ‘In Progress’.
3.Set Solution Data – For solutions, only set the status on the main ticket; solution description as dynamic standard text with reference to the sub-tickets and their solution descriptions.
4.Completion mark on main ticket – Successful processing is marked internally.
Escalation from the sub-ticket: Resetting the processing flag
•Start conditions: current ticket is a partial ticket and marked as processed; the main ticket is awaiting completion.
•Action: processing mark on partial ticket is reset (no open requirements for this ticket).
C) ‘None’
•There is no synchronisation; the relationship serves solely for structural and navigational purposes.
|
Examples of ticket relationships: A typical ITIL® scenario is the bundling of many similar incidents into one main ticket (e.g. ‘Major Incident’). Instead of processing each incident separately, the affected tickets are assigned to the main ticket as sub-tickets. Processing and solution documentation are carried out centrally in the main ticket. If the behaviour model is configured accordingly (‘main ticket completes sub-tickets’), the assigned sub-tickets are automatically closed when the main ticket is closed; notifications can be triggered by the system. Ticket types may vary (cross-type relationships are possible).
For problem or change scenarios, a central ticket can serve as the main ticket, to which the affected incidents are directly assigned as sub-tickets. The cause is analysed and rectified in the problem; depending on the behaviour model, either the associated incidents are automatically closed when the problem is closed (‘main ticket closes sub-tickets’) or the problem automatically goes to “completed” as soon as all assigned incidents are resolved (‘sub-tickets close main ticket’). Accordingly, a change can be used as a main ticket to control the implementation of measures and either take over the closure of the incidents from the change or trigger it by closing all assigned incidents. |
