Remember that the platform considers three date values when calculating the OV.

They are:

• The crosswalks "createDate" (also called the Source Publish Date)
• The crosswalks "singleAttributeUpdateDates"
• The crosswalks "updateDate"

The "Single Attribute Update Date" isn't visible in the UI. It can be found via API when you do a get entity by entity ID API call. You'll find it under the crosswalk section of the response it's called "singleAttributeUpdateDates."

For more information on the behavior of updating attributes "updateDate" and "singleAttributeUpdateDates" with the option partialOverride, scroll down to "Understanding Attribute Update Behavior with 'updateDate' and Configuration Flags."

Recency (Last Update Date, also known as LUD) Rule

This rule selects the value within the attribute that was posted most recently. You might think that the rule need only compare the LastUpdateDate of the crosswalks that contribute to the attribute to find the most recently updated crosswalk, then use the value that comes from that crosswalk as the Operational Value (OV). But the real process is a bit more complex. There are three timestamps associated with an attribute value that play a role in determining the effective LastUpdateDate for the attribute value. They are:

• Crosswalk Update Date - this is updated at the crosswalk level and reflects the best information about when the source record was most recently updated.
• Crosswalk Source Publish Date - this is also updated at the crosswalk level but entirely under your control. It is an optional field you can write, to capture the business publish date of the data. E.g suppose you receive a quarterly data file. You might post the value of 3/31/2020 into this field.
• Single Attribute Update Date - This is an internally managed timestamp associated with an actual value in the attribute’s array of values. It is updated separately from the crosswalk.updateDate if the value experiences a partial override operation in which case it will be more recent than the crosswalk.

The Recency rule calculates the effective timestamp of an attribute value to be the most recent of the three values discussed above: sourcePublishDate, SingleAttrUpdateDates, LastUpdateDate. Once it calculates that for each value in the attribute, it returns the most recent attribute value(s) as the OV of the attribute.

Here are some helpful links to our doc pages:

• Survivorship Rule Types: https://docs.reltio.com/en/model/consolidate-data/design-survivorship-rules/survivorship-rule-types 
• Managing Crosswalk Dates: https://docs.reltio.com/en/model/construct-your-data-model/define-or-refine-your-data-model/define-crosswalks-for-data-sources/managing-crosswalk-dates

Understanding Attribute Update Behavior with 'updateDate' and Configuration Flags

Scenario 1: Summary of Logic for Handling "updateDate" and "singleAttributeUpdateDates"

When processing a request with "updateDate" and the flag "updateAttributeUpdateDatesOnActualChanges" (true or false), and depending on the "options" values ("partialOverride" or "partialOverride,updateAttributeUpdateDates"):

1. No changes to attributes in the request

   • Response:
     • updateDate: Unchanged.
     • singleAttributeUpdateDates: Unchanged.

2. Some attributes unchanged, others not present in the request

   • Options = "partialOverride"
     • Response:
       • updateDate: Unchanged.
       • singleAttributeUpdateDates: Unchanged.
   • Options = "partialOverride,updateAttributeUpdateDates"
     • If request updateDate < existing updateDate:
       • Response:
         • updateDate: Unchanged.
         • singleAttributeUpdateDates: Unchanged.
     • If request updateDate >= existing updateDate:
       • Response:
         • updateDate: Unchanged.
         • singleAttributeUpdateDates: Updated for attributes in the request, unchanged for others.

3. All attributes present in the request, with some or all changed

   • Response:
     • updateDate: Matches updateDate from the request.
     • singleAttributeUpdateDates:
       • Empty for changed attributes.
       • Unchanged for other attributes where singleAttributeUpdateDates < request updateDate.

4. Not all attributes present in the request, with some or all changed

   • Response:
     • updateDate: Unchanged.
     • singleAttributeUpdateDates:
       • For changed attributes:
         • Matches request updateDate if it >= existing updateDate.
         • Empty if request updateDate < existing updateDate.
       • Unchanged for other attributes.

Scenario 2: Summary of Logic for Handling "updateDate" When Absent

When "updateDate" is not present and the flag "updateAttributeUpdateDatesOnActualChanges" is either true or false, with options set to "partialOverride" or "partialOverride,updateAttributeUpdateDates":

1. No changes to attributes, or some unchanged while others are not present in the request

   • Response:
     • updateDate: Unchanged.
     • singleAttributeUpdateDates: Unchanged.

2. Some or all attributes in the request have changes

   • Options = "partialOverride"
     • Response:
       • updateDate: Unchanged.
       • singleAttributeUpdateDates:
         • Empty for changed attributes.
         • Unchanged for others.
   • Options = "partialOverride,updateAttributeUpdateDates"
     • If updateAttributeUpdateDatesOnActualChanges is false:
       • Response:
         • updateDate: Unchanged.
         • singleAttributeUpdateDates: Current date for all attributes in the request.
     • If updateAttributeUpdateDatesOnActualChanges is true:
       • Response:
         • updateDate: Unchanged.
         • singleAttributeUpdateDates: Current date for changed attributes, unchanged for others.

3. Some attributes changed, and others not present in the request

   • Response:
     • updateDate: Unchanged.
     • singleAttributeUpdateDates:
       • Current date for attributes in the request.
       • Unchanged for others.