Question
We have a filtered survivorship rule in our tenant for many attributes. This survivorship rule is working correctly for other attributes but now it's not working perfectly for Degree and Specialty attributes. Previous it was working fine for these attributes as well but today we are facing this issue.
Survivorship rule: For Degree & Specialty only verified degree and Specialty value should be survived and aggregated. For now, we can see unverified values as well survived.
Answer
Survivorship not working for the Title attribute (Multiple title values becoming OV)
For entity 1Jil63RE, there are two values for the title attribute that are not the same lookup value at all:
Based on source system survivorship there should only be one OV but both are true:
"Title": [
{
"type": "configuration/entityTypes/Contact/attributes/Title",
"ov": true,
"value": "Miss",
"lookupCode": "Miss.",
"lookupRawValue": "MISS.",
"uri": "entities/1Jil63RE/attributes/Title/4RQ61Yyb4"
},
{
"type": "configuration/entityTypes/Contact/attributes/Title",
"ov": true,
"value": "Mr.",
"lookupCode": "Mr.",
"lookupRawValue": "MR.",
"uri": "entities/1Jil63RE/attributes/Title/3LX1Sti3I"
}
],
If you look at your physical storage configuration, you are using Advanced Survivorship strategies (see https://docs.reltio.com/en/model/consolidate-data/design-survivorship-rules/advanced-survivorship-strategies)
"survivorshipAdvancedBehavior": [
"LUD",
"OldestValue",
"SRC_SYS"
],
If you look at the survivorship definition for configuration/entityTypes/Contact/attributes/Title, you will see:
{
"attribute": "configuration/entityTypes/Contact/attributes/Title",
"sourcesUriOrder": [
"configuration/sources/Reltio",
"configuration/sources/AllerganAdvantage",
"configuration/sources/Medforce",
"configuration/sources/MOXIE",
"configuration/sources/MDM",
"configuration/sources/BSMConsulting",
"configuration/sources/SamplingInfo",
"configuration/sources/AllerganDirect",
"configuration/sources/VolbellaBrandTraining",
"configuration/sources/ALLEProvider",
"configuration/sources/Spark",
"configuration/sources/OnboardingPortal",
"configuration/sources/CaseMgmtAustin",
"configuration/sources/NICE"
],
"fallbackStrategies": [
{
"attribute": "configuration/entityTypes/Contact/attributes/Title",
"survivorshipStrategy": "LUD"
}
],
"fallbackUsingCriteria": "MORE_THAN_ONE",
"survivorshipStrategy": "SRC_SYS"
},
If we look at the contents of 1Jil63RE for Mr and Miss, you see that the source is the same source of AllerganAdvantage. Next we will look at your fallback strategies (which will initiate because SRC_SYS are tied), you will notice the update date is the SAME. Your fallbackUsingCriteria is defined MORE_THAN_ONE.
Based on the survivorship selection that you have made, it is expected to have two OV values for title. Please take a moment to review the documentation in https://docs.reltio.com/en/model/consolidate-data/design-survivorship-rules/survivorship-rules to determine what is the best combination of survivorshp and fallback survivorshp (including what would be the best selection when the fallbackStrategies are a tie.
"uri": "entities/1Jil63RE/crosswalks/3LX1SVa0i",
"type": "configuration/sources/AllerganAdvantage",
"value": "AA_0054P00000AgarAQAR",
"reltioLoadDate": "2022-11-20T18:40:05.368Z",
"createDate": "2022-11-20T18:40:05.368Z",
"updateDate": "2022-11-20T18:40:05.368Z",
"attributes": [
"entities/1Jil63RE/attributes/Title/4RQ61Yyb4",
"type": "configuration/sources/AllerganAdvantage",
"value": "AA_0054P00000Agb4AQAR",
"reltioLoadDate": "2022-11-20T18:40:05.368Z",
"createDate": "2022-11-20T18:40:05.368Z",
"updateDate": "2022-11-20T18:40:05.368Z",
"attributes": [
"entities/1Jil63RE/attributes/Identifiers/3LX1Stuq4",
"entities/1Jil63RE/attributes/Role/3LX1SsKo8",
"entities/1Jil63RE/attributes/Title/3LX1Sti3I",
Invalid license values becoming OV
For entity 146Xf6bI, we can see where the Validation Status is "Invalid" and based on your rules you shouldn't get OVs with that invalid status.
In this case here is that the customer passing "INVALID" and "VALID" as lookupRawValues.
"ValidationStatus": [
{
"type": "configuration/entityTypes/Contact/attributes/License/attributes/ValidationStatus",
"ov": true,
"value": "Invalid",
"lookupCode": "Invalid",
"lookupRawValue": "INVALID",
"uri": "entities/146Xf6bI/attributes/License/3ralfiUVo/ValidationStatus/3ralfiYm4"
}
]
Hence we store them in the database, hence we compare them with
{
"uri": "configuration/entityTypes/Contact/attributes/License/attributes/ValidationStatus",
"value": "Valid"
}{
"uri": "configuration/entityTypes/Contact/attributes/License/attributes/ValidationStatus",
"value": "Invalid"
}
When creating an entity with a lookup attribute, it is possible to specify either a lookup code or a lookup value.
In case of specifying the lookup code/value for the attribute in the “filter” section of survivorship group, behavior of filtering depends onresolveLookupCodeparameter of the physical configuration.
- resolveLookupCode = true.Means that lookupcode is stored in C*, no matter lookup code or lookup value was specified in the entity POST request, in case Platform can resolve POSTed value to lookup code.
In that case the value of the attribute from the survivorship group is looked up among values of the current attribute in the entity, and referring to the clarification about storing attributes in C* above,survivorship group should contain lookup code for correct filtering.
- resolveLookupCode = false. The“raw” valueof the lookup attribute (which was specified in the entity POST request) is recorded to C*. This is your current setting.
Filter in the survivorship group will be working correctly only in case when either only lookup codes or only lookup values are used in both the survivorship group and the entity.
Setting resolveLookupCode=true and filtering by lookup code in survivorship group is the best practice.
For more information, please refer to
https://docs.reltio.com/en/explore/get-going-with-apis-and-rocs-utilities/reltio-rest-apis/model-apis/lookups-api/resolve-attribute-or-tenant-lookups
Preferred Names with multiple OVs
For entity 1JiGBdLA, this has a recency rule for "Preferred Name" but there are two winning values when the "Tina" value is older:
If we look at your survivorship rule, we see the following. As you can see there is no "true" fallbackUsingCriteria. Both are considered LUD.
{
"attribute": "configuration/entityTypes/Contact/attributes/PreferredName",
"fallbackStrategies": [
{
"attribute": "configuration/entityTypes/Contact/attributes/PreferredName",
"survivorshipStrategy": "LUD"
}
],
"fallbackUsingCriteria": "MORE_THAN_ONE",
"survivorshipStrategy": "LUD"
},
Now let's look at the OV true definition for preferred name.
"PreferredName": [
{
"type": "configuration/entityTypes/Contact/attributes/PreferredName",
"ov": true,
"value": "Tina Befor",
"uri": "entities/1JiGBdLA/attributes/PreferredName/3u1gfztly"
},
{
"type": "configuration/entityTypes/Contact/attributes/PreferredName",
"ov": true,
"value": "Chris Befor",
"uri": "entities/1JiGBdLA/attributes/PreferredName/2CYmwzJfh"
},
If we look at the LUD for the crosswalk in the 1JiGBdLA entity, we see the following. As you can see both of these preferred values have the SAME last update date and neither of them have a singleAttributeUpdateDate, As you can see in the documentation, the survivorship is behaving as expected.
{
"uri": "entities/1JiGBdLA/crosswalks/1qbK57foW",
"type": "configuration/sources/MOXIE",
"value": "MOXIE_0033h000011i14UAAQ",
"reltioLoadDate": "2022-11-20T19:16:45.401Z",
"createDate": "2022-11-20T19:16:45.401Z",
"updateDate": "2022-11-20T19:16:45.401Z",
"attributes": [
"entities/1JiGBdLA/attributes/FullName/3u1gfzpVi", <<====
"entities/1JiGBdLA/attributes/Identifiers/2CYmx6jzZ/Type/2CYmx6sW5",
"entities/1JiGBdLA/attributes/PreferredName/3u1gfztly",
{
"uri": "entities/1JiGBdLA/crosswalks/1qbK4wwuG",
"type": "configuration/sources/MOXIE",
"value": "MOXIE_0033h000011i14eAAA",
"reltioLoadDate": "2022-11-20T19:16:45.401Z",
"createDate": "2022-11-20T19:16:45.401Z",
"updateDate": "2022-11-20T19:16:45.401Z",
"attributes": [
"entities/1JiGBdLA/attributes/EntityType/3LWK9tmIm",
"entities/1JiGBdLA/attributes/Identifiers/2CYmwzNvx/Value/2CYmwzaij",
"entities/1JiGBdLA/attributes/Role/2CYmwyyMP",
"entities/1JiGBdLA/attributes/AffiliationIDs/3LWK9tECi/VerificationStatus/3LWK9tISy",
"entities/1JiGBdLA/attributes/Email/2CYmwyd37",
LUD
If some values have many crosswalks with the same most recent date, then all of those crosswalks become winners, and all values with those crosswalks become winners as well.
Comments
Please sign in to leave a comment.