Best practice for applying a default Support Group for a CMDB Class

[lucaslopesm]

Hello guys, 

I would like your help to design a good and proper way of populating the "support group" in some classes.

Why I am trying to achieve this:

I want that incidents, alerts etc always have a group when the CI is the main impacted resource.

What I have been studying for this:

TSO - Best option so far, but I found a caveat: If the some items of the class have other support group, I would have to create other TSOs, and since they don't have a "hierarchy", those TSO dynamic CI groups would be constantly maintained to guarantee that they don't overlap.

BR - Not native, but very doable with little effort, wonder if it would be a good practice for maintainability

Default field on the class table - Not native, but very doable with little effort, wonder if it would be a good practice for maintainability

Example1:

I would like to set default group for windows classes to be "MS Windows Support" but I have heavily secured servers (e.g. domain controllers) which also are windows and want to assign "MS Domain Services Support"

Example2: 

I have a batch workload software (Control-M) whose jobs are maintained by different teams, and would like to default the group to one of them.

I don't know if I'm overthinking it or just am thinking just too narrowly, so feel free to contribute with options I haven't listed here

[BharatC]

Hello @lucaslopesm 

Use a precedence stack — no single mechanism (TSO/BR/class-default) handles overlap cleanly on its own.

This is about reliable incident/alert routing, not CSDM service-portfolio modeling — TSO still has its place for the latter, but its dynamic CI groups are siblings with no precedence, so overlaps require manual non-overlap maintenance between filters.

Resolution order, evaluated top-down:

1) CI-level attribute, if populated — from discovery/import (e.g. Control-M folder/app ownership pushed in at ingestion). Best case: nothing downstream has to compute it.

2) Class-level default via CI Class Manager — native, no scripting, respects class inheritance (child overrides parent). Solves cases like Windows Server vs. Domain Controller if DCs are their own subclass — worth splitting the class if not.

3) Lookup table (class/attribute → group) + thin BR — only for splits that don't map cleanly to a class. Keep the BR a pure lookup so maintenance is a data edit, not a script edit.

4)  Assignment Rules (sysrule_assignment) — native, ordered, no-code — as an alternative/complement to #3 for incidents. Alerts need the Event/Alert Management equivalent.

if this helped you, please click on helpful

Thanks,

Bharat C

[Mathew Hillyard · Accepted solution]

@BharatC @lucaslopesm 

This is absolutely a CSDM problem, which is what guides the routing. It's also because assigning support group and other groups to huge numbers of CIs via some form of custom logic is a recipe for disaster. CSDM seeks to make this far simpler by driving it from the (Technology Management) Service Offering.

The whole point of the Foundation domain is to ensure your CMDB data is accurate enough to: 

1. Support build out of Service Instances (Business Application instantiations)
2. Enable the build out of Technology Management Services and Offerings via Dynamic CI Groups

If you are struggling to avoid overlap with Dynamic CI Groups look again at the foundation data quality, and if that doesn't work, take a long hard look at your support model, as it may well be over-complicated.

I can recall several situations I have encountered where inadequate foundation data has slowed or even completely stalled a CSDM implementation. There's a reason it comes first and it's important to be disciplined about enforcing better data quality.

There are many examples of this kind of dynamic allocation of related objects in the platform so wherever possibly do your best to leverage them.

If after all that, you still cannot get things to work properly without some form of customisation, use custom logic to add CIs to a CMDB Group so your entire TMSO architecture is consistent (all TMSOs are linked to a DCG related to a CMDB Group with related CIs).

I hope this helps!
Mat

[lucaslopesm]

Thanks Mathew, I will evaluate the logic within the DCG groups!

[vaishali231]

Hey @lucaslopesm 

I would recommend using Technical Service Offerings (TSOs) with Dynamic CI Groups as the primary approach. I would avoid using a Business Rule or a custom class-level default field unless there is a specific gap that cannot be handled through the CMDB/CSDM model.

1. Why TSO + Dynamic CI Group?

The Support Group should represent who supports a CI or a specific set of CIs, rather than simply who supports an entire CI class.

Your Windows example demonstrates this well. Both a normal Windows server and a Domain Controller can belong to the Windows Server class, but their operational ownership is different.

You could model this as:

Standard Windows Servers

    Dynamic CI Group

    TSO: Windows Infrastructure

    Support Group: MS Windows Support

Domain Controllers

    Dynamic CI Group

    TSO: Domain Services

    Support Group: MS Domain Services Support

This allows the support responsibility to be determined by the characteristics of the CI instead of only its class.

2. How to handle overlapping Dynamic CI Groups

Your concern about overlap is valid. I would design the Dynamic CI Group filters to be mutually exclusive wherever those groups are being used to determine support ownership.

For example:

Group 1: Windows Server AND NOT Domain Controller

Group 2: Windows Server AND Domain Controller

This gives each CI a predictable support path and avoids ambiguity about which group should own it.

It is also useful to have an unclassified/catch-all group so that newly discovered CIs that do not match the expected criteria can be identified and corrected.

3. Control-M example

The same model can be applied to Control-M jobs if there is a reliable attribute that identifies the responsible team.

Control-M Finance Jobs

    TSO: Control-M Finance

    Finance Support

Control-M HR Jobs

    TSO: Control-M HR

   HR Support

The important part is having reliable CMDB data that the Dynamic CI Group can use to determine which operational group the CI belongs to.

4. Business Rule

A Business Rule is technically possible, but I would not make it the first choice. As more exceptions are introduced, the BR can gradually become a custom assignment engine containing class, application, environment, and other conditions.

That makes the solution more difficult to maintain and keeps ownership logic in code rather than in the CMDB/service model.

I would use a BR only for exception scenarios that cannot reasonably be modeled using CMDB/CSDM data.

5. Default field on the class

I would also avoid using a custom class-level default Support Group as the main solution.

It works when every CI in a class has the same support team, but your Domain Controller example already shows the limitation: same class does not necessarily mean same support ownership.

Recommendation

My preference would therefore be:

1. TSO + Dynamic CI Groups for the standard support ownership model.
2. Keep the Dynamic CI Group criteria mutually exclusive where possible.
3. Use the CI-level Support Group for genuine individual exceptions.
4. Use a Business Rule only when the ownership cannot be modeled cleanly through CMDB/CSDM

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb