CSDM Data Sync: Managed By Group and Relationships Cleared When CI Falls Out of Dynamic CI Group Membership - Support and Troubleshooting

CSDM Data Sync: Managed By Group and Relationships Cleared When CI Falls Out of Dynamic CI Group Membership Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Description

When any CI attribute changes such that the CI no longer matches a Dynamic CI Group's query filter criteria, the following changes occur automatically:

Managed By Group — reverted to NULL or a class-level default from cmdb_class_info Service Configuration Item Association (svc_ci_assoc) — association record deleted Related Services relationships — removed from the CI Common scenarios that trigger this behavior include (but are not limited to): lifecycle stage changes, operational status changes, location changes, OS changes, state changes, or any other field referenced in the Dynamic CI Group's query filter.

Customers often report that the "CSDM Data Sync" scheduled job is inactive and question how this is happening. The key insight is that the CSDM Data Sync scheduled job and the CSDM Business Rules are entirely separate mechanisms. The Business Rules fire reactively on svc_ci_assoc record deletion, regardless of whether the scheduled job is active or inactive.

Cause

This is OOB (out-of-box) CSDM behavior, not a bug. The CSDM Data Sync framework consists of multiple independent components that maintain alignment between Technical Service Offerings, Dynamic CI Groups, and CI attributes. When a CI drops out of its Dynamic CI Group due to a filter mismatch, the framework automatically reverts the Managed By Group to either a class-level default or NULL.

Components Involved

1. Scheduled Job: Update svc_ci_assoc and Error Counters

This OOB scheduled job runs periodically (default interval: every 5 minutes) and performs the following:

Re-evaluates all Dynamic CI Group (cmdb_ci_query_based_service) membership by re-running each group's query filter Adds new svc_ci_assoc records for CIs that now match the filter Deletes svc_ci_assoc records for CIs that no longer match the filter Updates CI counters on services and removes duplicate count records 2. Business Rule: CSDM Data Sync on removed association

This OOB Business Rule is registered on the Service Configuration Item Association [svc_ci_assoc] table:

When: After Operation: Delete only (Insert and Update are unchecked) Filter Conditions: Service Id.Service classification is Technology Management Service AND Service Id.Class is Dynamic CI Group Script:

(function executeRule(current, previous /*null when async*/) { var job = new GlideRunScriptJob(); job.scheduleScript("new CSDMCMDBUtil().updateCiOnAssocDelete(" + JSON.stringify(current.getValue("ci_id")) + ")"); })(current, previous); This BR queues an asynchronous script job calling CSDMCMDBUtil.updateCiOnAssocDelete(), passing the CI sys_id from the deleted svc_ci_assoc record. The async job executes on a background worker thread.

3. Script Include: CSDMCMDBUtil

Function: updateCiOnAssocDelete(ciSysIds)

This function performs the following logic when called:

Step A: Queries svc_ci_assoc to check if the CI is still associated to another Dynamic CI Group with service_classification = Technical Service. If yes, it attempts to inherit the Managed By Group value from that group's parent Technical Service Offering (most recently created TSO with a MBG value takes precedence). Step B: If no other DCG association exists, the CI sys_id remains in the "to revert" array. Step C: Calls revertMBGToClassValueOrNull() for all CIs that need reverting. Function: revertMBGToClassValueOrNull(cis, tsoMbgValue)

This function determines the fallback Managed By Group value:

If a tsoMbgValue is provided (from another TSO), uses that value If no tsoMbgValue, queries cmdb_class_info table for the CI's class to check for a default managed_by_group If cmdb_class_info has a default, uses that value If no default exists anywhere, sets managed_by_group to NULL Executes updateMultiple() to apply the change to all affected CIs of that class 4. Other Related CSDM Business Rules

The following additional OOB Business Rules are part of the same framework and may trigger similar MBG clearing in different scenarios:

