Support and Docs are "unreconciled" regarding Reconciliation Rules - why won't our field update?

[MikeLerch]

I have a support case open with ServiceNow because we're seeing some unexpected behavior based on our understanding of the documentation.  Support is telling us that what we're doing causes things to behave "weird" in an undocumented way, but that there's no PRB, and that smells fishy to us. 

Here's the (abbreviated and obfuscated for confidentiality) scenario.  Please give this a read, and let us know if we misunderstood something, or if you think we have a bug.  I'd love to hear your experience with static CI reconciliation rules.

• The problem:
  • The IP address of one of our Linux servers has changed.
  • ServiceNow Discovery is seeing the new IP address (it's in the payload), but the address is not getting updated in the CMDB.
    • As a reminder, the CI Class Hierarchy for Linux Server is Configuration Item > Hardware > Computer > 
      Server > Linux Server
• Our environment:
  • Reconciliation Rules
    • We have a two Reconciliation Rules at the Hardware level:
      • Discovery Source ABCDE, priority 75, for several specific fields including IP Address.
      • Discovery Source ServiceNow, priority 100, for all fields.  
    • We have one Reconciliation Rule at the Server level.
      • Discovery Source FGHIJ, priority 50, for some of Service Graph Connector fields.
    • Data Refresh Rules
      • We have Data Refresh rules at the Hardware level for all the data sources, all at 10 days.
  • CI History
    • Data Source FGHIJ did the initial insert of the CI, many months ago, and hasn't touched it since then.
    • ServiceNow Discovery has found it every day since then.
    • Discovery Source ABCDE has never had anything to do with this CI.

The IRE logs explicitly say that the Reconciliation rule for Discovery Source ABCDE is the problem.

"identification_engine : logId:[q1w2e3r4] Reconciliation: update to field 'serial_number' of CI 'a1s2d3f4' was skipped because of rules [(our ABCDE rule)] defined in cmdb_reconciliation_definition"

So that's unquestionable.  But we don't understand why.  Our understanding from the docs is that even though ServiceNow has a lower priority, because the other sources haven't updated the record, ServiceNow should be able to.  That's clearly not happening.  

What support is saying is that we are misunderstanding how it works and/or that there's a widely-known but unaddressed bug, stating that 'the Child Class rule overrides the parent rules, and cannot have more than one rule on the different classes for a child CI' and that 'you cannot have a Parent Reconciliation rule with two different classes.'  That definitely doesn't align with the documentation.

So there it is...any thoughts?  Also, since we have a multi-source CMDB and CMDB 360, I'm wondering if we should be shifting to Dynamic reconciliation rules?

Thank you for reading and I'm looking forward to participating in the discussion!

[Chelsea Ruel]

I can't help with this. But I just wanted to note that I have also experienced multiple SNOW support cases where Support describes "expected" behaviour that is not documented anywhere. 

We've only got access to the information that is documented. If you're "misunderstanding" how something works that's probably because you've had to piece together sparse documentation with trial and error.

If this is a bug they should help you fix it. If this is not a bug they should provide documentation of how it is supposed to work.

[Christopher Hub]

Take a look at Data Refresh Rules to supplement your reconciliation rules:  Create a data refresh rule.  From the docs: "Specify data refresh rules to determine if a CI is stale for a specific discovery source. Such CIs can then be updated by a lower-priority authorized discovery source."

My understanding is that lower priority sources can't update a CI just because another source did not, but rather, they must be sufficiently stale to allow that update, and a DRR must grant that ability.

[MikeLerch]

My understanding is that lower priority sources can't update a CI just because another source did not, but rather, they must be sufficiently stale to allow that update, and a DRR must grant that ability.

Agreed.  The issue here is that the other sources were sufficiently stale, but the IRE was still not allowing the lower priority data sources to update the record.

The resolution to my case was that they are going to update the documentation in the Australia release.  It will indicate that if you have a reconciliation rule set at the attribute level, rules with the "all attribute" toggle set will not be able to override them, even if the staleness rule has expired.  

I personally still don't think that's how it should work, but at least now there will be docs that say how it does work.

(PS we worked around it by getting rid of our attribute-specific rules.  Our business cases had changed such that we were able to do that.  Not everyone will be that fortunate)

[Christopher Hub]

"Agreed.  The issue here is that the other sources were sufficiently stale, but the IRE was still not allowing the lower priority data sources to update the record."

So, you do have Data Refresh Rules in place then?