Virima ServiceNow Sync Configuration Gotchas: 3 That Break the Integration
Three ServiceNow sync configuration gotchas silently break Virima’s CMDB sync without returning a visible error: an IRE policy set to “manual override always wins,” custom CI class hierarchies outside ServiceNow’s Common Information Model, and field-level encryption on CI attributes. All three present as a successful sync. CI records are not updated. This article identifies what each configuration does, why it breaks the sync, and how to resolve it before go-live.
Why the same sync configuration can behave differently across ServiceNow instances
ServiceNow instances accumulate years of configuration layering:
- IRE rules adjusted by a previous CMDB team
- CI class hierarchies built during a platform migration
- Encryption policies applied by a security team that didn’t coordinate with the CMDB team
The three configurations below appear in enough production ServiceNow instances that we encounter them regularly during integration setups. None of them returns a visible error that points directly to the problem.
According to HDI’s 2025 State of CMDB report, 62% of IT organizations report difficulty keeping their CMDB synchronized with their actual IT environment. Most attribute the problem to configuration conflicts that surface only after integration go-live. Diagnosing these conflicts in production costs time and delays visibility for your IT operations team.
Configuration 1: IRE set to “manual override always wins”
What breaks
Virima’s discovery data cannot update CI records even when it holds higher-confidence and more recently collected data. A hostname last manually entered 14 months ago beats a hostname Virima discovered this morning, because the Identification and Reconciliation Engine prioritizes manual entries globally.
Why it happens
ServiceNow’s IRE in many instances is configured to protect manual entries on the assumption that manual data is intentional and therefore authoritative. That assumption holds for ownership fields, cost center assignments, and contractual data. It breaks down for network and OS attributes, where manual entries go stale within weeks and automated discovery is the only reliable source of current data.
The setting often dates to an earlier CMDB project where the team was concerned about a discovery tool overwriting carefully maintained manual data. The intent was reasonable. The scope was too broad.
How to resolve it
Create a Virima-specific data source record in ServiceNow’s IRE configuration with a defined confidence tier. When setting up the Virima integration, the data source record in IRE should be named to match the Virima REST API service account and positioned at tier 2 — above other automated tools but below manual entries for ownership and contractual fields. Then define attribute-level override rules:
- Virima wins on hostname, IP address, OS version, OS edition, and installed software
- Manual entries win on ownership, cost center, business service assignment, and contractual lifecycle fields
This granular approach, called attribute-class-specific confidence tiering, ensures that discovery data authorizes the attributes it’s most reliable for while preserving intentional manual data in governance and ownership fields. ServiceNow’s IRE documentation details the steps for creating and ordering data sources; the key is to avoid a global “manual always wins” policy.
Configuration 2: Custom CI class hierarchy outside ServiceNow’s Common Information Model
What breaks
Virima’s discovery engine maps discovered assets to standard Common Information Model (CIM) CI classes. When a ServiceNow instance contains custom CI classes that inherit from non-standard parent classes, Virima creates a new CI in the nearest standard class on sync — and the custom class CI remains unchanged. Two records now exist for the same physical asset with no reconciliation rule linking them, creating duplicate inventory and conflicting dependency data in service mapping.
Why it happens
Long-running ServiceNow instances frequently contain custom CI classes added during platform migrations or bespoke integrations. A financial services firm that built a custom cmdb_ci_regulated_server class to track PCI-scoped assets for compliance workflows is a typical example. Healthcare organizations add custom classes to track HIPAA-regulated infrastructure. These custom classes served a real business need — but they sit outside ServiceNow’s standard CI model hierarchy.
Non-standard CI class hierarchies are particularly common in enterprises that have undergone platform migrations or built compliance-specific classes for financial services or healthcare regulatory requirements — contexts where ServiceNow’s CIM standards predated the current maturity level of those industries’ infrastructure classification needs.
How to resolve it
Before Virima integration go-live, run a CI class audit in ServiceNow. Export the CI class hierarchy and identify every class whose parent chain does not trace back to cmdb_ci through a standard CIM path. For each non-standard class, choose one of two resolutions.
The cleaner path is to migrate the custom class to its nearest standard CIM parent class and migrate existing CIs (Option A). This aligns the CMDB with ServiceNow’s Common Information Model architecture, which benefits service mapping accuracy downstream and improves consistency with ServiceNow’s own tooling and updates.
If the custom class must stay in place, create explicit reconciliation rules linking the custom class to Virima’s CIM-mapped output by serial number or hostname (Option B) — but plan for manual rule maintenance as Virima’s discovery output evolves.
Configuration 3: Field-level encryption on CI attributes
What breaks
Virima’s REST API sync cannot write to encrypted fields. ServiceNow’s encryption plugin silently rejects write attempts from external integrations when it covers CI attributes like IP address, hostname, or MAC address. No error appears in the sync log. The sync reports as successful. The encrypted fields are not updated. CI records contain stale values in exactly those attributes most critical for discovery accuracy.
This is one of the most insidious configuration gotchas because the integration appears healthy in the log, but the most critical attributes diverge from the source of truth.
Why it happens
Security and compliance teams apply field-level encryption to CI attributes containing regulated data in environments subject to HIPAA, PCI-DSS, SOC 2, or internal data governance policies. NIST SP 800-111 and PCI-DSS both recommend encryption of data at rest for sensitive identifiers — a standard that extends to network and system attributes stored in a CMDB. The encryption configuration is applied by a team that is not coordinating with the CMDB integration team. The security team’s mandate is data protection; the integration team’s mandate is data accuracy. Without pre-integration alignment, the two mandates conflict.
How to resolve it
Audit CI attribute encryption settings before Virima integration. Query the ServiceNow encryption context configuration to identify which fields on which CI classes have field-level encryption applied. In Virima’s default write scope, the fields most likely to be affected are hostname, IP address, OS version, and installed software — the same attributes that IRE tiering protects in Configuration 1. Field-level encryption on any of these will silently block Virima’s REST API writes.
For each field that Virima must write to, coordinate with your security team on one of two resolutions.
The preferred path is to create an integration-specific service account with field-level decrypt and re-encrypt permissions for Virima’s write operations (Option A). This preserves encryption at rest while allowing Virima’s integration user to decrypt, validate, and re-encrypt CI data during sync.
If a service account with decrypt permissions isn’t achievable in your environment, establish a separate CMDB staging table for discovery-sourced attributes that are exempt from field-level encryption (Option B). Virima writes to the staging table; a trusted internal ServiceNow transform populates the encrypted production fields from the staging table on a scheduled basis.
Both approaches require security team buy-in. Start this conversation early in your integration planning — field-level encryption is a critical control and should be preserved, but it must be transparent to the integration architecture to avoid silent data staleness.
Planning a ServiceNow integration and want to catch these before go-live? Virima’s integration team can run a pre-integration configuration audit against your ServiceNow instance before any deployment work begins. Request a configuration review →
What this tells you about your CMDB integration setup checklist
These three configuration gotchas share a common characteristic: each was put in place for a legitimate reason in a context that predated the Virima integration. A pre-integration configuration audit — specifically targeting IRE settings, CI class hierarchy, and field encryption — takes less time than investigating a silent sync failure three weeks after go-live.
Run these three checks before building your integration mappings:
| Check | What to audit | Expected outcome |
|---|---|---|
| IRE configuration | Confirm no global “manual override always wins” rule. Verify Virima data source record exists with tier-2 confidence and attribute-level overrides defined. | Virima’s discovery data updates hostname, IP, OS, and software fields; manual entries retain ownership and contractual fields. |
| CI class hierarchy | Export class hierarchy. Identify every class whose parent chain does not trace back to cmdb_ci via a standard CIM path. | All asset classes in Virima’s discovery scope trace to standard CIM parents, or explicit reconciliation rules exist for non-standard classes. |
| Field-level encryption | Query encryption context configuration. List every CI attribute with encryption applied. Cross-reference against Virima’s write scope. | No field in Virima’s write scope has encryption applied, or integration service account has decrypt/re-encrypt permissions. |
ServiceNow admins and configuration managers should also validate:
- Whether any CI attributes are subject to workflow modifications that might restrict external writes
- Whether integration service accounts have sufficient permissions on all CI classes in your hierarchy
- Whether any data quality rules or duplicate detection rules might interfere with upsert operations
Frequently Asked Questions
Why is Virima’s ServiceNow sync completing successfully but CI records aren’t being updated?
How do you configure ServiceNow IRE to allow a discovery integration to update CI records without overriding intentional manual data?
What ServiceNow CI class hierarchy checks should I run before connecting a discovery integration?
cmdb_ci through a standard Common Information Model path. For each non-standard class, determine whether existing CIs can be migrated to the nearest standard CIM class, or whether explicit reconciliation rules need to be created linking the custom class to the discovery integration’s standard-class output.
