Re-routing Incident from L1 support to L2/L3 tech support - CSDM considerations

[Tom Sienkiewicz]

Hi Folks,

I'm wondering about the preferred way to route INCs to L2/L3 support. I would appreciate some feedback on the recommended setup as there seem to be multiple ways of handling it.

 Imagine an INC created by an end user. The end user specifies the impacted Service Offering. The Offering would be linked to a Team for L1 support. On the INC form, We have Business Service Offering as well as Business Service auto-populated in the respective fields. 

L2/L3 support Teams would be linked to Technical Service Offerings / CIs (mapped through Tech Service Offering/ Dynamic Group).

Now, we need to reroute this INC to L2/L3 tech support. I tried to list multiple options here with some pros/cons:

#	Setup	Pros	Cons
1	Create additional fields on INC form for Technical Service and TSO, populating those changes assignment to respective L2/L3 group	We get to keep original BS/BSO for reporting. TS/TSO is available on the form for easy reporting as well.	Adding custom fields to INC. We lose original assignment group from INC, need to make sure INC will be assigned back to L1 before resolution.
2	Replace BS/BSO with TS/TSO in OOTB fields	no custom fields required, less cluttered form	We lose the BS/BSO information for easy reporting (still there's Impacted Services related list). Difficult to restrict selection of the TS/TSO that way. We lose original assignment group from INC, need to make sure INC will be assigned back to L1 before resolution.
3	Manual reassignment. Do not replace BS/BSO and do not select TS/TSO, but leverage CSDM relationships to determine fitting TSO/Support group manually.	No custom fields needed We keep original BS/BSO for reporting	Manual lookup required by the Agent. We lose original assignment group from INC, need to make sure INC will be assigned back to L1 before resolution.
4	Rely on CI field for L2/L3 assignment	BS/BSO fields stay intact. Best practice says always try to have CI populated (if not automatically, then by L1 agent). It will be consistent with INC created with CI (e.g. from monitoring).	It would be difficult to route to L2/L3 if the precise CI is not known (although perhaps App Service could be a good substitute in such cases). Requires to control the reassignment back to L1 etc.
5	Leverage INC Tasks. Leave the parent INC with BS/BSO, create INC Task for L2/L3 team, put TS/TSO in the fields of that INC Task which will assign it automatically	Original INC contains BS/BSO data for easy reporting. INC stays with L1 group the whole time, no need to control reassignments. INC Task contains clear TS/TSO data.	A lot of additional setup complexity (syncing with parent INC). Seems "redundant" considering CI field. Also would make "monitoring" scenarios harder to setup (possibly having to create INC task/INC at the same time).

I'm personally leaning towards #4 (through CI, my most preferred option) or #5 (INC tasks).

How do you have this set up? Is there another option that I missed?

One additional question that I have is: what is the best way to narrow down "selectable" TSO on the Incident, would it be via BSO->lots of stuff->TSO relationships, or better via CI->Dynamic Group->TSO / CI -> App Service -> TSO relationship? Is the svc_ci_assoc table a good starting point for those lookups? Would it normally contain BS/TS/BSO/TSO or only "Infrastructure" CIs?

Many thanks!

[MaxMixali]

ServiceNow – Preferred Ways to Route Incidents to L2/L3 and How to Narrow Selectable TSOs

Short answer (recommended pattern)
------------------------------------------------------------
• Primary: **CI-driven routing (#4)** — Assign L2/L3 based on the CI (or Application Service) on the Incident. This aligns with CSDM and works for events/monitoring-created incidents as well.
• Complement: **Incident Tasks for specialist work (#5)** — Keep the parent Incident with L1 for ownership/comms/SLAs; spawn tasks to L2/L3 for deep-dive work.
• Avoid proliferating custom fields for TS/TSO on the Incident body unless you have a strong reporting need that can’t be met via relationships.

Why this works
- CI/App Service is the core of operational support in CSDM.
- Keeps Incident ownership clear (L1) while enabling parallel expert work (tasks).
- Supports auto-routing from Event Mgmt/AIOps where CI is already set.
- Minimizes customizations and preserves OOB reporting on Business Services/Offerings.

Implementation blueprint
------------------------------------------------------------
1) CSDM hygiene & data model
- Business Service (cmdb_ci_service with classification = business) and **Business Service Offering** (cmdb_ci_service_offering) are already on the Incident for L1.
- Ensure **Technical Services/Offerings** exist and are related to the underpinning CIs (infrastructure + application services).
- Map **support/assignment groups** on one or more of: CI, Application Service, Technical Service Offering (TSO). Use a single source of truth if possible.

2) Auto-assignment logic (priority order)
a) If **CI** present on Incident and CI has support_group/assignment_group → use it (L2/L3).
b) Else, if **Application Service** (app service CI) present → use its support group (or its TSO’s).
c) Else, derive candidate TSOs from the **Business Service Offering → related CIs** and pick the owning L2/L3 group.
d) Fallback → **BSO’s L1** group.
- Implement via **Assignment Rule** (ordered), or **Before Insert/Before Update Business Rule**, or **Flow Designer** action.

