Hub/NUI Displays Stale RDM Lookup Values After RDM Updates

Gloria

Updated June 03, 2026 22:47

Overview

This article documents the investigation, root cause, and resolution of an issue in which the Hub/NUI displayed outdated AddressType lookup values after updates were made in RDM.

We should consider the following possible problems.

RDM looks correct, but Hub/NUI shows old values- The lookup values were updated in RDM, but the UI still displays outdated dropdown options.
MDM may have stale local lookup values -MDM can retain its own local lookup values separate from RDM.
The UI may be using a merged lookup response-Hub/NUI may call lookups?source=ALL, which merges values from both RDM and MDM.
Old MDM values can appear alongside current RDM values. This causes dropdowns to show both valid current values and obsolete legacy values.
RDM cache reset may be needed - If stale values exist in MDM’s local lookup store, resetting the RDM cache may address the problem; however, clearing only the RDM cache may not fix the issue, depending on the source of the values.

Issue Description

The AddressType dropdown in Hub displayed values that did not match the current RDM configuration.

Expected Values (Current RDM Configuration)

Examples:

Billing Address
Business
Primary Residence
Secondary Residence
Mailing
Alternate Address
HIPAA Address
User Registration

Unexpected Values Displayed in Hub

Examples:

Billing
Primary
Secondary
Shipping
Delivery

The customer confirmed that these legacy values were no longer part of their current RDM configuration.

Step 1 - Verify Current RDM Configuration

Why

The first objective was to determine whether the incorrect values were actually present in RDM.
If RDM itself contained the legacy values, Hub would behave as expected.

Validation Performed

Reviewed the AddressTypes lookup directly in RDM UI.
Confirmed the lookup contained the expected current values:

Result

RDM contained the correct lookup values.
No obvious legacy values such as Billing, Primary, Secondary, Shipping, or Delivery were visible in the lookup definitions.

Conclusion: The issue was not immediately attributable to incorrect RDM configuration.

Step 2 - Validate Direct RDM API Response

Why

The RDM UI could potentially be displaying cached or transformed information.
We needed to validate the raw data being returned by the RDM service.

Validation Performed

Executed:

GET https://eprus-01-ssrv-rdm-api47.reltio.com/lookups/btwj3ezR8nslrgK/AddressTypes

Result

The API returned the expected current values and source mappings.

Examples:

{
  "code": "10005",
  "value": "Billing Address"
}

{
  "code": "3",
  "value": "Business"
}

{
  "code": "1",
  "value": "Primary Residence"
}

Conclusion

Confirmed that RDM itself was returning the correct values.
The issue was not caused by incorrect RDM data.

Step 3 - Verify MDM to RDM Connectivity

Why

If MDM was connected to an incorrect RDM tenant or service endpoint, it could retrieve outdated data.

Validation Performed

Executed:

GET /status/rdmStats

Result

Confirmed:

Status = OK
Correct RDM service configured
Correct RDM tenant configured
No connectivity failures
Successful RDM communication

Conclusion

The issue was not caused by RDM connectivity or incorrect tenant mapping.

Step 4 - Verify RDM Cache Health

Why

A stale cache is a common cause of lookup discrepancies.
We needed to determine whether MDM was serving outdated values from cache.

Validation Performed

Reviewed cache statistics:

GET /status/rdmStats

Executed:

POST /resetRDMCache

Result

Cache reset completed successfully.
Subsequent validation continued to show healthy RDM connectivity.
However, the issue remained.

Conclusion

The problem was not resolved by clearing the RDM cache alone.

Step 5 - Capture the Hub Lookup Request

Why

We needed to determine exactly which backend service Hub uses to populate the dropdown.

Validation Performed

Captured the network traffic while opening the AddressType dropdown.

Observed:

POST /nui/reltioAPI/api/{tenant}/lookups/list

Payload:

{
  "type": "rdm/lookupTypes/AddressTypes"
}

Result

The response contained:

Current values:

Billing Address
Business
Primary Residence
Secondary Residence

AND

Legacy values:

Billing
Primary
Secondary
Shipping
Delivery

Conclusion

Hub was displaying exactly what the backend lookup endpoint returned.

This ruled out:

Browser cache
Frontend rendering issues
UI-only defects

The problem existed in backend lookup generation.

Step 6 - Compare Lookup Sources

Why

At this point the key question became:
"Where are the legacy values coming from?"

Validation Performed

Executed:

Retrieve MDM lookup source:

GET {{api_uri}}/{{tenant}}/lookups?source=MDM

Retrieve RDM lookup source:

GET {{api_uri}}/{{tenant}}/lookups?source=RDM

Retrieve merged lookup source:

