May 23, 2023 / August 12, 2024 by Lyubomira Alexandrova

resolveLookupCode physical configuration setting

Definition

The resolveLookupCode parameter is a physical configuration setting that determines which value for lookup attributes will be stored in Reltio’s backend database.

Behavior

Depending on the value of the resolveLookupCode setting we observe different behavior. There are two possible values that this setting can accept:

false
- This is the default option
- The value that is stored in Reltio’s backend database is the “raw” input value that has been submitted
- In the API response, the customer will see an attribute property lookupRawValue in the RDM attribute properties which will hold the value which was originally pushed to Reltio in the lookup attribute
true
- The value that is stored in Reltio’s backend database is the lookup code
- In the API response, the customer will see an attribute property lookupValue in the RDM attribute properties which will hold the lookupCode of the RDM record the originally pushed to Reltio value in the lookup attribute resolved to

The resolveLookupCode setting can be configured at the tenant and at the attribute levels. The attribute level overrides the tenant level, so if configured for a certain attribute, it will override the tenant level configuration for this attribute. If it is not defined at the attribute level, then the tenant level is considered.

The resolveLookupCode parameter also has impact when calculating:

matchFieldURIs
matchRules
keyFieldUris
simple duplicated attributes

Examples

Let’s look at the following examples which show the impact of the resolveLookupCode setting in the matchFieldURIs behavior and how Reltio calculates matches for nested attributes.

Example Configuration

Nested Attribute Configuration

Expand to see the nested attribute in L3 configuration

{
                "label": "Color",
                "name": "Color",
                "dataLabelPattern": "{Color}",
                "type": "Nested",
                "hidden": false,
                "important": false,
                "system": false,
                "required": false,
                "faceted": false,
                "searchable": false,
                "uri": "configuration/entityTypes/Individual/attributes/Color",
                "matchFieldURIs": [
                    "configuration/entityTypes/Individual/attributes/Color/attributes/Color"
                ],
                "attributes": [
                    {
                        "label": "Color",
                        "name": "Color",
                        "description": "",
                        "type": "String",
                        "hidden": false,
                        "important": false,
                        "system": false,
                        "uri": "configuration/entityTypes/Individual/attributes/Color/attributes/Color",
                        "lookupCode": "rdm/lookupTypes/COLOR",
                        "skipInDataAccess": false
                    },
                    {
                        "label": "Brightness",
                        "name": "Brightness",
                        "description": "",
                        "type": "String",
                        "hidden": false,
                        "important": false,
                        "system": false,
                        "uri": "configuration/entityTypes/Individual/attributes/Color/attributes/Brightness",
                        "skipInDataAccess": false
                    }
                ],
                "skipInDataAccess": false
            }

RDM configuration

Canonical Column	BFO	SAP	Salesforce
Canonical value: GreenCanonical code: 2	Source value: GreenSource code: 2	Source value: GrSource code: 95Source value: Green_ColorSource code: GR_C	Source value: GrSource code: 96Source value: Green_CSource code: GR_C

L3 Physical Config

resolveLookupCode = false

Scenario 1

	Raw Input 1	Raw Input 2
Source	SAP	Salesforce
Color attribute value	95	96
Brightness attribute value	light	dark

Scenario 2

	Raw Input 1	Raw Input 2
Source	SAP	Salesforce
Color attribute value	GR_C	GR_C
Brightness attribute value	light	dark

In Scenario 1 two different values 95 an 96 for the Color attribute are pushed by the SAP and Salesforce crosswalks and event though both values map to the same RDM Canonical Code, they appear separately in the Reltio UI and in the entity payload API response.

In Scenario 2 two identical values GR_C for the Color attribute are pushed by the SAP and Salesforce crosswalks. Both values map to the same RDM Canonical Code and they appear merged in the Reltio UI and in the entity payload API response.

These two scenarios show us that when resolveLookupCode is set to false, then lookupRawValue is considered by Reltio when it determines whether two instances of a nested attribute are the same or not.

When resolveLookupCode is set to false the original value submitted by the crosswalk is retained in rawLookupValue and can be seen via the Reltio API if needed.

L3 Physical Config

resolveLookupCode = true

Scenario 1

	Input 1	Input 2
Source	SAP	Salesforce
Color attribute value	95	96
Brightness attribute value	light	dark

Scenario 2

	Input 1	Input 2
Source	SAP	Salesforce
Color attribute value	GR_C	GR_C
Brightness attribute value	light	dark

In Scenario 1 two different values 95 and 96 for the Color attribute are pushed by the SAP and Salesforce crosswalks. Both values mapped to the same Canonical Code and they appear merged in Reltio UI and in the entity payload API response.

These two scenarios show us that when resolveLookupCode is set to true, then lookupCode is considered by Reltio when it determines whether two instances of a nested attribute are the same or not.

However, when resolveLookupCode is set to true the original value submitted to Reltio is lost and cannot be retrieved. For example we would not know if the Salesforce crosswalk submitted 96 or GR_C or Green.

Transitioning

If you update the resolveLookupCode setting from false to true a few changes will be observed:

lookupValue will correspond to lookupCode in the API response
The value for lookupValue stored in Reltio’s backend database will change only if:
- An update of any entity’s attribute is performed – it can be a partial override, cumulative update, or full update and it can update the RDM attribute or not
- An update of any entity’s crosswalk attribute is performed (for example “updateDate” property)
- An update of the start or end date attributes of the whole Reltio entity

If you revert back the resolveLookupCode’s value back from true to false the rawLookupValue will not be recovered automatically. You will have to reload all your profile data again, otherwise, the change will be applied only to newly loaded profiles. Any profiles which merged while the setting value was set to false but should not merge when the value is set to true that existed up until this moment will remain merged. Reindex data task won’t help in this situation either because when resolveLookupCode = true, the raw source values aren’t kept by Reltio.

resolveLookupStrategy parameter

The resolveLookupStrategy parameter is applied when calculating match tokens for the entities. The way it works is that it either resolves a lookup before a token is generated or uses the raw value of the attribute. In most user scenarios the resolveLookupStrategy parameter has values of either LOOKUP_CODE or LOOKUP_VALUE. It can accept 3 possible values:

NONE
- Lookup types will not be resolved for matching
- Raw attribute values will be applied
LOOKUP_CODE
- Lookup types will be resolved
- Lookup code will be considered for matching instead of the raw value of the attribute
LOOKUP_VALUE
- Lookup types will be resolved
- Lookup value will be considered for matching instead of the raw value of the attribute
- The resolveLookupStrategy parameter uses LOOKUP_VALUE by default for backward compatibility