Example (scripted assignment rule, pseudo):
```js
(function executeRule(current) {
var grp = RoutingUtils.resolveL2Group(current);
if (grp) current.assignment_group = grp;
})();
```

Script Include (outline):
```js
var RoutingUtils = Class.create();
RoutingUtils.prototype = {
resolveL2Group: function(inc) {
// 1) CI-level
var ci = inc.cmdb_ci;
var g = this._getGroup(ci);
if (g) return g;
// 2) App Service (cmdb_ci_service with classification=technical/application)
var app = this._getAppServiceFromIncident(inc);
g = this._getGroup(app);
if (g) return g;
// 3) From BSO → related TSOs/CI
var tso = this._getTSOFromBSO(inc.service_offering);
g = this._getGroup(tso);
if (g) return g;
// 4) Fallback L1 from BSO
return this._getL1FromBSO(inc.service_offering);
},
// helper methods _getGroup(), _getAppServiceFromIncident(), _getTSOFromBSO(), _getL1FromBSO() omitted for brevity
type: 'RoutingUtils'
};
```

3) Keep ownership with L1; use **Incident Tasks** for L2/L3
- Parent Incident remains with **L1 assignment group** to handle comms/SLAs/coordination.
- Create **Incident Tasks** for L2/L3 teams. Auto-assign tasks from CI/App Service/TSO.
- When tasks close, L1 validates/communicates and resolves the parent Incident.
- Benefits: no need to reassign parent back and forth; clean audit.

4) Reassignment controls & SLAs
- If you do choose direct reassignment of the Incident, persist **original L1 group** in a custom “owner_group” (read-only) field to reassign back upon resolution.
- Ensure SLAs attach to the parent Incident, and define task-level SLAs separately if needed.

How to narrow selectable Technical Service Offerings (TSO)
------------------------------------------------------------
Goal: prevent agents from picking unrelated TSOs; keep choices relevant to the Incident context.

A) CI → TSO filter (best)
- Reference qualifier on TSO field: show TSOs linked to the Incident’s **cmdb_ci** (or its **Application Service**).
- Use **m2m tables** that relate services/offerings to CIs (e.g., **svc_ci_assoc** for service↔CI, and **m2m_service_offering_ci** for offering↔CI; table names can vary by release).
- Advanced ref qual example:
```js
javascript:(function() {
var ci = current.cmdb_ci;
if (!ci) return 'sys_id=javascript:gs.nil("none")';
// Candidates: TSOs that are related to this CI
// Example using m2m_service_offering_ci:
var ids = [];
var m2m = new GlideRecord('m2m_service_offering_ci'); // or service_offering_ci
m2m.addQuery('ci', ci);
m2m.query();
while (m2m.next()) ids.push(m2m.getValue('service_offering'));
if (!ids.length) return 'sys_id=javascript:gs.nil("none")';
return 'sys_idIN' + ids.join(',');
})();
```

B) BSO → TSO filter (fallback)
- If no CI, derive technical offerings connected to the Incident’s **Business Service Offering** via service relationships.
- Use **svc_ci_assoc** to traverse Business Service → App Service/Infra CI → TSO.

C) App Service → TSO
- When Incident has an **Application Service** CI, filter TSOs linked to that app service or its underpinning technical service.

Notes on svc_ci_assoc and scope
- **svc_ci_assoc** is a good starting point to navigate **service↔CI associations**. Depending on your version, it can include both Business and Technical Services, and both Application and Infrastructure CIs.
- For Offerings, use the offering↔CI m2m (commonly **m2m_service_offering_ci** / **service_offering_ci**). Validate in your instance.

Pros/Cons recap of your options
------------------------------------------------------------
#1 Extra TS/TSO fields on Incident – Simple reporting, but adds customization and ownership confusion.
#2 Replace BS/BSO with TS/TSO – Hides business context; not recommended.
#3 Manual reassignment – Low build, high agent effort & error-prone.
#4 **CI-driven routing** – Best fit to CSDM and monitoring, scalable, minimal customization. ✅
#5 **Incident Tasks for L2/L3** – Great for ownership and parallel work; adds some workflow config. ✅

Operational tips
------------------------------------------------------------
- Populate CI automatically where possible (Discovery, Event Mgmt, Transform Maps from source tools).
- Put **support_group** on CI/App Service/TSO as your single routing source of truth.
- Use **Assignment Rules** (ordered) + Script Include for clean governance.
- Provide a **“Propose CI”** quick action for L1 if CI is unknown.
- Add a **UI Action** to spawn Incident Tasks to common L2/L3 towers with pre-set groups from CI/TSO.
- For analytics, report on BS/BSO at the Incident level and on TS/TSO at the Task level.

