Parent-child incident relationships let you group multiple incidents under a single parent when they stem from the same underlying issue. This guide shows you how to set up these relationships and what automation you'll need for proper resolution handling.
Why parent-child relationships exist
When a server goes down or a service fails, you typically get flooded with incidents from different users reporting the same problem. Without grouping, your team wastes time investigating duplicates, users get frustrated waiting for updates on what appears to be separate issues, and managers lose visibility into the real scope of outages. The people managing incidents — service desk agents and incident managers — need a way to show that multiple reports are actually facets of one underlying problem.
How incident relationships work
A parent-child relationship is a simple reference field connection. You set the Parent Incident field on child incidents, and ServiceNow automatically shows those children in a related list on the parent. The parent becomes your single point of control for communication and resolution tracking. Start basic: manually link incidents as you identify them. Then add Business Rules or flows to automatically resolve children when parents close, and consider SLA pause rules so child incidents don't breach while you're working the root cause.
Production-quality improvements
Once you have basic linking working, add automation for resolution propagation — child incidents should typically move to the same state as their parent. Consider knowledge base integration so resolving the parent automatically creates or updates KB articles. For high-volume environments, build notification rules that alert stakeholders when parent incidents are created or resolved, and add dashboard widgets that show parent-child trees for major incident command center views.
Before you start
- •itil role or admin access to modify incident records
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Open the child incident
Navigate to the incident that should become a child in the relationship. This is typically one of the duplicate or related incidents you've identified as stemming from the same root cause as your parent incident.
Set the parent incident reference
Scroll to the Parent Incident field and use the lookup to select the incident that should serve as the parent. The lookup will search by number, so typing 'INC0001234' is usually the fastest way to find it. Once selected, save the record.
Verify the relationship on parent
Open the parent incident record and scroll to the Child Incidents related list at the bottom of the form. You should see your child incident listed there with its number, state, and assigned group. This related list updates automatically when you create parent-child relationships.
The child incidents related list shows key fields like State and Assignment Group so you can quickly see the status of all related incidents without opening each one.
Test resolution behavior
Change the state of the parent incident to Resolved and save. Check the child incidents — their states remain unchanged. This is default behavior and usually what you want for initial testing, but most organizations need resolution to cascade automatically.
Create resolution automation
Navigate to System Definition > Business Rules and create a new rule. Set the table to Incident, When to After, and add a condition for when State changes to Resolved or Closed. In the script, query for child incidents where parent_incident equals current.sys_id and update their states to match the parent.
Configure SLA handling
Navigate to Service Level Management > SLA Definitions and review your incident SLAs. By default, SLAs on child incidents continue running independently. If you want child SLAs to pause when there's a parent, add a pause condition checking for !parent_incident.nil().
Most organizations pause child SLAs when a parent exists, since you're typically working the parent incident and children are waiting on that resolution.
Best practices
Create the parent-child relationship as soon as you identify duplicates — don't wait until resolution to link them.
Use Business Rules for resolution cascading rather than trying to manually resolve children — you'll forget child incidents in large outages.
Pause SLAs on child incidents when they have parents, otherwise you'll get breach notifications for incidents you can't actually resolve independently.
Set up notification rules that inform reporters of child incidents when the parent is resolved — they need to know their issue is fixed even though their specific incident shows as a child.
Don't create parent-child chains more than two levels deep — ServiceNow handles it but your team will lose track of the relationships during major incidents.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue