Survivorship Data Container Rules

On a matching algorithm, the following rules are available for promoting data container values to a golden record.

Data Container: Most Recent

Valid for strategies: merge or link

Specifies that the most recent data container instances and their attribute values are promoted to the golden records. The analysis is performed in the single context / workspace selected in the algorithm, and that data is promoted across all contexts / qualifiers.

Business Condition - The business condition is used on data containers to determine whether the source data container instance represents an update to one of the existing target data containers or whether a new instance should be created. If no Data Container Key is configured, the condition is mandatory. Click the ellipsis button () and select a business condition that is valid for the golden record object type.
- The condition must be a JavaScript rule that uses the 'Pairs of Attributes' bind to compare data container instances on source records with data container instances on golden records when survivorship rules are applied. For more information and an example of the bind, refer to the topic Pair of Attribute Values Bind in the Resource Materials online help documentation. Examples of this behavior can be found in the Data Containers Business Condition Example Behavior section below.

Note: There is no need to configure a business condition if the data container type being merged has a configured Data Container Key. For more information on data container keys, refer to the topic Data Container Keys in the System Setup documentation.

Data Container Type: Click the ellipsis button () and select the relevant data container type.
Last Edit Date Attribute - When no attribute is selected, the most recent date is the STEP object revision timestamp when the given element of the survivorship rule entered STEP.

Optionally, click the ellipsis button () and select the attribute that holds the value to be used as the last edit date when determining the most recent source record to promote to the golden record.
- When the selected attribute is valid for this object, timestamp is taken from the object.
- When the selected attribute is not valid for the object, the value is taken from the given element of the survivorship rule, for example, a data container object or a reference object.

Note: Survivorship rules consider Last Edit Date attributes on the entities before considering Last Edit Date on the attributes within a data container. Additionally, for multi-value data container types, the newest date from all data containers of the specified type is considered.

Survive incoming empty values - When selected, an imported empty value replaces an existing empty value in the data container. For example, the phone data container for a record has PhoneType value of 'Private Phone', PhoneNumber value of '555-8637', and the LastEditDatePhone value of '2021-06-21'. Importing the following XML:
```
<DataContainer>
  <Values>
    <Value AttributeID="PhoneType"></Value>
    <Value AttributeID="PhoneNumber">555-8637</Value>              
    <Value AttributeID="LastEditDatePhone">2021-11-13 15:00:00</Value>
  </Values>            
</DataContainer>
```
results in the following outcome based on the checkbox setting:
- Survive incoming empty values = checked, the phone data container PhoneType attribute is updated to blank (the empty value survives) and the LastEditDatePhone attribute value is updated to 2021-11-13 15:00:00.
- Survive incoming empty values = not checked, the phone data container PhoneType attribute is not updated (the previous value 'Private Phone' remains) but the LastEditDatePhone is updated to 2021-11-13 15:00:00.
  
  Important: The 'Survive incoming empty values' setting is applied when an existing data container is updated either because the business condition returns 'true' or because a data container is matched by key. This setting has no effect when new data containers are created.

Data Container: Trusted Source

Valid for strategies: merge or link

Specifies data container instances and their attribute values that originate from the specified trusted source(s) are promoted to the golden records. The analysis is performed in the single context / workspace selected in the algorithm, and that data is promoted across all contexts / qualifiers.

Business Condition - The business condition is used on data containers to determine whether the source data container instance represents an update to one of the existing target data containers or whether a new instance should be created. If no Data Container Key is configured, the condition is mandatory. Click the ellipsis button () and select a business condition that is valid for the golden record object type.
- The condition must be a JavaScript rule that uses the 'Pairs of Attributes' bind to compare data container instances on source records with data container instances on golden records when survivorship rules are applied. For more information and an example of the bind, refer to the topic Pair of Attribute Values Bind in the Resource Materials online help documentation. Examples of this behavior can be found in the Data Containers Business Condition Example Behavior section below.

