Understanding Reconciliation Filter Behavior in IRE - Support and Troubleshooting

Understanding Reconciliation Filter Behavior in IRE .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Summary This article explains how the Reconciliation Filter Condition behaves based on the system property:

glide.identification_engine.enable_reconciliation_filter_before_update

The behavior determines when the filter condition is evaluated — before or after an update — and how this affects which data sources are allowed to modify a CI.

Overview The IRE (Identification and Reconciliation Engine) supports filtering rules that define:

Which data source is allowed to update specific attributes. Under what conditions (filter criteria) those updates are permitted. The system property controls when ServiceNow evaluates these conditions:

Property Value Behavior false Filter applied after update true Filter applied before update Example Payload Format (Reference Only) Below is a simple example of a typical payload used by Identification Engine API:

Reconciliation Rules Used in Tests Data Source Priority Attribute Condition ServiceNow 10 RAM Operational Status is not Retired ServiceWatch 20 RAM Operational Status is not Retired

Test 1: Property Disabled ( false ) glide.identification_engine.enable_reconciliation_filter_before_update = false Behavior Payload updates the CI first. After the update is done, the reconciliation condition is checked. If the update itself causes the CI to become Retired, the condition fails after the update. Since validation happens after updating, any data source is allowed to modify attributes. Case 1 Existing CI Name Operational Status RAM CI1 Operational 1024 Incoming Payload (Source: ServiceWatch) Updates RAM to 3062 and Operational Status to Retired.

Result RAM updated → 3062 Operational Status updated → Retired Explanation Because the CI is updated before the reconciliation condition is evaluated, the filter sees the CI as already Retired, causing the condition to fail. When the condition fails, the reconciliation rules are bypassed and any data source can update the fields.

Test 2: Property Enabled ( true ) glide.identification_engine.enable_reconciliation_filter_before_update = true Behavior Condition is evaluated before applying any updates. If CI passes the filter → Only the data source defined in the rule (with highest priority) can update controlled attributes. If CI fails the filter → Reconciliation rules are skipped and all sources are allowed to update. Undefined data sources (e.g., Tivoli) can also update if filters fail. Case 1 — Lower Priority Source Attempting Update Existing CI Name Operational Status RAM CI1 Operational 1024 (last updated by ServiceNow) Incoming Payload (ServiceWatch) RAM: 3062 Name: CI1 Operational Status: 6 (Retired) Result RAM → remains 1024 Operational Status → updated to Retired Explanation RAM is protected by the rule and ServiceWatch has lower priority → cannot update RAM. Operational Status is not restricted → updated successfully.

Case 2 — CI Already Retired Existing CI Name Operational Status RAM CI1 Retired 1024 Incoming Payload (ServiceNow) RAM: 3062 Name: CI1 Operational Status: 1 (Operational) Result RAM updated → 3062 Operational Status updated → Operational Explanation The CI fails the filter (status = Retired). When the condition fails, the system allows any data source to update all fields, including controlled attributes.

Case 3 — Lower Priority Data Source Existing CI Name Operational Status RAM CI1 Retired 3062 Incoming Payload (ServiceWatch) RAM: 2048 Name: CI1 Operational Status: 1 (Operational) Result RAM updated → 2048 Operational Status updated → Operational Explanation Retired CIs fail the filter. With a failed filter, priorities and rule definitions no longer matter — all fields are editable.

Case 4 — Undefined Data Source (Tivoli) Existing CI Name Operational Status RAM CI1 Retired 2048 Incoming Payload (Tivoli) RAM: 1024 Name: CI1 Operational Status: 1 (Operational) Result RAM updated → 1024 Operational Status updated → Operational Explanation Even though Tivoli is not defined in any Reconciliation Rule, the failed filter condition allows any datasource to update the CI.

Summary of Behavior When Property = false (Disabled) Behavior Description Reconciliation Check After update Impact The CI is updated first. If the update causes the CI to become Retired, the condition fails afterward. Outcome CI fields can still be updated because rule validation is too late to block the update. When Property = true (Enabled) Behavior Description Reconciliation Check Before update If Condition Passes Only the allowed, highest-priority data source updates the controlled fields. If Condition Fails Any data source (even undefined ones) can update the CI. Key Rules If CI passes the filter condition: → Controlled fields can be updated only by the highest-priority data source. If CI fails the filter condition: → Reconciliation is bypassed → All data sources can update the CI, regardless of priority or rule definition. Additional Resources Understanding IRE Reconciliation Rules https://www.servicenow.com/community/cmdb-articles/understanding-ire-reconciliation-rules/ta-p/3289239