Effects of entity operations on materialized hierarchies
Learn more about how merge, unmerge, unlink, and delete operations affect materialized hierarchies.
Entity merge, unmerge, unlink, and delete operations affect materialized hierarchy placement, branches, effective dates, and metadata. Unmerge behavior can depend on whether hierarchy connections were created with entity IDs or crosswalks.
Merge scenarios
The following table describes how materialized hierarchies are updated when entities are merged.
| Scenario | Hierarchy behavior |
|---|---|
| Replacing the losing entity would create a cycle | The entity merge completes, but Reltio does not apply the hierarchy remap that would create the cycle. Existing hierarchy data remains available, and the notification service notifies users about the cycle. |
| Both entities are children of the same parent | The winning entity replaces the losing entity, so only one node remains under the parent. The losing entity's child branch is attached under the winner. |
| The entities have different parents | The winning entity replaces the losing entity wherever the losing entity appears. The winning entity can appear under both parent locations after the merge. |
| The entities belong to different unversioned hierarchy instances of the same hierarchy type | The hierarchy instances are combined. The winning entity's hierarchy keeps its name, connections from both hierarchy instances are merged, and overlapping intervals for duplicate connections are combined. |
| The losing entity has child nodes | The losing entity's child branch moves under the winning entity, preserving the branch under the winning entity. |
| The entities have overlapping effective-date intervals | The overlapping intervals are combined into one interval. The resulting interval starts at the earliest start date and ends at the latest end date. |
| The entities have conflicting hierarchy metadata | The winning entity's hierarchy metadata takes precedence, including labels, localized labels, display information, and ordering-related metadata. |
| The entities have conflicting inherited attribute rules | Inherited attributes and attribute applicability are recalculated using the winning entity's final position. The losing entity's inherited context no longer applies. |
| The merged entity is a hierarchy root | The winning entity becomes the surviving root entity. If the merge would create a cycle, Reltio does not apply the hierarchy remap. |
Unmerge scenarios
The following table describes how a materialized hierarchy is updated when a contributor entity is unmerged.
| Scenario | Hierarchy behavior |
|---|---|
| The original hierarchy placement is available | The restored entity returns to its previous parent and position. If the original placement cannot be identified, the entity is not restored automatically. |
| The hierarchy changed after the merge | If the hierarchy connections were created with entity IDs, the original placement cannot be restored after the hierarchy changes, and the nodes remain with the winning entity. If the connections were created with crosswalks, the crosswalk information lets the nodes be split and restored. |
| New connections were added after the merge | New connections remain with the winning entity unless source or crosswalk information identifies a connection as belonging to the restored entity. Without this information, the connection remains with the winning entity. |
| Child nodes originated from the losing entity | Source or crosswalk information identifies child nodes that originated from the losing entity. Those nodes move back to the restored entity, while child nodes that originated from the winner remain with the winner. If ownership cannot be determined, the subtree remains with the winner. |
| The unmerged entity has effective dates | Historical temporal information is used to restore the split entity's effective dates. If this information is unavailable, the restored entity uses the winning entity's current effective dates. |
| The unmerged entity was a hierarchy root | Root-level unmerge is not automatically restorable. The root entity is not returned to its previous hierarchy placement. |
Unlink and delete scenarios
The following table describes how unlink and delete operations affect materialized hierarchies.
| Scenario | Hierarchy behavior |
|---|---|
| An unlinked node has child nodes | Unlinking the node moves its child subtree into a separate hierarchy. The root of the detached subtree retains the original hierarchy ID. |
| A parent entity or hierarchy node is deleted | Deleting the parent or node removes its branch from the hierarchy, including the child nodes below it. The child nodes are not retained as separate orphan nodes. |