ServiceGrid Articles - Parent and Child Tickets

From DocWiki

Jump to: navigation, search


There are several options to create parent and child tickets in Cisco ServiceGrid. This page gives a short overview of the options and the details can be found in the linked articles.

  1. Creating a parent or child via CallAction without XSLT.
  2. Creating one or several child(ren) via CallAction using XSLT (also known as mass incidents functionality).
  3. Creating one or several child(ren) or a parent via Internal Message using XSLT. 
  4. Creating a parent or child by using the CallDetail right frame button.

The above options are interlinked with each other. For example, Option 1 can be used to create a child ticket and Option 3 can be used to update the child ticket. Regardless of how they are created, the following rules always apply:

  • A ticket can have ONLY one parent.
  • A ticket can have multiple child tickets.
  • A ticket can have both a parent and child tickets.

The following are some guidelines implemented when choosing an option:

  • If you want to have full control over what is being transferred from one ticket to the other up or down the hierarchy, especially if fields should be mapped differently (for example, if one ticket's diagnosis should become the other's description), use internal messages.
  • If parents or children should be created by bridge interactions only. For example, if no user is logged in to work on the existing tickets, the methods described in the internal message should be used.

NOTE: You do not need an internal message if all the required information can be provided by the incoming bridge message.

  • If the tickets should be linked, but there is little interaction between the two tickets planned, the CallDetail right frame option should be chosen.
  • If there is a major incident that affects many different customers, a helpdesk user would most likely want to trigger mass incidents.
  • If a ticket has several subtasks that can run independently, but all need the same basic information, the CallAction without any XSLT should be used.

Master, Slaves, Parents and Children

Based on automatic updates, one important difference should be made while handling the parent and child tickets.

If all children are to be updated once their common parent reaches a certain status, regardless of the current child ticket's status, Master-Slave relationships are taken into account. This means that all slaves (child tickets) are automatically closed once the master (parent) ticket is closed. For example, a major incident results in multiple incidents being created by different customers. They are all assigned as slaves to one master incident dealing with the issue. Once the incident is resolved, the master is closed and the slaves are updated accordingly.

If parents are supposed to wait for the children's updates, parents will stay as parents and children will stay as children as per the terms. For example, a new employee joins the company. An Employee-Onboarding ticket is created with status Employee onboarding started, which triggers several child tickets to be created or issued such as:

  • an Active Directory user,
  • a laptop and cell phone,
  • necessary application permissions and
  • a key card.

Once all these child tickets are closed, the parent moves to the Employee onboarding finished status.

For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.


Rating: 0.0/5 (0 votes cast)

Personal tools