Investigate options forAutomatic grouping of child tickets under parent tickets

[RaginiP]

Could  you please someone help on this

Is there a recommended approach to implement a threshold-based limit on the number of child tickets under a single parent incident (e.g., max 300), so that when the threshold is reached the system automatically creates a new parent ticket and assigns additional child tickets to it? The goal is to prevent transaction time‑limit failures when closing large parent incidents.

Thnaks in Advance!

Ragini.

[pr8172510]

Hi Ragini,

1. Recommended approach → Threshold-based parent creation (controlled grouping)

Since there is no OOB feature for this, you need to implement custom logic:

• Define a threshold (e.g. 300 child incidents per parent)
• Once limit is reached:
  • Create a new parent
  • Route new child incidents to the new parent

---

2. Implementation logic (core idea)

Use Business Rule (before insert/update) OR Flow Designer

Logic:

1. When assigning a parent to a child incident:
2. Count existing children:     

   var count = new GlideAggregate('incident');
   count.addQuery('parent', current.parent);
   count.addAggregate('COUNT');
   count.query();

   if (count.next()) {
   var total = parseInt(count.getAggregate('COUNT'));

   if (total >= 300) {
   // create new parent
   var parent = new GlideRecord('incident');
   parent.initialize();
   parent.short_description = "Auto-created Parent for overflow";
   var newParentId = parent.insert();

   // assign new parent
   current.parent = newParentId;
   }
   }

    

3.  Maintain parent grouping context (important)

   To avoid random parent creation:

   • Use a field like:
     • u_parent_group_key (e.g. based on issue/category/source)

    So:

   • All related incidents still group logically
   • But are split across multiple parents

   ---

   4. Handle parent creation smartly

   Instead of creating parent every time threshold hits:

   • Check if an existing “active parent” is available for that group
   • Only create new if:
     • All existing parents reached threshold

   ---

   5. Why this approach works

   • Prevents:
     • Transaction timeout during closure
     • Heavy updates on single parent
   • Improves:
     • Performance
     • Scalability

   ---

   6. Alternative (closure handling)

   If main issue is closure:

   • Use:
     • Async processing (Scheduled Job / Event-based closure)

   But still:
    Splitting parents is more scalable long-term