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