The actual number of imported records does not match the total count in Intune.

[mmm22345n]

I am currently attempting to import data from Intune using the Service Graph Connector (SGC).

However, I am facing an issue where the full set of data from Intune is not being committed to the cmdb_ci_computer table. For the Identification Rules (IRE), I have configured it to use the Intune Device ID and MAC Address for identification, as Serial Numbers and Names often have duplicates, leading to improper imports.

Interestingly, the missing data exists in the staging table SG-Intune Device, but not in SG-Intune Computer. Furthermore, when I test the missing data using the Identification Simulator, it shows a status of "INSERT".

Does anyone have any insights into what might be causing this discrepancy?

[DanielJ43996773]

Hi @mmm22345n how are you?

If the records are present in SG-Intune Device, but not reaching SG-Intune Computer / cmdb_ci_computer, the issue is probably not only with the IRE identification rule.

The Identification Simulator showing INSERT means IRE is able to identify that the payload could create a CI, but something is likely preventing the record from moving through the full SGC pipeline.

I would check the following areas:

Transform / mapping between SG-Intune Device and SG-Intune Computer

Confirm whether the missing records meet all conditions required to be promoted from the device staging table into the computer staging table. There may be filters or mapping logic that exclude certain Intune device types, ownership types, operating systems, or incomplete records.

Required fields for cmdb_ci_computer

Even if IRE says INSERT, the final commit can fail if mandatory or expected fields are missing or invalid.

Check whether the missing records have valid values for:

Intune Device ID
MAC Address
OS / device type
Manufacturer / model
Correlation ID or source-native key
Class mapping target

IRE is not the same as commit success

The simulator validates identification logic, but the actual import also depends on:

Transform map logic
Robust Import Set Transformer
CMDB Data Manager / reconciliation rules
Class mapping
Reconciliation precedence
Errors in import logs

Review import and CMDB error logs

I would check:

Import Set logs
Transform history
CMDB IRE logs
Identification/reconciliation errors
SGC job execution logs
Records marked as ignored, skipped, or failed

Validate the identifier strategy

Using Intune Device ID is usually a better identifier than name, and MAC address can help, but MAC can also be unreliable for devices with multiple adapters, randomized MACs, VPN adapters, or missing network data.

A good pattern is usually:

Intune Device ID / source native key as the strongest identifier
Serial number as secondary where reliable
MAC address as supporting identifier, not always the only match key

Check reconciliation / data source precedence

If another source already owns or updates the same CI class, ServiceNow may prevent Intune from updating certain attributes depending on reconciliation rules and precedence.

My recommendation would be to pick one missing device and trace it end-to-end:

Confirm it exists in SG-Intune Device
Check whether it is created in SG-Intune Computer
Review transform status and error details
Confirm the class mapping target
Run the IRE payload
Check CMDB/IRE logs for skipped or rejected commits

The key clue is that the data is in the first staging table but not the next one. That usually points to a connector mapping/filter/transform issue before IRE commits to cmdb_ci_computer, rather than the identification rule alone.

If this answer helps, please mark it as helpful.

Regards,
Dan