CSDM – Recommended approach to populate Assignment Group based on Application Service or CI

[AvinashU]

Hi Community,

I am designing an incident model using CSDM for AWS/Azure discovered resources and would like to understand the recommended ServiceNow approach.

My requirement is:

• We have multiple Application Services.
• Each Application Service may have an Assignment Group.
• Application Services are related to the appropriate cloud account/AWS/Azure resources.
• On the Incident, users can select either an Application Service or a specific Configuration Item (CI).

I want the following behavior:

Scenario 1 – Application Service selected

If the user selects:

Application Service = SAP AWS

then the Incident Assignment Group should automatically populate with the Assignment Group defined for that Application Service.

Scenario 2 – CI selected

If the user selects a specific discovered CI, for example an AWS EC2 instance, ServiceNow should determine the appropriate Application Service for that CI and then populate the corresponding Assignment Group.

My question is:

What is the recommended OOB/CSDM approach for this requirement?

Should we use:

• Application Service Assignment Group?
• Dynamic CI Group?
• CI relationships/service mapping?
• Assignment rules?
• Another CSDM-supported mechanism?

I am particularly interested in avoiding unnecessary customization and following ServiceNow/CSDM best practices.

Also, is a Dynamic CI Group recommended for determining the Application Service from a selected CI, or is there a better OOB approach?

Thanks in advance for your guidance

[Sifatullah_solo]

Here is how I would do it with minimal customization:

1. Put the owning team in the Support group field of each Application Service (and on the Service Offering, if you use offerings - that is where CSDM expects routing to come from).

2. Let the service own its CIs. Whether the service is tag-based, built from a Dynamic CI Group or mapped, its members end up in the svc_ci_assoc table - so a Dynamic CI Group is a way to fill the service, not a routing mechanism on its own.

3. Route with an Assignment Rule (or a small before business rule): if the Service is set, use its support group; if only a CI is set, look up its Application Service in svc_ci_assoc and use that group; if nothing is found, fall back to the CI's own support group.

4. Decide up front what happens when one EC2 instance belongs to several services - most teams then use the CI's own support group.

[AvinashU]

Thanks. Let me explain our proposed structure.

Currently, we have a custom Project table, and the Cloud Account is linked to the Project. After cloud discovery, we are planning to remove the custom Project table and represent the Project using an Application Service (cmdb_ci_service_discovered). selected cmdb_ci_service_discovered correct table for application service?

The proposed relationship would be:

Application Service (Project) → Cloud Account → Discovered Cloud Resources

For Incident assignment, our proposed logic is:

1. Application Service is selected

• If the Application Service has an Assignment Group, use that group.

1. Configuration Item (CI) is selected

• If the selected CI has a specific CI Assignment Group, that group should take priority and replace the Application Service assignment group.

1. Fallback

• If the Application Service Assignment Group is empty and the CI Assignment Group is also empty, then use the Technical Service Offering (TSO) Assignment Group.

So the assignment priority would be:

CI Assignment Group → Application Service Assignment Group → TSO Assignment Group

The main objective is to have the Application Service represent the project/service context while allowing a specific discovered CI to route the Incident to the appropriate technical team when required