Service Graph Connector for WIZ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
We are currently configuring the Service Graph Connector for Wiz to ingest our GCP cloud infrastructure hierarchy (Organizations → Folders → Projects) into the ServiceNow CMDB using out-of-the-box structural tables (cmdb_ci_cloud_org, cmdb_ci_gcp_folder, and cmdb_ci_gcp_project).
During our implementation, we identified a critical limitation in the connector's data streams (specifically within SG-Wiz-Organization and SG-Wiz-Subscription) that prevents a standard deployment:
- The Issue: The integration payload only provides the upper layers of the governance hierarchy as plain text string paths or arrays of names (e.g., "Company/Region/Production"). It completely lacks dedicated, unique numeric identifiers (such as a distinct folderId or parentID) for these structural layers. So, when we receive data for a ‘project’ for example, that is contained by a ‘folder' we expect both the project ID and folder ID in the raw data. However, we only receive the project ID and ‘path’ that contains all string names making it difficult to identify the exact unique folder it is contained by.
- The Impact: Because the ServiceNow Identification and Reconciliation Engine (IRE) strictly requires a unique Object ID to securely create and link CIs without record collisions, using non-unique text names as primary identifiers breaks the mapping. If different business units use identical folder names (e.g., multiple folders named "Production"), the IRE merges them into a single record, corrupting the CMDB architecture.
Has anyone identified a way to resolve this ? If not, are there any planned enhancements for WIZ Service Graph Connector to ensure that Wiz's upstream GraphQL response passes distinct, unique IDs for folders and organizational branches alongside the raw resource metadata? This would allow the connector to natively build dependent CMDB relationships out-of-the-box without requiring high-maintenance custom ETL scripts.