Asset not getting created for few CIs via Meraki Integration

[Aman Trivedi1]

Hi All,

We are facing an issue with inconsistent asset creation for WAP CIs (cmdb_ci_wap_network) coming from Meraki integration via Service Graph Connector.

🔹Scenario
• Total CIs: ~3890
• Asset created: ~3601
• Asset missing: ~289

All CIs have:
• model_id populated
• Asset tracking strategy = Leave to category
• Valid Model Category mapping (IP Address / IP Switch – OOTB setup)
• Discovery Source = SG – Meraki

🔹Observed Behavior
• For some CIs, asset is created successfully
• For others, asset is not created during insert

🔹Validation Done
Based on https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0749624 KB (KB0749624),
we have validated:
• Model Category exists for the CI class
• No duplicate Model Category for the same CI class
• Asset class is correctly mapped
• Enforce CI verification is not enabled
• Asset tracking strategy is not set to “Do not create assets”

Question:
Has anyone faced similar issues where asset creation is inconsistent for records inserted via Service Graph Connector / IRE?

[Naveen20]

Root cause almost always comes down to timing of attribute population during IRE processing, not the configuration itself.

Here's what's most likely happening and how to investigate:

Most probable root cause: model_id not present at insert time

When Service Graph Connector pushes data through IRE, the processing often happens in two phases — the CI is first identified/created, then attributes are reconciled in a subsequent update. The business rule "Create asset for CI" (on cmdb_ci) fires on insert only. If model_id isn't populated until the reconciliation pass (the update), the asset creation logic never triggers because the insert-time check finds no model and skips it.

You can validate this by checking the sys_audit table for the 289 problem CIs — look at whether model_id was set on the initial insert operation or on a subsequent update. If audit shows the model_id arriving as an update rather than on insert, that confirms the timing issue.

Other things worth investigating:

The IRE operation order in the Service Graph Connector payload matters a lot. If the connector's ETL map pushes the CI record and the model relationship as separate operations, the CI insert can land before the model association. Check the Service Graph Connector's robust transform map and see if model_id is part of the primary CI payload or comes through as a related entry/relationship in a subsequent operation.

Also check whether the 289 failing CIs share any common trait — same batch/import set run, same time window, specific model, or a particular source_native_key pattern. This can reveal whether it's a race condition in parallel IRE threads or a data-specific issue.

Possible remediation approaches:

For the immediate gap, you could write a scheduled job or fix script that queries cmdb_ci_wap_network where asset is empty but model_id is populated, and programmatically triggers asset creation using the CreateAsset script include. Something like calling new CreateAsset().createAssetFromCI(ciGr) for each orphaned record.

For the long-term fix, there are a couple of paths. First, check if there's a business rule "Sync CI and asset on update" or similar that handles asset creation on CI update (not just insert) — in some versions/patches this exists but may be disabled. Second, you can create a custom after business rule on cmdb_ci_wap_network that fires on update when model_id changes from empty to populated and asset is still empty, then triggers the asset creation. Third, consider opening a case with ServiceNow support referencing this pattern — there have been known PRBs around IRE + HAM asset creation timing, and a targeted patch or workaround may already exist for your version.