Record level survivorship rules

AD
DM

Administrators and Data Managers can define custom rules that determine survivorship based on the most recent update. This can simplify survivorship when the most recent information is the most valuable and should win; for example, when you are tracking HCP channel consent.

These record-level rules are applied to data updates (from source subscriptions only) and merges. They override all source rankings and merge rules that are defined in your Network instance.

Supported objects

Record level rules can be applied to all sub-objects and relationship objects that are enabled in your Network instance.

Main objects and custom keys are not supported.

Requirements

Rules are based on custom date or date/time fields. The dates are compared between records to determine survivorship.

Sub-objects and relationships objects must have a custom field of this type so that record level rules can be created.
Sources must use these custom fields to specify when the record was last updated.

About survivorship

Survivorship in Network is typically applied using the following methods:

Source rankings - Survivorship is determined by the highest ranked source. Source systems can be ranked at the instance level, object level, and field level.
Merge instructions - Survivorship is determined by one of the following instructions:
- Exclusive merge - Field values are retained from the winning record unless the winner has no value.
- Inclusive merge - Source rankings are used to determine which value should win.
Used when merges occur through suspect match tasks, Find Suspect Match and in data updates or bulk merge using source subscriptions.
Field level merge rules - Custom rules that override regular survivorship rules. They are applied only to merges; they are not applied during data load.

When these time-based record level rules are applied, they override all of these survivorship methods listed above.

Supported actions

Record level survivorship rules are applied when records are updated using source subscriptions or when records are merged.

Updating records - The date/time is compared between the incoming data and the existing record in Network.

Survivorship scenario	Update Dropped or Accepted
Data in the source feed is more recent than what Network currently has	Accepted
Data in Network is more recent than the data in the source feed	Dropped
Data in the source feed and the current date are the same	Accepted

Rules do not apply to updates from change requests or to edits made directly on the Profile page.

Merging records - When two records (Veeva IDs) are merged, the data with the most recent date survives the merge.

Example: If the data with the most recent date/time is on the losing record, it is added to the winning record.

Note: Record level survivorship is typically based on the recentness of the data, but there is an option to choose the oldest date as the winner.

Create a time-based survivorship rule

Add a rule to determine survivorship based on the date or time of the field value.

Prerequisite

Record level rules support the following types of custom fields: Date (no time) and Date and time. Ensure that the sub-object or relationship object has a custom field of this type so you can create the rule.

Add the rule

In the Admin console, click Data Model > Custom Survivorship Rules.

Previously, this tab was called Custom Merge Rules.
Select the Record Level Rules tab.

The Field Level Rules tab contains any custom merge rules that were previously created in your Network instance.
Click Add Rule and define the details for the rule.
Rule Name - Define a name.

Supported characters: alphanumeric (a-z, A-Z, 0-9), hyphens (-), and underscores (_). The name cannot contain spaces.
Entity - Choose the sub-objects or relationship object that the rule applies to.
Field used to determine survivorship - Select the custom field that will be used to determine survivorship. Only custom date and date/time fields display.
Winning Condition - Choose either Most recent date wins or Oldest date wins .
Countries- Select the applicable countries.
Status - The rule is on by default.
Filters - Add filters to the rule if you want it to apply to selected records only.
- Field - Choose the field for this filter. The fields in the drop-down list apply to the object selected for this rule.
- Condition Choose one of the available conditions.
- Value - If the Condition that you chose requires a value, type the value. The value might be free text (for example, type a name) or a list of options.
- And/Or - Choose the operator if there is more than one filter.
Save your changes.

The rule will run when records that include that sub-object are updated or merged.

Rules can be edited or deleted.

Example - Updating data

In this example, a Consent custom sub-object stores HCP channel consent. A source subscription is loading updates for the Consent object for three HCP records. When records are updated, we want the most recent consent information to survive.

Example consent record

Records in Network - Current consent information for the HCPs

These records were originally loaded to Network using the Salesforce Marketing Cloud (SFMC) source system. Note that Record 3 currently has no Consent record.

Record	HCP Email	Consent Capture Date	Consent Status	Source System
1	alvin.li@verteo.com	2023-08-20 19:39:00	Opt-In	SFMC
2	vivian.kay@verteo.com	2023-08-20 19:39:00	Opt-In	SFMC
3	jim.davis@verteo.com	NULL	NULL	NULL

Source file - Updates to consent information of the HCP

A source file from Veeva CRM contains updates to the Consent status for Records 1 and 2 and contains new consent records for Record 3.

Note: In this example, the SFMC system is ranked higher than the CRM system.

Results - Updates to the consent information of the HCPs

Record-level survivorship rules determine the Consent Status value based on the most recent Consent Capture Date. The source rankings are overruled.

Record	HCP Email	Consent Capture Date	Consent Status	Source System
1	alvin.li@verteo.com	2023-08-20 19:39:00	Opt-In	SFMC
2	vivian.kay@verteo.com	2023-08-21 10:39:00	Opt-Out	CRM
3	jim.davis@verteo.com	2023-08-27 10:39:00	Opt-In	CRM

Record 1 - Update dropped: The incoming consent capture date was older than the current consent capture date.
Record 2 - Update accepted: The incoming consent capture date was more recent than the current consent capture date.
Record 3 - Record created: The consent data from the source feed is used to create the consent record on the HCP.