Bottom line
------------------------------------------------------------
Adopt **#4 (CI-driven)** for automatic, CSDM-aligned routing. Use **#5 (Incident Tasks)** to keep L1 ownership and to engage L2/L3 experts without bouncing the parent Incident. Narrow TSO choices using **CI/App Service relationships** via **svc_ci_assoc** and the offering↔CI m2m table to keep selection relevant and clean.

[Tom Sienkiewicz]

Thank you very much for this detailed insight! I'll consider some of the suggestions you gave.

[MaxMixali]

Preferred Approach for Routing Incidents (INCs) to L2/L3 Support in ServiceNow
=============================================================================

When routing incidents between L1, L2, and L3 teams, the best practice depends on your organization’s CSDM alignment and how well CIs and service offerings are maintained. Below are recommendations and rationale based on typical enterprise setups.

---------------------------------------------------------------------
Overview:
---------------------------------------------------------------------
- L1 support: Handles user-facing issues tied to **Business Service Offerings (BSO)**.
- L2/L3 support: Works on **Technical Service Offerings (TSO)** and **CIs** tied to infrastructure or applications.
- The goal is to maintain traceability between **Business Service** and **Technical Service**, while ensuring smooth escalation without data duplication.

---------------------------------------------------------------------
Recommended Options (Evaluation)
---------------------------------------------------------------------

**Option 1 – Create Additional Fields for Technical Service/TSO**
✅ Pros:
- Maintains both Business and Technical context on the same record.
- Keeps original BSO for reporting.
- Offers clarity on escalation flow.

❌ Cons:
- Adds custom fields to Incident.
- Requires logic to reset assignment to L1 before closure.

🟢 *Recommendation:* Good for hybrid orgs where both business and technical ownership are needed.

---------------------------------------------------------------------

**Option 2 – Replace BS/BSO with TS/TSO**
✅ Pros:
- Simpler UI (no extra fields).
❌ Cons:
- You lose original business context for reporting.
- Hard to enforce which technical service can be selected.
🔴 *Not recommended* — it overwrites important traceability.

---------------------------------------------------------------------

**Option 3 – Manual Reassignment via CSDM Relationships**
✅ Pros:
- No customization.
- Keeps BS/BSO intact.
❌ Cons:
- Labor-intensive and error-prone.
🟡 *Use only for low-volume orgs or early-stage CSDM adoption.*

---------------------------------------------------------------------

**Option 4 – Use CI Field for L2/L3 Assignment (Preferred)**
✅ Pros:
- Aligns with ITIL and CSDM 4.0 best practices.
- Keeps BS/BSO data intact for reporting.
- Incident to CI relationship enables automated routing using CI > Dynamic Group mapping.
- Supports integration with monitoring tools (alerts auto-create incidents).

❌ Cons:
- Relies on CI accuracy; without good discovery data, routing may fail.
- Needs automation for reassignment tracking.

🟢 *Strongly Recommended.*
CIs are the core link between Business and Technical layers — this maintains CSDM consistency and auditability.

---------------------------------------------------------------------

**Option 5 – Use Incident Tasks for L2/L3 Teams**
✅ Pros:
- Parent INC retains BS/BSO.
- Clear separation of responsibilities.
- Ideal for multi-team collaboration (SOC, NOC, DevOps).

❌ Cons:
- More complex workflow (synchronization, reporting alignment).
- Monitoring-triggered incidents may not fit well.

🟢 *Recommended when multiple technical teams participate in resolution (e.g., L2 infra + L3 app dev).*

---------------------------------------------------------------------

Best Practice Summary:
---------------------------------------------------------------------
| Scenario | Recommended Option |
|-----------|--------------------|
| Mature CSDM with CI data | Option 4 – CI-based routing |
| Multiple teams involved | Option 5 – INC + Tasks |
| Low data maturity | Option 1 – Extra fields for TSO |
| Manual process | Option 3 – CSDM manual lookup |

---------------------------------------------------------------------

Technical Note: Restricting Selectable Technical Services (TSO)
---------------------------------------------------------------------
You can restrict selectable Technical Service Offerings on the Incident form using reference qualifiers or relationships:

**Best approach:**
- Use `svc_ci_assoc` (Service-CI association) to map BSO → TS → CI.
- Reference qualifier for TSO field:
```javascript
javascript: 'active=true^ci_service.service_offering=' + current.business_service_offering
```
- Or, use **Dynamic Group Mapping**:
- CI → Assignment Group
- CI → Technical Service Offering

This ensures that when a CI is selected, the related Technical Service Offering and support group are auto-populated.

---------------------------------------------------------------------

✅ Summary:
---------------------------------------------------------------------
- **Option 4 (CI-based routing)** aligns with CSDM and ITIL best practices.
- Maintain both BS/BSO and TS/TSO linkage for traceability.
- Automate assignment via CI > Group mappings.
- Avoid overwriting BSO fields.
- Use INC Tasks for multi-team workflows.

This ensures a scalable, auditable, and CSDM-compliant routing structure for L1→L2/L3 handoffs.