Good question.
I think you're asking for a fallback. My example, earlier in the webinar, when we had two choices that win and we only want one winner and that is something I can go ahead and jump to. It's conveniently my next slide. When you have, for example, first name, you had a duplicate Twitter record. Twitter's our highest source system priority here in source system as our survivorship strategy. There are two records representing the same individual. They both provide a first name. Well source system if there's two Twitter records, how does it choose which first name to use if they're both Twitter, there's a tie?
That's where fallback strategies come in. And it's an array within the survivorship rule. And this is only configurable from the JSON with Postman. Unfortunately, you can't do this with the UI but what we see here is we've provided to fallback strategies. If there's a tie on first name, we're going to take the minimum value, which seems arbitrary to me but that's what this example chose. And if there's still a tie, so potentially there's the same source system and they have the same name provided but we don't want to see Joel twice. We just want to see Joel once. We would switch to last updated date. And one of these Twitter records is likely more recently updated than the other and that one will win. This would be a good example of a compound rule or what we call an Reltio a fallback strategy.
How you fall back is also important. If you have more than one winner, that's the default. It's going to jump to a fallback strategy. If you have zero winners, it will just show zero winners. If you have a source system list but your only record that provides first name is not in that list, you'll have zero winners and you will not have a first name get through. If you want to make sure that's populated, you might consider turning fallback using criteria on and doing zero more than one. If there's no winners here, then we'll fall back anyway. Whereas the default behavior is we only use fallback if there's more than one. And I can show you in our address example, this is set up. If no address is in this list of source systems between the Reltio Cleanser and Reltio, we'll go to the last updated date, and we have fallback using criteria zero more than one. If more than one address wins or if no address wins, we're going to go to the most recent address rather than the source system list. Hopefully that answers your question.
------------------------------
Joel Snipes
------------------------------
Original Message:
Sent: 09-14-2021 10:10
From: Sandro Palleschi
Subject: When changing Source Order is that updating config for this attribute or is it changing the order for this profile only?
@Joel Snipes, thanks for the answer. Also, how do you define a compound rule type? Can you talk a little bit about that?
------------------------------
Sandro Palleschi
Manager - Enterprise Data Services at Empire Life
Empire Life
Original Message:
Sent: 09-14-2021 10:09
From: Joel Snipes
Subject: When changing Source Order is that updating config for this attribute or is it changing the order for this profile only?
@Sandro Palleschi,
Thanks for the question.
On the top level, when we're looking at addresses, we're not inside the nest yet, we're at the top level, almost every nested attribute you're going to want to have set to aggregation. There are examples, I've seen very specific examples where you don't, but as a rule of thumb, aggregation is the way you want to go about it. The lower-level attributes are kind of data dependent. For example, with address line one, we're using the source system with the Reltio Cleanser. In this example, our customer wants the cleanser data as a top priority but if the cleanser was unable to find a cleansed version of the address, the uncleansed version will still come through. We could have made this Reltio Cleanser nothing and then only cleansed values will come through. But that differs from the example I was just showing where for identifiers, we want the minimum ID and I can even think of another example here.
The tool we're using to generate our identifier goes from being an incremental number to a hash. Now the minimum value of a hash is meaningless, and this rules no longer hold up. The future strategy might move to the oldest value, and this will drive and pick the UUID based on create date. You still only get one winner, but it'll always be the oldest crosswalk, ensuring that the ID never changes. The only fast rule with nested attributes is you're probably going to want aggregation at the top level. Inside the nested attribute it's going to be data dependent.
Take a look at the#Survivorship webinar I hosted:
------------------------------
Joel Snipes
Original Message:
Sent: 09-14-2021 10:05
From: Sandro Palleschi
Subject: When changing Source Order is that updating config for this attribute or is it changing the order for this profile only?
This question is around the #Survivorship webinar that @Joel Snipes did a few weeks back.
------------------------------
Sandro Palleschi
Manager - Enterprise Data Services at Empire Life
Empire Life
------------------------------