The source feed contained multiple consent records with the same email address. This can be very typical for data extracted from Veeva CRM when the consent status is updated several times creating multiple records in the Veeva CRM database.

These records were deduplicated during data load; the Source Dedup setting was on in the subscription for the Consent object.

Job details

You can see the outcome of the updates in the Job Summary Section.

In this example, one Consent record was added (Record 3) and one Consent record was updated (Record 2).

Note: The consent update that was dropped for Record 1 is not recorded. Updates that are dropped for record level survivorship are not logged in the job details.

Data loading considerations

Timezones

It is highly recommended to specify the timezone when loading data.

Record level survivorship rules always compare the incoming date/time with the current date/time on the record to determine whether to accept or drop the incoming update.

In the Network database, all date timestamps are stored in Coordinated Universal Time (UTC). For example: 2023-03-25T19:30:00Z. This can be different from the timezone that displays on record profiles. On the Profile page, the date/time reflects the time zone of your local machine.

Example: If your local computer is set to Central European Summer Time (UTC+02:00) and data is loaded at 2023-03-25T19:30:00Z (UTC), the date and time that displays on the profile page is 2023-03-25T21:30:00Z ( UTC+02:00).

Examples

Review these examples to understand if the incoming update will be accepted or rejected based on the defined timezone.

Current Date/Time in Network	Incoming Date/Time	Result	Details
2023-03-25T-19:30:00Z (UTC)	2023-03-25T-19:15:00-04:00 EDT (UTC -04:00)	Accepted	2023-03-25T-19:15:00 EDT equals 2023-03-25T-23:15:00 UTC. The incoming date/time is more recent than the current date/time.
2023-03-25T-19:30:00Z (UTC)	2023-03-25T-21:15:00+02:00 CEST (UTC +02:00)	Dropped	2023-03-25T-21:15:00 CEST equals 2023-03-25T-19:15:00 UTC. The incoming date/time is less recent than the current date/time.
2023-03-25T-19:30:00Z (UTC)	2023-03-25T-19:35:00	Accepted	No timezone was specified in the incoming update, so UTC is the default. The incoming and current date/time are in the same timezone and the incoming date/time is more recent than the current date/time.

Note: The timezone offset from UTC time must be specified in the source feed to indicate the different timezone. For example, if the data reflects Central European Summer Time (UTC+02:00), the date in the source file must include +02:00.

Source dedupe

Always enable the Source Dedupe setting for the object to ensure that duplicate records are not created.

In most cases, the record level survivorship rules will ensure that only one record survives. However, if an initial load contains duplicates in the source feed, duplicate records will be created if the Source Dedupe setting is not on.

Null values

Record level survivorship rules are based on date fields. If the date field in Network or an incoming data feed is empty or null, survivorship is handled using the following behavior:

Date in Feed	Date in Network	Result	Details
2023-03-04T-09:00:00Z	2023-03-04T-09:00:00Z	Accepted	The incoming and existing date/time is the same.
2023-03-04T-09:00:00Z	empty/null	Accepted	The incoming update has a date/time so it wins survivorship over the value in Network that has no date/time.
empty/null	2023-03-04T-09:00:00Z	Dropped	The incoming record did not specify a date/time so the date/time defined in Network wins survivorship.
empty/null	empty/null	Accepted	The incoming record wins survivorship because neither record has a date/time defined.

Example - Merging records

Records can be merged in several ways; for example, using Find Suspect Match, through the Data Updater, and bulk merge using Source subscriptions. Merges can also occur when records are merged by OpenData. When merges performed by OpenData are pushed down to your Network instance, record-level survivorship rules apply only to data managed in custom objects.

In this example, two locally managed HCP records will be merged using the Data Updater feature. The HCP records include consent data. A record level survivorship rule is applied to the Consent object to ensure that the latest consent capture date wins survivorship.

Records being merged

The losing record has the most recent consent Capture Date, so that consent information should survive on the winning record.

Data Updater job

A Merge Option must be defined for each job. In this example, we'll select Winner Priority instruction; this means all values from the winning HCP record will win during the merge unless the winner does not have a value. However, for the Consent object, the record level survivorship rule will override the Winner Priority instruction to ensure that the most recent consent information survives.

Results

When the merge completes, the most recent consent data from the merge loser is moved to the winning record.

Inactive fields

When a field that is used in a record level survivorship rule is deactivated, an Alert icon displays beside the rule name on the Record Level Rules tab.

On the rule configuration, the field is highlighted and the message "This field is inactive" displays.

Rule behavior

The rule will not be applied when the field is inactive. Survivorship is determined by the usual methods.

Filter behavior

If a field that is used in a rule filter is deactivated, the rule will be applied but the filter condition will not apply.

For example, when a rule filter specifies that the channel_status__c field value must be Active but that field is deactivated, the rule will apply to all Consent records regardless of their value for the channel_status__c field.

Deleting custom objects

If a record level survivorship rule is defined for a custom object, the survivorship rule is included in the Impact Summary before the object is deleted from your Network instance.

Managing configurations

Record level survivorship rules can be exported to target systems (Settings > Configuration Export).

A module called Custom Survivorship Rules (Record Level Rules) is added to the Available Configurations pane. All enabled rules in your Network instance can be included in your export package.

When you add a rule to the export package, the custom object and fields that are used in the rule are automatically added.