Filling in the parent field in the task table

[PolyannaS]

Problem with the Parent field in the Task table when using the parent/child relationship of Incidents
Hello Community,

I'm facing a problem related to the parent/child relationship of Incidents and the Task table, and I would like your help to confirm the best practice in this scenario.

Current Behavior

In our instance, Incidents can be related as a primary (parent) incident and child incidents.

This relationship is being done through a custom field in the Incident table (for example, "Primary Incident").

The custom field works visually within the Incident form and other tables that have this customization.

However:

The default task.parent field is not being populated.

When viewing the records in the Task View (task table), the Parent column (reference) appears empty.

As a consequence, Task-based views, reports, and hierarchy resources do not recognize the parent/child relationship.

Even within the Incident table itself, the default Parent field remains empty.

Observed Impact

The parent/child hierarchy is not recognized at the Task level.

Filters, reports, and dashboards that depend on the task.parent field do not function correctly.

The relationship exists only logically through the custom field, and not through the standard ServiceNow hierarchy model.

Understanding to date

From what we understand, ServiceNow natively recognizes parent/child relationships only through the task.parent field. Because the relationship is being controlled by a custom field, the system does not treat these incidents as hierarchically related tasks.

Questions

Is it considered good practice to always populate the task.parent field when implementing parent/child relationships between Incidents?

Are there supported alternatives to using task.parent in this scenario?

Are there any known risks or side effects of populating the task.parent field in existing records?

How can I transfer this information from a custom field to the standard field without major impacts?

[Naveen20]

1. Is it good practice to always populate task.parent?

Yes. If you want ServiceNow to recognize the hierarchical relationship at the Task level, task.parent is the standard mechanism the platform uses. Features like task hierarchy views, related lists driven by parent/child, rollup reporting, and certain OOTB business rules all key off this field. A custom reference field creates a logical relationship that only your custom configurations understand — the platform itself remains unaware of it.

That said, the Incident table also has its own OOTB mechanism for major/child incident management (Major Incident Management plugin) which uses fields like parent_incident and the child_incidents related list. If you're on a recent release, check whether the Major Incident Management feature fits your use case before deciding between task.parent and the incident-specific fields.

2. Are there supported alternatives to task.parent?

A few options depending on your requirements:

• Major Incident Management (MIM): This is the OOTB approach for primary/child incident grouping. It uses parent_incident on the Incident table and comes with built-in workflows for child creation, communication, and resolution propagation. This is the recommended path for incident-specific parent/child use cases.
• Related Records / Related Lists: If the relationship is informational rather than hierarchical, a many-to-many table or the OOTB Related Records feature may be more appropriate.
• task.parent itself: If you need the relationship to be visible and functional across the entire Task hierarchy (cross-table reporting, unified task views), then task.parent is the right field.

The choice depends on whether you need the hierarchy at the Task level or only within Incidents.

3. Are there risks or side effects of populating task.parent on existing records?

Yes — a few things to be aware of:

• Business Rules and Flows: Any OOTB or custom business rules that trigger on task.parent changes will fire. Audit your instance for business rules on the Task or Incident table with conditions referencing the parent field before doing a bulk update.
• SLA and Assignment behavior: Some configurations evaluate parent task state or assignment. Populating the parent could unexpectedly trigger SLA recalculations or assignment logic if such rules exist.
• UI and Related Lists: Once task.parent is populated, the OOTB "Child Tasks" related list on the parent record will start showing entries. Confirm this is the desired experience for your users.
• Circular References: Ensure your data migration logic prevents circular parent references (A → B → A), as this can cause infinite loops in recursive scripts.

4. How to migrate from the custom field to the standard field?

A phased approach works best:

Phase 1 — Audit and prepare. Identify all business rules, client scripts, UI policies, flows, reports, and widgets that reference either your custom field or task.parent. Understand what will change when task.parent gets populated.

Phase 2 — Backfill with a fix script. Write a fix script that reads your custom field and sets task.parent accordingly. Run it in a sub-production environment first. Something like:

var gr = new GlideRecord('incident');
gr.addNotNullCondition('u_primary_incident'); // your custom field
gr.addNullCondition('parent');
gr.query();
while (gr.next()) {
    gr.setValue('parent', gr.getValue('u_primary_incident'));
    gr.setWorkflow(false); // suppress business rules during migration
    gr.autoSysFields(false); // preserve sys_updated_on/by
    gr.update();
}
gs.info('Migration complete: ' + gr.getRowCount() + ' records updated');

Use setWorkflow(false) during migration to avoid triggering unintended side effects, and autoSysFields(false) to preserve audit timestamps.

Phase 3 — Synchronize going forward. Create a business rule on the Incident table (before insert/update) that syncs your custom field value into task.parent so both stay aligned. Over time, you can deprecate the custom field entirely once all dependent configurations have been moved to use task.parent.

Phase 4 — Validate and clean up. Run reports comparing the custom field vs task.parent to confirm data consistency. Test all affected reports, dashboards, and hierarchy views. Once validated, retire the custom field from forms and update any documentation.