ITIL guidance would say to create a problem, then perform your root cause analysis there.
Understanding that real-world cases often differ this guidance, and also recognizing that there are not many customers with a mature Problem Management process, the Parent/Child incident is the simplest approach.
The way we generally implement this isn't to lock out "child" incidents from writability, but to limit the relationship to 1 level. I.E. prevent "grand-child" incidents.
This is done by a simple reference qualifier (pre-Eureka):
parent_incidentISEMPTY
If you're using Eureka, it's even easier. Personalize the same Parent field (depending on what version of ServiceNow you're using, this is either "parent", "parent_incident" or "u_parent_incident":
Then, you're welcome to perform any additional customizations or "links" you wish, using Business rules.
For example, if you want to cascade work notes from the parent to the children, this is a simple business rule to use:
When: after/update
Condition:
current.parent_incident.nil() && current.work_notes.changes()
Script:
updateChildWorkNotes();
function updateChildWorkNotes(){
var childIncidentQuery = new GlideRecord('incident');
childIncidentQuery.addQuery('parent_incident', current.sys_id);
childIncidentQuery.addQuery('sys_id', '!=', current.sys_id); // make sure we don't get into a loop
childIncidentQuery.query();
while (childIncidentQuery.next()){
childIncidentQuery.work_notes = current.work_notes;
childIncidentQuery.update();
}
}
Finally, add the "Incident > Parent Incident" related list to the Incident form.
