- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We are trying to populate the support group according to CSDM guidelines and here is the path we used but support group is not populating after CSDM data sync scheduled job, Is anyone followed this below path to populate support group when it is empty. I could not find any field to add Dynamic CI group to the service offering (Technical Service offering). Is this being the mistake for not seeing the support group or did we not add the dynamic group to correct TSO
CMDB Group
↓
Dynamic CI Group
↓
Technology Management Service
↓
Technical Service Offering (TSO) (created downstream relationship manually between TSO and Dynamic CI group)
↓
Support Group
↓
CSDM Data Sync
↓
Windows Server CIs
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hey @praswethas,
The chain you diagrammed is basically right, but the relationship type and direction between the Technical Service Offering and the Dynamic CI Group is where this usually breaks. And no, there's no field for it on the TSO form on purpose, it's a CI relationship record, not an attribute, so you're not missing a form field.
- Relationship type: current CSDM guidance wants Contains::Contained by running from the TSO down to the Dynamic CI Group. Older instances and some legacy docs use Managed by::Manages instead, so confirm which one your version's CSDM Data Sync actually keys off before assuming the relationship is wired correctly.
- Direction: the TSO has to be the parent, Contains, and the Dynamic CI Group the child, Contained by. Reverse it and nothing propagates even though the relationship exists.
- Support group on the TSO itself: the sync only pushes down what's already populated on the TSO record. Empty Support group, Change group, or Managed by group on the TSO means there's nothing to send.
- Service Classification: check that the offering is actually set to Service Classification = Technical Service on service_offering. Naming it "TSO" doesn't make it one for sync purposes.
- Group membership: the Windows Server CIs need to actually satisfy the Dynamic CI Group's query at the moment the job runs, not just historically.
Also run CSDM Data Sync manually with Execute Now instead of waiting on the nightly job, and check the execution log for errors, there's a known issue on some instances where this scheduled job silently fails to run.
Thank you,
Vikram Karety
Octigo Solutions INC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @praswethas
Refer: Using Dynamic CI Groups to set Support Group
KB0952941 Technical Service Offerings with Support Group or Change Group Populated
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hey @praswethas,
The chain you diagrammed is basically right, but the relationship type and direction between the Technical Service Offering and the Dynamic CI Group is where this usually breaks. And no, there's no field for it on the TSO form on purpose, it's a CI relationship record, not an attribute, so you're not missing a form field.
- Relationship type: current CSDM guidance wants Contains::Contained by running from the TSO down to the Dynamic CI Group. Older instances and some legacy docs use Managed by::Manages instead, so confirm which one your version's CSDM Data Sync actually keys off before assuming the relationship is wired correctly.
- Direction: the TSO has to be the parent, Contains, and the Dynamic CI Group the child, Contained by. Reverse it and nothing propagates even though the relationship exists.
- Support group on the TSO itself: the sync only pushes down what's already populated on the TSO record. Empty Support group, Change group, or Managed by group on the TSO means there's nothing to send.
- Service Classification: check that the offering is actually set to Service Classification = Technical Service on service_offering. Naming it "TSO" doesn't make it one for sync purposes.
- Group membership: the Windows Server CIs need to actually satisfy the Dynamic CI Group's query at the moment the job runs, not just historically.
Also run CSDM Data Sync manually with Execute Now instead of waiting on the nightly job, and check the execution log for errors, there's a known issue on some instances where this scheduled job silently fails to run.
Thank you,
Vikram Karety
Octigo Solutions INC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thank you for solution, I have created the relationship between TSO and Dynamic CI group and also in service offering the team tab has support group, mentioned the support group helps to populate the support group for windows servers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
To slightly correct you: on your final bullet point, there is no query on the Dynamic CI Group; the queries are contained in the related lists of the linked CMDB Group - Query Builder Queries, Encoded Queries, or Manually-added Configuration items. This is why you will find no Service Configuration Item Associations for a Dynamic CI Group if it does not have a valid CMDB Group which returns at least one CI.