Comma separated list of trusted sources - Enter a comma-separated list of the case-sensitive Source System ID for all trusted sources, starting with the most trusted source, then the next-most, and so on. Content is taken from the first trusted source with data. If content does not exist for any of the trusted sources, nothing is promoted to the golden record and the existing golden record value is cleaned. For information on the Source System ID Attribute setting, refer to the topic Configuring the Matching - Merge Golden Record Component Model.
Data Container Type: Click the ellipsis button () and select the relevant data container type.
Last Edit Date Attribute - When no attribute is selected, the most recent date is the STEP object revision timestamp when the given element of the survivorship rule entered STEP.

Optionally, click the ellipsis button () and select the attribute that holds the value to be used as the last edit date when determining the most recent source record to promote to the golden record.
- When the selected attribute is valid for this object, timestamp is taken from the object.
- When the selected attribute is not valid for the object, the value is taken from the given element of the survivorship rule, for example, a data container object or a reference object.

Single-Valued and Multi-Valued Data Container Instances

The survival behavior of data container instances depends on whether keys are configured.

Single-valued data container instances

If a data container key is defined for a single-valued data container, it serves as a unique identifier for the data container object type and helps prevent the creation of duplicate data container instances. If a new instance is submitted with a key that already exists, the system will update the existing instance instead of creating a new one.

Multi-valued data container instances

Unlike single-valued data containers, which can hold only one instance, multi-valued data containers can contain multiple instances. In multi-valued data containers, the data container key acts as a unique identifier for each instance. This allows for the identification and management of each instance based on its unique key, even when multiple instances of the same data container are present.

Consider the following principles when configuring survivorship rules for multi-valued data container instances:

With keys

No business rule is needed to survive the data container instances. The system automatically handles survival based on key matching.
Any data container instance found on the target by key is updated with source data. Target instances without matching source keys are deleted to clean up removed data from the source. Any source data container instance without a matching key is created as a new data container instance.
Only newly created data container instances receive new data container IDs.

Without keys

A business rule is required to survive the data container instances. The business rule determines which values should survive. Updates are performed using data container IDs instead of keys.
Any data container instance found on the target by ID is updated with source data. Target instances without matching source IDs are deleted to clean up removed data from the source. Any source data container instance without a matching ID is created as a new data container instance.
Only newly created data container instances receive new data container IDs.

Regardless of key configuration, matched data container instances are updated based on the applied merge rules (‘Most Recent’ or ‘Trusted Source’).

Note: Even when a data container is configured with a key, it is possible to apply a business condition. This condition will allow you to force a distinction between records, even if they are identical.

Data Containers with Inconsistent Keys

Consider the following principles when configuring survivorship rules to account for data containers with inconsistent keys:

Data containers with inconsistent keys do not survive a merge using standard survivorship rules, even if the key is incomplete or duplicated.
When updating a target with a duplicate key, the data container with the lowest internal STEP ID survives.
Survivorship rules cannot write an incomplete key.
Survivorship rules cannot add a data container instance with a duplicated key.

For more information on data container keys, refer to the topic Data Container Keys in the System Setup documentation.

Data Container Business Condition Example Behavior

The following examples show how a business condition configuration determines whether existing data containers are updated or replaced during a merge. The initial data container IDs are '831623' (email1) and '831624' (email2).

Example 1: The condition returns 'true':

In the first example, both 'email1' and 'email2' already exist in the system, so the condition evaluates to 'true'. As a result, the data container IDs remain unchanged at '831623' and '831624' and the email addresses remain the same, while only the additional attributes are updated as needed.

Example 2: The condition returns 'false':

In this second example, while 'email1' exists in the system and returns 'true', 'email2' does not exist, causing the overall condition to return 'false'. As a result, the existing data container instance is deleted and recreated with the new email value 'email3', which generates a new data container ID of '831632'.

If the goal is to accumulate values from incoming updates rather than replacing them, the survivorship rule must include a JavaScript function that defines this logic.

Configuration with a data container key

In this scenario, instead of using a business condition, the email type is configured with a data container key. This approach prevents the creation of multiple emails of the same type, enabling updates to existing data container instances when the types match. As a result, the data container IDs remain unchanged, while the email fields are updated with incoming values.