Target record and Target table fields are empty in SG-Meraki Staging Table

[Amit Bhatt]

Hi everyone,

I am currently implementing the Service Graph Connector for Meraki using IntegrationHub ETL, and I've run into a UI quirk that I'm hoping to get some clarity on.

When I look at my Staging Table / Import Set list view, the data is processing successfully (State = Processed), and my target CIs (like cmdb_ci_ip_firewall, MAC Addresses, and Serial Numbers) are being created and updated perfectly in the CMDB.

However, the Target record, Target table, and Transform Map columns on the staging table list view are completely (empty) for every single row.

I know that Service Graph Connectors use the Robust Transform Engine (RTE) instead of legacy Transform Maps. Because the RTE does 1-to-Many mappings (e.g., splitting one staging row into a Firewall, a Serial Number, and a Network Adapter record), I assume ServiceNow leaves that single Target record field blank by design since it can't link to three places at once.

My questions for the community are:

1. Is it 100% expected, out-of-the-box behavior for these specific columns to remain blank when using the RTE / Service Graph Connectors?

2. Outside of checking the JSON payload in the Comment field or digging into the Transform Target Rows related list at the bottom of the Import Set, what is your best practice or preferred method for quickly auditing and clicking through to the newly created target CIs?

Thanks in advance for any insights!

[Vishnu-K]

Hi @Amit Bhatt ,

Yes  this is completely expected, out-of-the-box behavior. Nothing is broken on your end.

The "Target record," "Target table," and "Transform Map" columns on the staging table list view were built for the classic 1-to-1 Transform Map model, where one import row produces exactly one record in one target table. Since there is a single destination, ServiceNow can populate those columns cleanly.

Service Graph Connectors work differently. They use the Robust Transform Engine (RTE), which is designed to take a single staging row and split it into multiple CMDB records simultaneously — in your Meraki case, that means a cmdb_ci_ip_firewall, a cmdb_serial_number, a cmdb_ci_network_adapter, and potentially relationship records, all from one row. Because there is no single target record to point to, ServiceNow intentionally leaves those legacy columns blank. There is nowhere to store three or four sys_ids in a field that holds one.

Your data processing correctly (State = Processed) and your CIs being created and updated in the CMDB is the actual confirmation that the RTE ran successfully. The blank columns are a UI limitation of the legacy import set view, not a sign of failure.

For auditing and navigating to the created CIs, here are the approaches I use:

1. Transform Target Rows related list (what you already found)
This is the right place. Each entry in that related list maps to one of the target entities created from that staging row and gives you a direct link to the CI. It is the RTE's equivalent of the "Target record" column.

2. sys_object_source table
Navigate to sys_object_source.list and filter by your Discovery source (SG-Meraki). Every CI that the connector has touched will have an entry here, including a reference link back to the actual CI record. This is especially useful for bulk audits.

3. Target CI list view filtered by Discovery source
Go directly to cmdb_ci_ip_firewall.list (or whichever class you want to audit), add a filter for Discovery source = SG-Meraki, and sort by sys_updated_on descending. Fast way to spot-check a recent run.

4. Comment field JSON payload
The JSON in the Comment field is the RTE's per-entity summary. Look for keys like "errors" or "incomplete" against each entity type (e.g., cmdb_serial_number, cmdb_ci_network_adapter) to catch partial failures. If all you see is "mergedPartialPayloads" and "partial," that typically just means the record was merged from multiple payloads across runs not an error.

5. IntegrationHub ETL Studio ($cmdb_integration_studio.do)
If you need to trace exactly how a field was mapped or debug a specific entity, open the ETL studio, find your Meraki definition, and use the test/preview mode. It walks you through the transform step by step.

Personally I use sys_object_source for bulk audits and the Transform Target Rows list for drilling into individual records.

If this helped you please do mark it as helpful and accept the solution

Thanks,

Vishnu

Hope that helps!