Troubleshooting IRE Reconciliation: Why a Lower-Priority Source Can Still Update a CI

souravparhi
Kilo Contributor

3 hours ago

Hi ServiceNow Community,

While working with CMDB Identification and Reconciliation Engine (IRE), one scenario that can be particularly confusing is this:

A higher-priority data source has already populated an attribute on a CI, but later the same attribute appears to be updated by a lower-priority source. Why does this happen?

At first glance, we may assume that the higher-priority source should always win. However, reconciliation behavior can depend on several factors, including attribute-level rules, class hierarchy, source priority, Data Refresh Rules, staleness, dynamic reconciliation, and the actual ingestion path.

I wanted to share a structured troubleshooting approach and also hear how others in the community validate these scenarios.

1. Start with the exact CI class and attribute

First, confirm:

  • The CI's actual class
  • The exact attribute being updated
  • The data sources updating the CI

One important point is that reconciliation is attribute-oriented. The CI's discovery_source field alone should not be used to determine which source owns a specific attribute.

2. Identify the reconciliation rule that actually applies

In CI Class Manager, navigate through the class hierarchy and review:

Class Info → Reconciliation Rules

Use Preview Rule where applicable to understand the precedence for the attribute and the relevant data sources.

While reviewing the configuration, I normally check:

  • Is there an attribute-specific reconciliation rule?
  • Is there an Apply to all attributes rule?
  • Is the rule configured directly on the CI class or inherited?
  • What priorities are assigned to the individual sources?

An attribute-specific rule can take precedence over a broader Apply-to-all rule, and the class scope/inheritance should also be considered.

Also remember:

A smaller priority number represents a higher-priority source.

3. Do not overlook Data Refresh Rules

This is one of the areas I believe can easily cause confusion during troubleshooting.

Static reconciliation works together with Data Refresh Rules. If data from the higher-priority source becomes stale, an authorized lower-priority source may be allowed to update the attribute.

Therefore, check the Effective Duration against the actual refresh schedule of the integration.

A configuration should ideally reflect expected source behavior. For example, if Source A normally updates every 24 hours, the stale-data strategy should be designed around that expected cadence rather than selecting an arbitrary duration simply to prevent another source from updating.

Particular attention should be given to an Effective Duration of 0, based on the behavior documented for the applicable release.

4. Check whether Dynamic Reconciliation applies

Another important check is whether a dynamic reconciliation rule applies to the same attribute.

If dynamic reconciliation is active, troubleshooting the static reconciliation configuration alone may lead to the wrong conclusion.

So before assuming that source priority is not working, verify whether the attribute is governed by static or dynamic reconciliation.

5. Confirm that the integration is actually using IRE

This is another check that I find important.

A populated discovery_source value should not automatically be considered proof that an integration passed through the expected IRE reconciliation path.

For every source expected to participate in reconciliation, verify the ingestion mechanism and confirm that it is using a supported IRE processing path.

6. Review Data Source History

The cmdb_datasource_last_update table can be useful when investigating source/update history.

However, I would avoid treating a missing entry in this table as definitive proof of one particular problem.

Instead, I would correlate the history with:

  • Reconciliation rule configuration
  • When the rule was enabled
  • Source priority
  • Data Refresh Rules
  • Integration/IRE path
  • Actual CI attribute updates

This provides much stronger evidence than relying on one table alone.

7. Reproduce the behavior with a controlled test

For complex reconciliation issues, I find that a controlled test is often the safest approach.

A simple validation sequence could be:

  1. Select one non-production CI.
  2. Select one attribute, for example RAM or CPU count.
  3. Record its current value and source history.
  4. Confirm the reconciliation rule applying to that attribute.
  5. Confirm source priorities.
  6. Check the applicable Data Refresh Rule.
  7. Check for Dynamic Reconciliation.
  8. Submit a representative payload from the higher-priority source.
  9. Record the resulting value/history.
  10. Submit a representative payload from the lower-priority source.
  11. Compare the result.
  12. Change only one configuration variable at a time and repeat.

I think this approach makes the result much easier to explain and audit.

Example scenario

Consider the following simplified case:

Server CI → RAM attribute

  • Source A: Higher priority
  • Source B: Lower priority

Source A updates RAM first.

Later, Source B appears to overwrite the RAM value.

Rather than immediately concluding that reconciliation has failed, I would check the following in order:

Attribute-specific rule → class/inherited rule → source priority → Data Refresh/Effective Duration → Dynamic Reconciliation → ingestion path → Data Source History

This sequence can help isolate whether the observed behavior is expected reconciliation behavior or an actual configuration/integration issue.

Additional troubleshooting consideration

If the result is still inconsistent, another configuration worth reviewing is:

glide.identification_engine.enable_reconciliation_filter_before_update

The timing of reconciliation-filter evaluation can affect behavior in relevant scenarios. I would recommend reviewing the documentation applicable to the instance release and performing an impact assessment before changing this type of property, particularly in production.

Practical validation checklist

✅ Correct CI class confirmed
✅ Exact attribute identified
✅ Attribute-specific reconciliation rule reviewed
✅ Apply-to-all rule reviewed
✅ Direct versus inherited rule checked
✅ Source priority confirmed
✅ Data Refresh Rule and Effective Duration reviewed
✅ Dynamic Reconciliation checked
✅ Integration confirmed to use the expected IRE path
✅ Data Source History reviewed
✅ Controlled tests completed in sub-production
✅ Expected vs. actual values and timestamps documented

Questions for the Community

I would particularly like to hear how others approach these scenarios:

  1. How do you validate reconciliation behavior for existing CIs, beyond testing only CI identification?
  2. How do you document expected vs. actual attribute ownership when multiple sources manage the same CI?
  3. What approach do you use for governing Effective Duration across CI classes with different discovery/integration schedules?
  4. Are there any other troubleshooting checks you consider essential when a lower-priority source unexpectedly updates an attribute?

Interested to learn from the community and compare approaches that make IRE reconciliation behavior more predictable, repeatable, and auditable.

Thanks in advance for sharing your experiences and recommendations!

References

Version note: Validate the behavior against the ServiceNow release and capabilities enabled in your own instance. Product features, navigation, and reconciliation behavior can vary by release and configuration.

  • 55 Views
0 REPLIES 0