Resolving OV Value Mismatch Between Reltio and Databricks Using Value-Based Priority Survivorship)

Question

Customers using the Reltio-to-Databricks connector (ovOnly: true) observed inconsistencies where attribute Official Values (OVs) displayed in Reltio UI differ from those appearing in Databricks tables.
This article explains the root cause, the corrective configuration, and the verification steps to resolve the issue by using Value-Based Priority Survivorship.

Symptoms

• The Last Name or other attribute OV in Reltio UI did not match the OV extracted into Databricks.

• Re-indexing or re-syncing entities does not resolve the mismatch.

• Connector configuration uses "ovOnly": true.

• Databricks connector table (e.g., entity_person) shows a non-OV value in columns such as Label.

• The issue persists across multiple exports or connector runs.

When multiple crosswalks contain the same attribute value updated at identical timestamps (LUD), the Reltio survivorship engine has no deterministic method to select which source should define the OV.

Without additional configuration, the system may alternate between crosswalks across API calls or connector syncs, resulting in inconsistent OV selection between:

• Reltio UI

• Connector (Databricks, BigQuery, Snowflake, etc.)

This behavior occurs because sortCrosswalksInLUDNonAdvanced is not enabled, and no explicit value-based priority order is defined for those attributes.

Resolution

The customer implemented a Value-Based Priority Survivorship rule that explicitly prioritizes contracts based on status (Active vs. Canceled) and dependent hierarchy.

This rule ensures that Reltio always selects attribute values (e.g., Last Name, Address) from the correct, active contract — and that the same OV is consistently sent to downstream systems like Databricks.

How the Rule Works

The survivorship logic uses a dependent number status key to determine the correct source contract in the following order of precedence:

1. Active contracts are always prioritized over canceled contracts.

2. Within active contracts, the dependent number determines which record takes priority:

   • A0 → Subscriber (highest priority)

   • A1 → Spouse

   • A2 → Dependent

3. Canceled contracts are then considered only if no active contracts exist, in the order:

   • C0, C1, C2

4. Fallback logic handles cases where multiple contracts of the same type exist (e.g., multiple A1 records) by selecting the most recent Last Updated Date.

This hierarchy forms the value-based priority list:

Example: 

A0 > A1 > A2 > C0 > C1 > C2

Configuration Example

In the survivorship configuration JSON for Last Name and Address attributes:

"survivorship": {
  "mode": "VALUE_BASED",
  "priorityValues": ["A0", "A1", "A2", "C0", "C1", "C2"],
  "fallback": {
    "strategy": "LAST_UPDATED"
  }
}

mode: Enables Value-Based Priority Survivorship.

priorityValues: Defines the ranking order using the dependent number status key.

fallback: Ensures tie-breaking logic uses the most recent update if multiple values share the same key.

Survivorship definition for Last Name.

{
                            "attribute": "configuration/entityTypes/Person/attributes/LastName",
                            "primaryAttributeUri": "configuration/entityTypes/Person/attributes/DepNoStatusKey",
                            "fallbackStrategies": [
                                {
                                    "attribute": "configuration/entityTypes/Person/attributes/LastName",
                                    "fallbackStrategies": [
                                        {
                                            "attribute": "configuration/entityTypes/Person/attributes/LastName",
                                            "survivorshipStrategy": "OldestValue"
                                        }
                                    ],
                                    "survivorshipStrategy": "LUD"
                                }
                            ],
                            "fallbackUsingCriteria": "ZERO_OR_MORE_THAN_ONE",
                            "survivorshipStrategy": "OtherAttributeWinnerCrosswalk"
                        },

Survivorship definition for DepNoStatusKey

  {
                            "attribute": "configuration/entityTypes/Person/attributes/DepNoStatusKey",
                            "valuesPriorityOrder": [
                                "A0",
                                "A1",
                                "A2",
                                "A3",
                                "A4",
                                "A5",
                                "A6",
                                "A7",
                                "A8",
                                "A9",
                                "A10",
                                "A11",
                                "A12",
                                ......
                                "C97",
                                "C98",
                                "C99"
                            ],
                            "fallbackStrategies": [
                                {
                                    "attribute": "configuration/entityTypes/Person/attributes/DepNoStatusKey",
                                    "survivorshipStrategy": "LUD"
                                }
                            ],
                            "fallbackUsingCriteria": "MORE_THAN_ONE",
                            "survivorshipStrategy": "ValueBasedPriority"
                        },

Results After Implementation

Outcome:

• Consistent attribute values between Reltio and DBX.

• OV values always sourced from the active, correct contract.

• No reprocessing or manual corrections required