Investigate options forAutomatic grouping of child tickets under parent tickets

RaginiP
Tera Contributor

‎04-01-2026 11:09 AM

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.
0 Helpfuls
  • 263 Views
1 REPLY 1

pr8172510
Giga Guru

‎04-02-2026 12:55 AM

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

       
0 Helpfuls