Automatically unmerge entity records

Learn about use cases for automatically unmerging entity records.

Are you a data steward or technical leader who is in charge of managing and analyzing your organization's data consolidation? If you often find yourself manually unmerging consolidated entity records, then this topic is for you!

When can't you use automatic unmerge?

When you are using options for contributors or data providers in the data loading processes, also known as merge-on-the-fly by crosswalk
When you are using Reltio Integration for Salesforce or Reltio Enrichment with D&B with a third-party Data Tenant Subscription Service (DTSS)
When you are using Reltio Enrichment with D&B (Data Blocks) or Reltio Enrichment with ZoomInfo

When can automatic unmerge help?

There are two situations where automatic unmerge can help you:

When an attribute value is updated on its source data crosswalk. Imagine a first name attribute – involved in match rules – changes from "John" to "Jack", causing a contributing profile to no longer match. You can see, below, an example for the default setting — unmerge not enabled, for all entity types. Under this setting, you are limited to manual unmerge actions.
By enabling unmerge at the EntityTypes level you can have profiles that no longer match, automatically unmerged, without requiring your time and attention.
Create, Read, Update, and Delete (CRUD) events drive Automatic unmerge actions. These actions happen in near real-time as attributes are changed on contributing source crosswalks.
You can decide, on a case-by-case basis, which entity types to enable unmerge for, based on your specific needs.
When you need to change an automatic match rule or update survivorship strategies, causing some profiles to no longer be a match.
In these situations, things are a bit different from what we talked about in the previous point. Instead of automatic unmerge happening on-the-fly, you'll need to execute BatchUnmergeEntities, see topic Automatic Unmerge Task.
When you execute this API, you'll only impact those entity types for which you've enabled unmerge.

When to use caution with automatic unmerge

Automatic unmerge operations are computationally intensive by design. The system performs in-memory evaluations to determine whether merged entity records still meet match conditions.

Use extra caution when enabling automatic unmerge for entity types that include address cleansing services like Loqate or contain address as a nested attribute (for example, the Location entity type). In these cases, unmerge evaluations also trigger cleansing jobs, which can further degrade performance and cause tenant-wide slowness.

You can still enable the feature in these scenarios, but we recommend doing so only when the business value clearly outweighs the performance cost.

Consolidated profiles in automatic unmerge

As explained above, the automatic unmerge feature evaluates profiles when there are changes to the source attributes or there is a change in the match rule.

The unmerge process also evaluates multiple crosswalks belonging to the same data source, and will unmerge the records if they are no longer a match. This also includes crosswalks from third-party enrichment systems. If you want to ignore certain crosswalks from being unmerged, you can list the crosswalks under the retainMergeConditions section of the Automatic unmerge feature configuration.

Under the retainMergeConditions section, you can also specify the automatic match rules (with scope = NONE) that you want to ignore during the automatic merge. Here's an example of why we would want to ignore match rules. Let us assume that two records with the same name, address, and phone number are merged. The phone number is updated, due to which the records are automatically unmerged. But another source system updates the phone number back to the original value, so the records are merged again as a result of automatic match rules. To avoid this scenario, create a new automatic rule setting the scope to NONE, adding only the name and address as a matching criteria. Add this rule under the retainMergeConditions section. This avoids the unmerging and merging of records again.

Manual merges are not considered during this process. Entities that are merged either using merge APIs, or manually merged by a data steward are not unmerged automatically. However, if you want to include manual merges during this process, you can configure the automatic unmerge feature to include it.

The automatic unmerge feature requires at least one automatic match rule in the entity type or a relevance-based rule with the auto_merge action. Without such a rule, automatic unmerge does not take place. This behavior prevents entities from being split apart when no automatic match rules are available to keep them merged. To use the automatic unmerge function without defining any automatic match rules, create an automatic match rule with extremely strict conditions that are not expected to match any pair. This rule can be assigned to the entity type, allowing the automatic unmerge feature to function while ensuring that entities remain separated.

To summarize, consolidated profiles are automatically unmerged if:

Underlying profiles are not found to be a match during evaluation using automatic match rules.
Note: If the merged records satisfy at least one of the automatic match rules, they remain consolidated.
The retainManualMerges parameter is set to false and the profiles were merged manually. For more information about the retainManualMerges configuration, see topic Enable automatic unmerge on the tenant configuration.

Consolidated profiles are not automatically unmerged for a specific entity, if:

