Bidirectional Sync Conflict Resolution in ServiceNow: Fix It with an Attribute Authority Matrix
| Quick summary 1. Bidirectional sync conflict resolution starts with a problem most organizations do not see until a P2 incident land in the queue. A ServiceNow bidirectional CMDB sync write access conflict occurs when automated discovery and a human team both hold write access to the same CI attributes without an attribute-level authority matrix. This typically produces data oscillation: the same field cycles between correct and incorrect values across sync intervals. Resolving it requires per-attribute ownership rules, not record-level access controls, and a conflict notification that surfaces writes promptly. 2. Three related P2 incidents traced back to write-conflicted CI data cost one operations team 45 days of investigative rework. That is the organizational cost of skipping an authority matrix. 3. Bidirectional CMDB sync means data flows in both directions. It does not mean both sources can write everything. Yet that distinction is exactly where most organizations stumble. 4. In one environment we assessed over a recent 90-day period, the ServiceNow platform team and the infrastructure team both had write access to the same CI records. Neither had defined which team was authoritative for which attributes. The sync ran on a 6-hour cycle. Every assumption was that sync would “figure it out.” Every assumption was wrong. |
The assumption that broke the CMDB
Eighteen teams, two data sources, one database. The ServiceNow platform team (8 engineers) managed CMDB-level concerns: ownership, business service alignment, cost center. The infrastructure team (12 engineers) managed discovery, feeding network and OS data from Virima’s high-frequency discovery cycles into ServiceNow. Both teams assumed their data would coexist in ServiceNow without conflicts.
The platform that was supposed to resolve overlaps used a simple rule: the most recent write wins. No attribute-level authority rules. No per-source priority. Just last-write-wins applied globally.
For 340 CI records touched by both sources, 89 developed write conflicts. When Virima’s discovery sync reported a correct hostname, then an infrastructure engineer manually updated it with a stale value, then the next scan cycle corrected it again, that is not synchronization. That is oscillation.
| Data oscillation in a CMDB occurs when two sources both hold write access to the same CI attributes without defined ownership rules. Without an attribute authority matrix, each source overwrites the other on its own schedule. One digit of difference in an IP address can invalidate change-scoping decisions made against mid-oscillation data, producing a chain of downstream P2 incidents. |
What oscillation patterns look like on your CMDB
One of those 89 conflicted CIs was a database server. Virima’s discovery reported its IP address as 10.45.22.187, directly from active network scanning. An infrastructure engineer updated the same record in ServiceNow with 10.45.22.188, copied from a documentation spreadsheet that had not been updated when the server was migrated. The difference: one digit. The operational impact was significant.
The next Virima scan cycle corrected it back to .187. Six hours later, the engineer updated it again to .188. For 45 days, this CI oscillated between two values. Post-incident reviews surfaced the damage: 12 separate changes had been scoped against CI records mid-oscillation, between a manual write and the next corrective scan. Three related P2 incidents had already been logged before the pattern was identified.
Want to see your CMDB’s attribute authority gaps? Discover with Authority →
According to the Flexera 2025 State of ITAM Report, IT teams across industries are losing visibility into their technology estates, with CMDB data quality cited as a persistent top challenge. That finding reflects exactly what bidirectional sync conflict resolution failures produce at scale: good data and stale data occupying the same CI field, with no system to determine which source takes precedence.
The three root causes behind bidirectional sync conflict resolution failures
No source-of-truth designation per attribute
Both the infrastructure team and Virima’s sync treated themselves as authoritative for the same network and OS fields. There were no explicit rules stating that Virima owns IP address, hostname, and OS version, or that the infrastructure team owns server name, assigned location, and decommission date. Without a formal authority model that names each source’s scope, every bidirectional sync conflict resolution cycle becomes a recurring problem. We explore this governance gap further in our post on why a CMDB alone is not AI governance.
No write-conflict notification
Neither team saw the other’s writes happening. The conflict stayed invisible until a post-incident review surfaced it, weeks after the problem started. By that point, the damage had already extended into incident workflows. For more context on that downstream impact, see how service mapping can improve the IT incident management process.
Global last-write-wins with no source weighting
The sync was configured with one blanket resolution rule: most recent write wins, regardless of source reliability or data freshness. When a manual entry overwrites discovery data, the CMDB trusts the most recent action, not the most trustworthy source.
Industry patterns reflect this consistently. Organizations that address bidirectional sync conflict resolution with attribute-level authority rules tend to achieve significantly higher CMDB data accuracy than those relying on last-write-wins. The gap matters most during change windows, when stale CI data shapes P2 timelines.
How the attribute authority matrix resolved bidirectional sync conflict resolution
An attribute authority matrix assigns each CI attribute class to a single authoritative source. For ServiceNow deployments using bidirectional sync, it separates discovery-owned attributes (hostname, IP address, OS version, installed software) from manually-maintained attributes such as owner, cost center, and business service alignment. Once defined, write access is scoped to match, preventing conflicting writes at the field level rather than the record level.
The fix required three changes:
1. Define an explicit attribute authority matrix that names which source owns which attributes.
2. Restrict write access for each team and integration to its designated attribute scope.
3. Add conflict notification that alerts the Configuration Manager within 15 minutes when a write conflict occurs.
The attribute authority matrix looked like this:
| Attribute Class | Authoritative Source |
| Hostname, IP address, MAC address | Virima discovery |
| OS version, OS edition | Virima discovery |
| Installed software, versions | Virima discovery |
| Server name (display label) | Manual (infrastructure team) |
| Owner, owning team | Manual (ServiceNow team) |
| Cost center, business service | Manual (ServiceNow team) |
| Contractual lifecycle dates | Manual (ServiceNow team) |
This matrix reflects a clear principle. Discovery-sourced data should take precedence for network and OS attributes, because those attributes are discovered fresh every scan cycle. Manually maintained attributes stay in human hands, because teams are the authoritative source for ownership, business context, and organizational metadata.
Once defined, the infrastructure team’s write access was scoped to ownership-class fields. Virima’s sync priority rules were updated so that for discovery-owned attributes, Virima-provided values take precedence over manual writes, regardless of write recency. The data cycling stopped within the next scan cycle.
Virima’s bidirectional ServiceNow integration supports attribute-level priority rules. Discovery-sourced attributes (hostname, IP address, OS version, installed software) can be configured so Virima-provided values take precedence over manual writes, regardless of write recency. Business context attributes remain under the infrastructure or ServiceNow team’s control. For a full overview, see the Virima ServiceNow integration overview.
A 15-minute conflict notification was added to the ServiceNow integration log. Now, any time a manual edit overwrites a Virima-written value, the Configuration Manager sees it and can investigate why.
After the authority matrix was in place, the 89 conflicted CIs stabilized. Write cycling stopped. The 12-change-decisions-made-on-stale-data problem dropped to zero in the next 90-day period. That is not because discovery got smarter. It is because the two data sources stopped competing over the same fields.
See how Virima’s Trusted Runtime Truth model governs attribute authority across every CI class. Explore Trusted Runtime Truth →
Authority is not direction: the governing principle
“Bidirectional” describes data flow. It says nothing about data authority. Configuring a bidirectional sync without an attribute authority matrix is equivalent to granting two teams write access to a shared spreadsheet with no cell-level locking.
Bidirectional sync conflict resolution best practices are consistent across industry. Define per-attribute ownership before go-live. Restrict write access to match ownership. Surface conflicts promptly. The Trusted Runtime Truth model that Virima implements makes this principle explicit: Virima is authoritative for what it discovers. Human teams are authoritative for what only they can provide. For a deeper look at the governance architecture, see ServiceNow CMDB governance best practices.
For IT teams structuring a Virima ServiceNow bidirectional integration, the attribute authority matrix is a required foundation. It is the difference between a sync that reconciles and a sync that oscillates.
| To see how Virima builds attribute authority into every discovery-sourced CMDB, schedule a demo today. |
Frequently Asked Questions
What causes data oscillation in a ServiceNow bidirectional CMDB sync?
Data oscillation occurs when two sources, automated discovery and a human team, both hold write access to the same CI attributes without an attribute authority matrix. Each source overwrites the other’s values on its own cycle, causing the attribute to cycle between correct and incorrect states. It persists until per-attribute ownership rules are defined and write access is scoped accordingly. Servicenow, Ivanti, Jira service management, Halo, Xurrent.
What is an attribute authority matrix and how does it resolve bidirectional sync conflict resolution?
An attribute authority matrix assigns each CI attribute class to a single authoritative source. Network and OS attributes (hostname, IP address, OS version) are assigned to automated discovery; business context attributes (owner, cost center, business service) are assigned to human teams. Write access is then restricted to match ownership, preventing conflicting writes at the field level rather than the record level.
How do I decide which CI attributes should be discovery-owned vs. manually maintained?
Discovery-owned attributes are those that change with infrastructure state and can be verified programmatically: hostname, IP address, MAC address, OS version, installed software. Manually-maintained attributes require human judgment: asset owner, owning team, cost center, business service alignment, and contractual lifecycle dates. Discovery tools are authoritative for what they can observe; human teams are authoritative for what only they can provide.
How does Virima handle attribute authority in a bidirectional ServiceNow integration?
Virima’s bidirectional ServiceNow integration supports attribute-level priority rules. Discovery-sourced attributes (hostname, IP address, OS version, installed software) can be configured so Virima-provided values take precedence over manual writes, regardless of write recency. Business context attributes remain under the infrastructure or ServiceNow team’s control. This prevents last-write-wins oscillation while preserving human ownership of organizational metadata.
Which CI attributes does Virima own, and which remain under the infrastructure team’s control?
In a typical Virima ServiceNow deployment, Virima is authoritative for network and OS attributes: hostname, IP address, MAC address, OS version and edition, and installed software with versions. The infrastructure or ServiceNow team retains ownership of display labels, asset owner, owning team, cost center, business service, and contractual lifecycle dates. The split is formalized in an attribute authority matrix defined during integration configuration.
