What are the best practices to use the link to "Parent Incident" for incidents?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-11-2018 05:25 AM
Hi Folks,
Good day. I am from IT support for a company and I would like some advise on this.
My company is using Service Now to keep track on our day to day incident submission. The other day, I encountered one situation where a particular Incident 'XYZ' were assigned late over to our assignment group (roughly 1 week later) without doing any basic troubleshooting as it was out of their scope. My Queue Manager (QM) on that day then created a new incident '123' and considered that as the Parent Incident and have 'XYZ' linked it '123'. Reason I was told is that by using this approach, this will save our SLA / end to end hours from breaching (as my company uses this metrics to keep track of our teams performance). From my understanding on the parent-child relationship is that the original incident should be treated as Parent incident on all scenarios and not using the just created child incident and treat it as the Parent incident. I was surprised by the way they chose this method to handle this scenario. Please help to advise me if I am missing out something on the use of the 'Parent Incident' function.
Thank you and best regards,
Scott.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-12-2018 11:22 AM
Scott,
You are right, Original Incident should be Parent Incident and later Incident should be consider as child Incident.
Thanks
Ziaur Rahman

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-12-2018 11:26 AM
The first incident should be the parent incident. Any incidents created after that should be child to it.
Creating an incident later and associating it to the old incident to help in your SLAs is not a good practice. This practice could then used by other teams and can become a loophole in your incident management.
Please mark this response as correct or helpful if it assisted you with your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-13-2018 06:34 PM
Scott,
Ziaur and Sanjivmeher are right about the parent-child incident relationship. The incident created with the earlier timestamp would be the Parent and the one created with a later timestamp would be a Child incident.
I've worked in an incident management environment and later analytics role, hence I believe I could provide some insight based on experience.
I have encountered the situation you mentioned before in the past when I worked as an incident management agent.
We had agents abusing the Parent-Child incident relationship to have a better looking SLA graph for quarterly reviews.
In short, whistles were blown and disciplinary actions were taken towards the agent who performed such malpractice.
Speaking as an experienced incident management agent, I would just say that this malpractice wrong in many levels.
For one, it is unethical to do so.
(Unless everyone in your top management endorses it then it's a different matter)
What sort of quality of service would be delivered if agents can are free to exploit such loopholes? Wouldn't the Customer Experience be bad?
(From experience, our executive IT directorship actually does their own "clandestine" report based on customer's feedback and would do comparisons towards the report IT provided at the end of every quarter)
Also, this doesn't seem to be inline with what ITIL principles suggest.
(whether your company does send its agents for ITIL trainings is another question)
Having moved out of out incident management and working closely with my company's IT team for analytics and overall planning, I can't stress more how this malpractice would impact the company as a whole.
Incident ticket metrics or reports are used in a much wider context, not just to see the SLA graph for "judging" purposes. They are used to calculate costing, hiring headcounts and other high level management decision making.
Malpractice such as what you mentioned would cause a chain reaction which may have a detrimental effect to your company's IT department in the long term.