GET {{api_uri}}/{{tenant}}/lookups?source=ALL

Result

RDM Source

Returned:

Billing Address
Business
Primary Residence
Secondary Residence

and other current values.

MDM Source

Returned:

Billing
Primary
Secondary
Shipping
Delivery

and other legacy values.

ALL Source

Returned both lists merged together.

Conclusion

Root cause identified.
The stale values were not coming from RDM.
The stale values were being sourced from MDM's local lookup store.

Step 7a - Remediate the problem when the problem is stale on the MDM side

Gather the lookup value from the MDM

GET https://{{api-uri}}.reltio.com/reltio/api/{{tnenat}}/lookups

Find the specific lookup type. Remove the stale values. Using that updated list, update the MDM.

POST https://{{api-uri}}.reltio.com/reltio/api/{{tnenat}}/lookups

Example of Payload

{
       "rdm/lookupTypes/AddressTypes": {
           "10002": {
               "displayName": "Alternate Address"
           },
           "10003": {
               "displayName": "Authorized Representative"
           },
           "10005": {
               "displayName": "Billing Address"
           },
           "3": {
               "displayName": "Business"
           },
           "10004": {
               "displayName": "Case Residence"
           },
           "10001": {
               "displayName": "Confidential Communication"
           },
           "102": {
               "displayName": "HIPAA Address"
           },
           "4": {
               "displayName": "Mailing"
           },
           "2": {
               "displayName": "Other Residence"
           },
           "1": {
               "displayName": "Primary Residence"
           },
           "7": {
               "displayName": "Secondary Residence"
           },
           "5": {
               "displayName": "Summer Residence"
           },
           "6": {
               "displayName": "Temporary Residence"
           },
           "101": {
               "displayName": "User Registration"
           }
       }
}

Step 7b - Remediate the problem when the problem is stale on the RDM side

Delete stale lookup code

POST https://{{rdm_uri}}/lookups/rdm_tenant_name/_delete

{ "uris" : 
   [ "rdm_tenant_name/State/AR",
     "rdm_tenant_name/State/CA",
     "rdm_tenant_name/State/KA", 
 ... ] }

Root Cause

MDM maintains its own local lookup repository in addition to retrieving lookup values from RDM. When Hub/NUI requests lookup values, MDM executes:

GET {{api_uri}}/{{tenant}}/lookups?source=ALL

This causes MDM to merge:

Local MDM lookup values
RDM lookup values

Legacy lookup values remained stored locally in MDM after the RDM updates. As a result, users saw a combination of:

Current RDM values
Obsolete MDM values

in the same dropdown.

Contributing Factors

publishRDMErrors Disabled

Tenant configuration:

{
  "publishRDMErrors": false
}

Impact

MDM does not generate warnings when local lookup values differ from RDM values.
This reduced visibility into the discrepancy.

Transcode Cache

Tenant configuration:

{
  "cache": {
    "type": "TranscodeInMemory"
  }
}

Impact

Lookup values can remain cached for approximately 15 minutes.
Although not the root cause, caching can delay visibility of lookup updates.

Key Takeaway

When Hub/NUI displays lookup values that differ from RDM:

Verify the values in RDM.
Verify the direct RDM API response.
Validate MDM-RDM connectivity.
Clear the RDM cache.
Capture the Hub lookup response.
Compare:

GET {{api_uri}}/{{tenant}}/lookups?source=MDM

vs.

GET {{api_uri}}/{{tenant}}/lookups?source=RDM

A discrepancy between these responses indicates that stale values are being retained in the MDM local lookup store and merged into the final lookup response returned to Hub/NUI.

Overview

Issue Description

Expected Values (Current RDM Configuration)

Unexpected Values Displayed in Hub

Step 1 - Verify Current RDM Configuration

Why

Validation Performed

Result

Conclusion: The issue was not immediately attributable to incorrect RDM configuration.

Step 2 - Validate Direct RDM API Response

Why

Validation Performed

Result

Conclusion

Step 3 - Verify MDM to RDM Connectivity

Why

Validation Performed

Result

Conclusion

Step 4 - Verify RDM Cache Health

Why

Validation Performed

Result

Conclusion

Step 5 - Capture the Hub Lookup Request

Why

Validation Performed

Result

Conclusion

Step 6 - Compare Lookup Sources

Why

Validation Performed

Result

RDM Source

MDM Source

ALL Source

Conclusion

Step 7a - Remediate the problem when the problem is stale on the MDM side

Step 7b - Remediate the problem when the problem is stale on the RDM side

Root Cause

Contributing Factors

publishRDMErrors Disabled

Impact

Transcode Cache

Impact

Key Takeaway

Articles in this section