CSDM Data Sync on DCG delete — fires when a Dynamic CI Group record itself is deleted; reverts MBG for all CIs that were associated to it CSDM Data Sync on removed relationship — fires when the cmdb_rel_ci relationship between a Technical Service Offering and a Dynamic CI Group is deleted CSDM Data Sync on TSO deletion — fires when a Technical Service Offering record is deleted CSDM Data Sync on Reclassification — fires when a CI's sys_class_name changes (reclassification) Sync From TSO to CI (Script Action) — propagates Managed By Group from a Technical Service Offering down to CIs via Dynamic CI Groups Sync Managed By Group from CI Class (Script Action) — batch syncs MBG values for CIs of a given class Sequence of Events

The following is the typical sequence when a CI attribute changes such that the CI no longer matches a Dynamic CI Group's query filter:

Step 1 — CI attribute changes Actor: User / Discovery / Workflow / Any update source Detail: A CI field referenced in the Dynamic CI Group's query filter is updated to a value that no longer satisfies the filter criteria. The Managed By Group is NOT cleared at this point — the CI still retains its original MBG value.

Step 2 — Dynamic CI Group membership re-evaluated Actor: Scheduled Job (system) Detail: "Update svc_ci_assoc and Error Counters" runs on its next interval. The job re-runs the Dynamic CI Group's query filter, determines the CI no longer qualifies, and deletes the svc_ci_assoc record linking the CI to the group.

Step 3 — Business Rule fires on svc_ci_assoc delete Actor: System (Business Rule) Detail: "CSDM Data Sync on removed association" fires after the delete. Queues an async GlideRunScriptJob calling CSDMCMDBUtil.updateCiOnAssocDelete().

Step 4 — Async job executes CSDMCMDBUtil Actor: System (background worker) Detail: updateCiOnAssocDelete() checks if the CI is still associated to any other Dynamic CI Group. If yes, inherits MBG from that group's parent TSO. If no other association exists, checks cmdb_class_info for a class-level default. Falls back to NULL if no default exists.

Step 5 — Managed By Group cleared Actor: System Detail: updateMultiple() sets managed_by_group to the determined value (another TSO's MBG, class default, or NULL). Audit history shows the change made by "System" user.

Timing note: There is typically a delay of 1–10 minutes between Step 1 and Step 2, depending on when the scheduled job next runs (default: every 5 minutes). This delay often causes confusion, as the MBG clearing does not happen immediately when the CI attribute is changed.

Resolution Options

Option 1: Set a Class-Level Default in cmdb_class_info (Recommended)

If the customer wants the Managed By Group to fall back to a specific value rather than NULL when a CI drops out of a Dynamic CI Group:

Navigate to cmdb_class_info.list Find or create a record for the relevant CI class (e.g., cmdb_ci_vmware_instance, cmdb_ci_linux_server) Set the managed_by_group field to the desired default group The CSDMCMDBUtil.revertMBGToClassValueOrNull() function checks this table as a fallback before defaulting to NULL. This is the least disruptive option as it works within the existing OOB framework.

Option 2: Adjust the Dynamic CI Group Filter

If the customer wants CIs to retain their Dynamic CI Group membership regardless of the attribute change, they can modify the group's query filter to be more inclusive. This prevents the svc_ci_assoc record from being deleted, so the entire chain never fires.

Consideration: This means CIs that would otherwise be excluded will remain members of the group and will be counted in service CI totals, which may not be desired from a service modeling perspective.

Key Takeaways

The "CSDM Data Sync" scheduled job and the CSDM Data Sync Business Rules are completely separate mechanisms. The scheduled job being inactive does NOT prevent the Business Rules from firing. The Business Rules fire reactively on svc_ci_assoc record deletion, regardless of what caused the deletion. The "Update svc_ci_assoc and Error Counters" scheduled job is the process that re-evaluates Dynamic CI Group membership and removes associations for CIs that no longer match the group filter. This job runs independently of the "CSDM Data Sync" job. Any CI attribute change that causes a filter mismatch with a Dynamic CI Group can trigger this chain — it is not limited to lifecycle changes. The complete chain involves multiple execution contexts: user transaction → scheduled job (worker thread) → business rule → async script job (worker thread). This cross-context execution makes the issue difficult to diagnose without Splunk log analysis. Audit history will show the Managed By Group change made by "System" user, confirming it was an automated background process. The cmdb_class_info table provides a fallback mechanism — if a class-level default managed_by_group is configured, CSDMCMDBUtil will use that value instead of NULL when reverting.