They are solely composed by Reltio related data sources (e.g., Reltio, Reltio Data Cleanser, Reltio Pattern Cleanser).
Their data source is the same. The system interprets them as singleton profiles.
The retainMergeConditions.matchGroups contains a rule and the profiles are merged based on one of the listed rules.
One of the records in the consolidated profile belongs to a source listed under retainMergeConditions.sources.

How automatic unmerge evaluates contributors

When automatic unmerge is triggered through the BatchUnmergeEntities task, the system evaluates each contributor (source entity) using a two-phase comparison model. Contributors are separated only if no automatic match rule continues to justify their consolidation.

Phase 1: Pairwise evaluation

Each contributor within a consolidated profile is compared individually against every other contributor in that profile. If at least one active automatic match rule returns true between two contributors, neither contributor is eligible for automatic unmerge during this phase.

This evaluation preserves valid pairwise matches and prevents contributors that still satisfy matching conditions from being split prematurely.

Phase 2: Group evaluation

Each contributor is then compared against the group of all remaining contributors. The evaluation uses the surviving attribute values currently represented in the consolidated profile.

If an automatic match rule still evaluates to true when the contributor is assessed against the aggregated group values, that contributor is not unmerged.

A contributor is automatically unmerged only if it fails to match in both phases. In other words, the contributor must fail all match rules, both in individual and group evaluations.

This two-phase design prevents unmerge and remerge loops. Without this safeguard, separating a contributor could immediately cause it to match again with the remaining contributors, resulting in repeated merge and unmerge operations.

Automatic Unmerge examples

To help you visualize what happens under the hood when you enable this feature for an EntityType, we'll lay out the following examples.

Example 1 - Automatic unmerge after an attribute update

Entity 1 (E1) is automatically merged with entity 2 (E2).
Information on the merge is written to the merge tree.
Contributing entities are listed in the surviving entity.
Attribute FirstName, from E1, is updated on its source data crosswalk.
In-memory testing detects E1 and E2 no longer match (CRUD event).
E1 is automatically unmerged from E2.

Example 2 - Automatic unmerge from a larger consolidated group

E1 is already automatically merged with E2.
E3 is merged with surviving E1.
Information on the merge is written to the merge tree.
Contributing entities are listed in the surviving entity.
Attribute FirstName, from E3, is updated on its source data crosswalk.
In-memory testing detects E3 and E1 no longer match (CRUD event).
E3 is automatically unmerged from E1.
E2 remains merged to surviving E1.

Example 3 - Automatic unmerge of a different contributor from a consolidated group

E1 is already automatically merged with E2.
E3 is merged with surviving E1.
Information on the merge is written to the merge tree.
Contributing entities are listed in the surviving entity.
Attribute FirstName, from E2, is updated on its source data crosswalk.
In-memory testing detects E2 and E1 no longer match (CRUD event).
E2 is automatically unmerged from E1.
Surviving E1 now contains exclusively E3 in its merge tree (at the beginning of this example, E1 contained exclusively E2 in its merge tree).

Example 4 - No automatic unmerge due to matching contributors

Entities A, B, C, and D are merged by an automatic match rule based on exact FirstName and LastName.
An aggregate survivorship strategy is applied, so all first and last names from all contributors are marked as OV=true.
Contributors A and B share the name "Alex Morgan."
Contributors C and D share the name "Taylor Jordan."
Automatic unmerge is enabled and BatchUnmergeEntities is executed.
No contributors are unmerged.

Why no unmerge occurs

During Phase 1, Entity A continues to match Entity B because they share the same first and last name.
During Phase 2, Entity A is compared against the combined group of B, C, and D. The aggregated group still contains the name "Alex Morgan" from Entity B, so the automatic match rule still returns true.

Because the contributor still satisfies an automatic match rule in both evaluation phases, it is not eligible for automatic unmerge.

Possible approaches

Manual separation of a contributor: If one contributor from a matching pair is manually unmerged, the remaining contributor can be evaluated again against the smaller group. If no automatic match rule applies in both phases, that contributor will then be automatically unmerged.
Isolated automatic rule evaluation: This approach is intended for demonstration purposes only and is not recommended for production use. Create an automatic match rule using a dummy or unused attribute and disable all other automatic match rules by setting their scope to NONE. Then run BatchUnmergeEntities passing only the specific entity IDs you want to evaluate. Without this scoping, the task runs across the entire tenant. Because the dummy rule is not expected to match any contributors, this approach produces the same result as calling _unmergeAllContributors directly on the entity.

Unify and manage your data