Incident Routing Across Support Tiers Using ServiceNow and CSDM Principles

[Akash Bhardwaj]

One of the most overlooked aspects of Incident Management is how efficiently tickets get routed to the right support team. It sounds simple — assign to the correct group — but when you’re running a multi-entity or multi-location setup, this becomes a real challenge.

Recently, I worked on a design where we had to automate assignment group routing based on Service Offering and Location, while keeping everything aligned with the Common Service Data Model (CSDM).
Here’s how we approached it.

Why This Matters

In large organizations (especially public sector setups), multiple entities often share a single ServiceNow platform. Each entity may have its own L1 (Service Desk) and L2 (SME) teams, sometimes distributed across locations.
If routing isn’t automated, incidents either end up unassigned or bounce between queues — both leading to longer resolution times.

The goal was to:

• Automatically assign the incident to the correct L1 or L2 support group
• Respect CSDM relationships (especially between Service Offerings and Locations)
• Keep the model flexible for shared services

The Design Principles

We kept the logic simple, but structured:

1. Follow CSDM Relationships
   The Service Offering drives the assignment. Each offering defines its support model and associated tier levels (L1, L2).
2. Start with L1 Support
• Incidents are routed to L1 groups by default — these are tagged as Service Desk on the record.
• If an L1 group isn’t defined for that location or service, the ticket escalates to the L2 support group (labeled SME).
3. Location-Based Routing
   The logic looks at the incident’s location and matches it with the locations tied to the Service Offering.
• If there’s a direct match, the system picks the L1 group of that location.
• If there’s no direct match, it checks the parent location.
• This ensures incidents raised for branch or regional offices still land with the right local support group.

How It Works (Step-by-Step)

Here’s a simplified version of the logic reflected in the flowchart:

1. When an incident is created or updated, the business rulept checks if either the location or service offering has changed.
2. If the Tier Level on the Service Offering is SME Support, the incident is directly assigned to the L2 group.
3. If it’s Service Desk, the logic queries the L1 group from the location defined in the Service Offering.
4. If no matching L1 group is found, the system looks at the parent location.
5. Once the correct L1 or fallback L2 group is identified, the incident’s Assignment Group field is automatically populated.

This keeps the entire routing process dynamic and avoids hard-coded group mappings.

A Few Lessons Learned

• Define your Service Offerings properly.
  The CSDM relationship between Service, Service Offering, and Location is what drives the entire routing logic.
• Avoid static business rules.
  Instead of hardcoding group names, use lookups based on reference data tables (like m2m_location_to_service_offering).
• Think about the exception paths.
  Always include logic for shared or global offerings — otherwise, escalations can stall.
• Keep your tier levels consistent.
  Define “Service Desk” and “SME” clearly in the Service Offering record. It makes troubleshooting far easier.

The Outcome

With this design, incidents now automatically route to the right L1 or L2 group based on where and for which service they were logged.
It’s scalable, CSDM-compliant, and easy to extend as new entities or locations come onboard.

This approach has proven especially useful in federated government environments and multi-tenant service delivery models, where each entity operates semi-independently but still relies on a shared platform.