Merging Records with Merge Rules

Last updated

The different merge rule types explained.

When merging records within an object, Plauti Deduplicate calls upon the Merge Rules to pick a master record, and to determine which field values should be stored in that master record. The Merge Rules also determine which master record and fields are pre-selected on the manual merge page, which fields can use AI Merge Recommendation‍, and which rules are used when executing an automated merge.

Stack up to four rules for the master record, for a field, or for a field group, and end each stack with a tiebreaker rule. Create multiple merge rule sets per object, so that different records are merged according to different logic.

Merge Rule Sets

Use merge rule sets to apply different merge logic to different records within the same object, for example different rules for Web leads and Phone leads, or per record type. Each merge rule set has its own master record rule, field rules and field groups, and its own stacked rules.

How a merge rule set is selected

  1. Plauti Deduplicate identifies a duplicate group for the object.
  2. Merge rule sets are evaluated in order of their priority number, starting with priority 1, and ending with the Default Merge Rules set which has priority 100. The first set that matches the records is applied.”
  3. A merge rule set applies only when every record in the merge matches the set's rules.
  4. Record groups that do not fully match any other merge rule set fall back to the Default Merge Rules set.

The audit log of a merge tracks which merge rule set was applied.

Default Merge Rules Set

Every object has a Default Merge Rules set that is always active, so there is always a merge rule set available for the manual merge page, quick merge and automated merges. It cannot be deleted, renamed or deactivated, but its rules can be edited. You can clone the default set as a starting point to create a similar but slightly different Merge Rules Set.

When you add a new object to Deduplicate Setup, its Default Merge Rules set is created and activated automatically.

Master Record Rule

The master record is the record that will be kept in Salesforce after merging. Out of a group of duplicate records, the master record is picked based on the master record rule. If the rule cannot determine a winning record, a tiebreaker rule is used. This means that the master record rule can be a single rule (date/time based), or a stack of up to four rules, followed by a tiebreaker that always selects a single record.

For example, you can decide that the master record is always the oldest record (Created date: Least Recent), the record with the most fields populated, or the record with the most attachments. Or use a value based record rule to set more advanced rules on text fields, so that the master record will always be the record that has a name that "starts with C", or a level that is "equal to 1".

When deciding the master record based on a field based rule, another option is 'most common value'. For example, decide that the master record has to be one of the records with the most often occurring value in the "email" field. Out of these records, the master record is then decided by the next rule in the stack or by the tiebreaker rule.

Let end-users change the master record

Decide if end-users working with the manual merge page are allowed to select a different master record than the one selected by the Master Record Rule. It could make sense to set a strict rule for defining the master record, which users are not able to bypass.
Toggle "Manual master selection" in the master record rule configuration window to allow or disallow this.

Note that this applies only to deciding which record will be the master record. If disabled, users can still set certain field values on loser records to be copied over to the master record upon merge.

Field Rules

Field rules decide which field value will be kept in a master record. This is often the value from the master record, but it can also be a value from one of the losing records.
To keep the master record value for a certain field, simply leave its field rule set to 'Master Record Rule'. This is the default value for field rules. Fields that are set to follow the Master Record Rule are therefore not listed as a configured field rule. Their value upon merge will always be the value of the master record.

For keeping a value from either the master or a loser record you have several options, depending on the field type. For example, take the longest value among the values on the master and losing records, or the most common value. For number fields, you can use a math rule such as average, sum, multiply or subtract to apply to all master and losing record values of a field, and record the outcome on the master record.

Note that for date field rules such as Modified Date: Most Recent, the date of the record is considered, not the date of the particular field. So if between record A and record B the email field of record A was modified last, but after that a different field on record B is edited, the email address of record B will be retained when using field rule Modified Date: Most Recent.

Keeping a value based on another field

A field rule normally decides a value by looking at the values of that same field across the duplicate records. With a Value Based rule, you can select a different field to evaluate on each record. This means the record that supplies the value can be chosen based on information stored elsewhere on the record, such as a validation status, a status code or a flag set by an integration.

When several fields must come from the same record, assign this kind of rule to a field group rather than a single field (see below). The field you evaluate does not have to belong to the group.

Field Groups

Plauti Deduplicate lets you group fields, which you then can assign a single field rule. This way the field values in a group are always taken from the same record, and kept together in a merge. So, for example, group the "email" and "email bounced reason" fields to make sure they always stay together. Or, decide to group a custom address field-set, which is then kept together always, even if one of the fields in the group is empty.

