Unify and manage your data

Advanced Survivorship Strategies

Learn about the advanced survivorship strategies in the Reltio platform.

You can use the OtherAtrributeWinner crosswalk and advanced strategies behavior for calculating the Operational Value.

OtherAttributeWinnerCrosswalk Strategy's Special Behavior

This strategy requires that you use the primaryAttributeUri attribute, as it gets all winner crosswalks from this primary attribute. If the current value has any crosswalks that are the primary attribute's winner crosswalks, then all of these crosswalks and all values provided by them become winners.

Every separate survivorship rule produces winner values and winner crosswalks as a result of the calculation. Winner crosswalks from the Operational Value (OV) calculation's result can be used only in OtherAttributeWinnerCrosswalk for another attribute. The current attribute depends on the primary attribute, and the primary attribute OV is calculated before the current one.

  • If the primary attribute does not have winner crosswalks, then the dependent attribute also does not have winner OV.
  • It is possible to have a primary attribute that also includes survivorship mapping in OtherAttributeWinnerCrosswalk. There is only a requirement to not create cyclic dependencies: the attribute cannot depend on itself directly (using the current attribute as primaryAttributeUri) or indirectly (through a chain of other attributes by primaryAttributeUri).
Restrictions for primaryAttributeUri
primaryAttributeUri can be on the same level as a dependent (current) attribute or on a higher level:
  • primaryAttributeUri=AddressLine1, current attribute=Zip/Zip5;
  • primaryAttributeUri=Zip, current attribute=Zip/Zip5;
  • primaryAttributeUri=Zip/Zip4, current attribute=Zip/Zip5;

Otherwise, the strategy works in an unpredictable manner.

If the restriction is violated, the attribute's values OV status is still calculated, with the following possible options:
  • primaryAttributeUri is on a lower level of the attributes hierarchy than the current one (the current attribute is a direct or indirect parent of primaryAttributeUri). For example, the Zip attribute depends on the Zip/Zip5 attributes. In this case, the current attribute has, by design, all crosswalks of all its children, and it automatically wins if some primaryAttributeUri values have OV=true. If there are no values of attribute primaryAttributeUri or no winner values, the current value will have OV=false. Each current value checks only its sub-hierarchy. All winner values of the current attribute are combined, and all winner crosswalks of primaryAttributeUri values are also combined.
  • primaryAttributeUri is a sub-nested attribute in a neighbour hierarchy. For example, the FirstName attribute depends on Zip/Zip5. In this case, the winner crosswalks of Zip/Zip5 are taken as all winner crosswalks of each winner Zip5 value which has all parents also being winners.

Sub-nested Values Hierarchical Operational Value Status

Any sub-nested value's OV status is calculated regardless if its parent is or is not a winner. Therefore, if any parent in the sub-nested attribute's hierarchy is OV=false, the sub-nested value still can be OV=true. This sub-nested OV status is NOT REFLECTED in the response, meaning, if any value is OV=false, then all its children are OV=false, but only in the response. Internally, in the model, it has its own OV status, which cannot match the response's status.

Based on the design, performance behavior is as follows:
  • Pinned value: survivorship rules are not applied to attribute values if one of those values is pinned. All pinned values become OVs, and all of the attribute’s survivorship rules are ignored. The restriction is if the sub-nested attribute is pinned but its parent has OV=false, this sub-nested attribute also will be OV=false. This sub-nested value has OV=false ONLY in the response. Internally, in the model, the value is OV=true.
  • Nested Label value: calculated by the sub-nested OV values specified in the Label template. If the nested value is OV=false, its sub-nested value still can be OV=true. Internally, the Label value is calculated by the internal OV status, which is an indirect way to discover the internal OV status of the sub-nested attribute value.

Advanced Strategies Behavior

You can set a special option, survivorshipsAdvancedBehavior, in the tenant's physical configuration:

"survivorshipAdvancedBehavior": [
        "LUD",
        "OldestValue",
        "SRC_SYS",
        "MyOwnRecordBase1",
        "MyOwnRecordBase2"
      ]

This option is an array and can contain only strings as items. The strings are short names of survivorship strategies described in the tenant's business configuration in the survivorshipStrategies section.

Note: LUD, OldestValue, and SRC_SYS have constant short names (they canot be redefined), but RecodBase has its own name in the survivorshipStrategies configuration section. It is possible to have more than one RecodBase type in the strategies; for example, MyOwnRecodBase1, MyOwnRecodBase2, and so on.
Only four strategies have possible advanced behavior. The differences between the strategies' behavior are as follows:
  • LUD
    • If some values have the same most recent crosswalk, but one (or many) of them has more recent singleAttributeUpdateDate, then this value becomes only a winner; however, the winner crosswalk remains the same.
    • 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.
  • OldestValue - If some values have many crosswalks with the same oldest create date,then all of those crosswalks become winners, and all values with those crosswalks become winners as well.
  • SRC_SYS
    Note: The following points apply only when the advanced behavior feature is disabled or internal fallbacks are triggering. When advanced behavior is enabled, fallback mechanisms such as single-value logic or relying on Cassandra update time are not used.
    • If an attribute does not have values from sources in the priority list, then the priority of sources is taken from the source types configuration of the business model.
    • If the business model does not specify source priorities and the priority list is also absent, no values are survived (all values have ov=false).
    • If the strategy is applied to one value only, this value and its crosswalk become the winner, regardless of whether or not this crosswalk has a source from the priority list.
    • If there are no values with crosswalks from the priority list, the winner value is the value with the most recent Cassandra update time. All crosswalks of this value become winner crosswalks.
  • RecordBase - If there is any value from the attributes considered that has a crosswalk with winner source type, then only crosswalks with this source type become winners, and their values become OV. If this condition is not met, then the LUD strategy is applied instead.
    Note: This point is not relevant if the advanced behavior feature is enabled and there are no internal fallbacks triggering.