Reconciliation Definition Issue

[Deepika Mishra]

Hi Community,

I'm working on a CMDB integration scenario where updates can come from two sources:

• WorkspaceONEUEM (via IntegrationHub)
• Excel Uploads (via Robust Import Set)

Both sources target the same table: u_cmdb_ci_comm_mobility.

✅ Goal:

Allow updates from either source only if the incoming data is newer than what’s already in the CMDB. I want to avoid hardcoding field names, so I’ve left the Attributes tab empty in the Reconciliation Definitions.

🔧 Setup:

• Rule A:
  • Data Source: SG-WorkspaceONEUEM
  • Priority: 100
  • Applies To: u_cmdb_ci_comm_mobility
• Rule B:
  • Data Source: Excel Import Set
  • Priority: 110
  • Applies To: u_cmdb_ci_comm_mobility
• Attributes: None selected (intended to allow updates to any field)

❓Issue:

Despite this setup, updates are not being applied consistently. It seems like the reconciliation logic is not triggering or not respecting the timestamp comparison.

Has anyone successfully implemented a similar setup? Do I need to explicitly define attributes even if I want all fields to be eligible? Or is there a better way to enforce "newer data wins" logic across multiple sources?

Thanks in advance!

[shantanu_patel8]

Hi @Deepika Mishra 

You can go through this https://www.servicenow.com/docs/bundle/yokohama-servicenow-platform/page/product/configuration-manag...

It has some references to how you can configure overlapping reconciliation rules.

Please mark the answer helpful and correct if it resolves the issue. Happy scripting 

-Shantanu

[Deepika Mishra]

Hi @shantanu_patel8 ,
I am not looking for ServiceNow docs. I know I can go and fetch the details from there. My issue is the scenario which I posted. If you have a solution for it please let me know.

[scottl]

Ensure that the Source Recency Timestamp being set against the record in the mapping of the ETL is not in the future. ServiceNow's IRE is not consistent either as I too have found issues where the record will not update when it is expected to.  Have a look at the Data 360 data too but again, that's another SN unreliable source as I have found that doesn't work as expected either.  Delete the records associated to those CI's from the sys_object_source table to, to try and get it to refresh.