For field groups, "Allow Blank" (see below) is set on the group, not on the individual fields in the group. A group with only part of the fields empty, for example a partially-filled address with a city and zip code filled in but no street, is considered to be not empty.

Stacked rules and the Tiebreaker

Some of the master record rules and field (group) rules can't always pick a single winning record or value straight away, if several records or values can match the rule. For these cases, you can configure follow-up rules. Ended with a tiebreaker rule, the merge rules will always result in only one winning record or value.
Furthermore, you can decide to which records in the duplicate group the follow-up rules should apply: only the records that meet the criteria of the previous rule, or all records from the duplicate group.

How a stack is evaluated

Rules are evaluated from top to bottom, narrowing the group of records as they go.

  1. The first rule is applied to all records in the duplicate group.
  2. If exactly one record matches, that record wins and no further rules are evaluated.
  3. If more than one record matches, the next rule is applied, either to the remaining records or to all records, depending on the 'Applies to' setting of that rule.
  4. If no record matches, the rule is skipped and the next rule is applied to the same records.
  5. The rule labeled Tiebreaker at the bottom of the stack always selects exactly one record.

The Tiebreaker is required and is always the last rule in the stack. You can choose one of the following rules as the Tiebreaker: Created Date: Least Recent, Created Date: Most Recent, Modified Date: Least Recent or Modified Date: Most Recent. Date rules always select exactly one record, so they can only be used as the Tiebreaker. All other rules can be stacked above it.

If four rules and a Tiebreaker cannot express the logic you need, use a Merge Plugin.

Applies to

Every rule below the first rule has an 'Applies to' setting that controls which records the rule evaluates. The first rule is always applied to the whole duplicate group. For the next rules you can decide to only consider the records that remain after the rules above it have been applied ('Records selected by previous rule'), or to return to all records of the duplicate group, including records that were eliminated by the rules above them ('All records').

A rule set to 'All records' discards the narrowing done by the rules above it. If the first rule in a stack protects a category of records, a later rule set to All records can bring the excluded records back into contention. Use 'Records selected by previous rule', unless you specifically want eliminated records to become eligible again.

Retain all values of a field

There are a couple of options available for keeping the values of all records upon merging, instead of picking just one value to keep.

  • Concatenate stores the values of the master and losing records together in the field on the master record.
  • Keep all values is similar, but stores the loser values in a second field, so that any existing values are not overwritten. You can even store values from several fields in this extra field, although it is recommended to use separate extra fields for clarity and size. If the maximum character limit of the long text area is reached, the values are truncated at the end.
  • With multi-select picklists you can Combine the values of the master and losing records, and add them all to the picklist on the master record.
  • For fields in a Field Group you can use Divide Values to divide all values from the master and loser records over the field group fields on the master record. Any additional field values are stored in a separate field.
    For example, group all email fields and apply "Divide values". Now, in a merge operation, all email values from all records are kept and divided over the email fields in the master record. Any additional values are stored in the mapped long text area field.
    Dividing only works for fields of the same field type.

Let blank fields be potential winners

Many fields and field groups have an option to "Allow Blank": allow a blank value. If enabled (ticked), a blank value can be chosen as a winning value to keep on the master record if the merge rule points to that value.
If disabled, and a merge rule initially points to an empty field, the rule is re-applied to decide which field value from the remaining records is best suited to be used in the master record.

"Allow Blank" is set for the entire stack of rules, not per rule.
For field groups, "Allow Blank" is set on the group, not on the individual fields in the group, and applies to every field in the group. This means for example that partially-filled addresses (e.g. addresses with a city and zip code filled in but no street) are considered to be not empty.

AI Merge

If the AI Merge Recommendation‍ feature is enabled, you can select a maximum of ten fields that can get an AI-generated merge suggestion. If you have the feature enabled in the General Setup, but do not enable it on an object's Merge Rules tab for specific fields, AI Merge Recommendation will decide which fields are best suited for recommendation on a case-by-case basis.

Merge Plugins

If you want to create rules that are more complex than what you can configure in the Merge Rules, for example if you want to use fields of a different object, have a look at our Merge Plugins. Use a Merge Plugin to execute custom Apex code before or right after a merge operation is done. Merge Plugins and Merge Rules work together well.

A Merge Plugin could be needed when a condition depends on a field on a different object, on data outside Salesforce, on logic that cannot be expressed as a single field comparison, or on more decision steps than a stack of four rules and a tiebreaker allows.