Reltio Connect

I want to take this opportunity to inform everyone of a feature in the Reltio API which I and many others feel is extremely important for anyone loading data from sources and managing survivorship. It blends the features of Delta Detection (aka Change Data Capture) and the Recency survivorship Rule to form a powerful yet simple approach to loading data into Reltio.

First, let me provide some background as context for this exciting capability. The Recency rule is intrinsically a more complex rule than the other survivorship rules. It embraces three physical timestamps in determining which value held within the attribute will become the OV (Operational Value) of the attribute. The physical timestamps are:

• Crosswalk.updateDate
• Crosswalk.publishDate
• {attribute value}.SingleAttributeUpdateDate

When the rule is triggered which occurs anytime the entity is accessed, Recency will calculate for each value in the attribute, an “Effective Timestamp” equal to the max value (i.e. the most recent) of the three physical timestamps. Having calculated the Effective Timestamp for each value, it then sets the OV of the attribute to the value with the max Effective Timestamp. 

Now for our discussion today, let’s ignore the crosswalk.publishDate since it is rarely utilized in practice.  And let’s recall that PartialOverride is the option in a POST that sets the SingleAttributeUpdateDate for a value in an attribute and allows the value to have a tightly bound physical timestamp greater than the crosswalk level, crosswalk.updateDate. 

Typically there are two POSTing scenarios most often implemented in practice. In Scenario1 below, PartialOverride is not used so all attributes that use Recency will rely solely on the one crosswalk.updateDate. 

Scenario 1: PartialOverride not utilized

Consider a source record with an LUD column and 20 attributes we care about. In this scenario, a simple integration POSTs all 20 attributes to the crosswalk and sets the crosswalk.updateDate to the LUD. And we replicate this integration for each source. Since PartialOverride is not being used, then in a very coarse manner, the source record with the most recent LUD becomes the OV for all 20 attributes. This baseline but often used approach has limited appeal in my opinion as illustrated in the following example. Consider a Salesforce Contact record that has been idle in Salesforce for 6 months. The user decides that the first name should really be Jacqueline instead of Jackie and updates it accordingly. Did the user also review the other 19 attributes for their current accuracy? Very unlikely. So upon pressing Save, the LUD is updated, and the integration transfers all 20 values to the Salesforce crosswalk and they become the OV taking the place of any other values that might genuinely be more recent from another source. So the OV quality of one attribute improved while the other 19 attributes have possibly gotten worse. How do we surgically update just one attribute while protecting the others? That takes us to the use of PartialOverride described in Scenario 2.

Scenario 2:  PartialOverride is utilized.

You might say that the previous scenario exhibits “crosswalk level recency”. But as a frequent implementer of MDM, I don’t want the survivorship for all my crosswalk attributes to be driven by a single crosswalk update Date. What I really want from Recency is attribute-level Recency. (Consider that all the other survivorship rules intrinsically operate at the attribute level.) To provide attribute-level control for Recency, you can add the PartialOverride parameter to the POST. This addition allows you to POST a subset of the attributes represented in the crosswalk and has the effect of setting the SingleAttributeUpdateDate on just those while leaving the values held in the other attributes of the crosswalk undisturbed. This empowers the values explicitly named in the POST to become the OV while the OV within other attributes continue to remain as they were, perhaps from a blend of other sources.  

The trouble with Scenario 2 is that while it resolves the coarseness problem of Scenario 1, it entails too much time and cost to implement because the developer has to: 

1. Create a Delta Detection mechanism for each source which stores the previous POST, compares it to the new POST and figures out which attributes have truly changed, then 
2. Form a JSON that includes only those changed attributes 
3. POST the custom JSON using PartialOverride. 

I’m exhausted just thinking about it.  

Not anymore! Now you can have the benefits of both scenarios with literally no effort. It is fundamentally based on a little-known parameter available within the physical configuration of the tenant. It is called AttributeUpdateDatesOnActualChanges. File a support ticket and ask for it to be set to True. 

Then, when POSTing the source record, include the following two options updateAttributeUpdateDates and PartialOverride in the request url. Be sure to exclude (yes exclude) the crosswalk.updateDate from the crosswalk section of the JSON body. Lastly, include in the request ALL of the attributes contained within the current crosswalk. If you meet these conditions, the API will do the following for you during the POST:

1. It will perform delta detection and determine which attribute values in your source record are different from those presently in the crosswalk.
2. It will update the crosswalk with only those that have changed, leaving the others as is. 
3. It will set the SingleAttributeUpdateDate timestamp for the changed values, to the current timestamp. (Yes, the current timestamp)

This is huge. It means that if you wish to use Recency on a range of attributes and enjoy attribute-level behavior, you can now just build a simple integration that POSTs all the attributes of interest from that source each time the source LUD is updated without worrying about which of the attribute values actually changed. The Reltio API will figure it out for you. It will update only the changed values and set their SingleAttributeUpdateDate timestamp for you. As regards #3, do I wish it would use the LUD of the source for the timestamp on the SingleAttributeUpdateDate of each value? Ideally yes, but the API in its current form doesn’t support that and in fact, in order to achieve the behavior described the API explicitly requires the crosswalk.updateDate date to be absent from the POST. If you include it you will not get the behavior described above. But the fact that the API will leverage the current timestamp is pretty good given the overall value proposition of this approach.

Again, a huge concept for anyone building integrations to Reltio! 

Hope you agree