Accelerate the Value of Data

Merge matched data

You can merge and unmerge entities and relationships along with nested attributes.

The concept of merging applies to entities, relationships, and nested attributes. Refer again to Quick Review of Reltio Information Architecture as it relates to Match, Merge, and Survivorship for an overview of this topic.

Merging of Entities

When entities merge, two things occur at the entity level. First the oldest entity ID of the two IDs is chosen as the winning ID. The other ID is not discarded but is held invisibly within the metadata of the merged (aka consolidated) entity. Subsequent posts can reference the losing ID and the post will be applied to this merged entity. Secondly, all of the crosswalks of the losing entity are absorbed by the winning entity. Thus the merged entity is simply an aggregate of all the crosswalks and all of the crosswalks’ attributes and values from the two entities. The merged entity, like any updated entity, is subjected to the usual sequence of cleanse, match, (and potential additional merge) processes.

Consider that a profile is defined as an entity along with all of the relationships and interactions linked to it. When two entities merge, the relationships and interactions are also transferred to the merged entity.

Note: After you merge entities, Reltio automatically removes the DCR on the loser entities.

Unmerging of Entities

When entity B is unmerged from entity ABCDE, all of the relationships and interactions from entity B that came into the ACDE are still known within the metadata of ABCDE, and they are returned to the entity B during the unmerge.

Merge-on-the-fly

As stated above, if a POST contains the source and crosswalk of an existing entity, the data from the POST is applied immediately to the crosswalk within the entity and the operation is known as an update to that entity. Conversely if the POST does not find an existing crosswalk to update, then the POST will likely result in the creation of a new entity, which typically will get tokenized, indexed, and potentially matched and merged by subsequent operations.

In this latter scenario above, Reltio has optimizations built-in so that if system resources are sufficiently available at the time of the POST, the platform optimization engine may elect to perform a match and merge without incurring the cost of first creating a new entity. This tactic is referred to as merge-on-the-fly and it is mentioned here because as a Customer Admin or developer, you should be aware that it results in a different set of events being streamed to the external queue than if an actual entity had been formed. For example, you will not see an Entity Create event if merge-on-the-fly occurred. Also, in the UI there are references to merge-on-the-fly, specifically in the History tab. As such, you can think of these references merely as informational, and use them at your discretion.

Controlling Merge-on-the-fly

While merge-on-the-fly is generally viewed as a feature that streamlines the merge process, you may wish to disable it so that an actual entity with an entity ID will be created each time a new record is POSTed through the API. You can enable or disable merge-on-the-fly through a combination of the Tenant-Level Match Strategy chosen for your tenant and metadata configuration applied to your tenant.

See the sample metadata configuration below. If matchBeforeCreate is set to false, merge-on-the-fly is disabled. If matchBeforeCreate is set to true, merge-on-the-fly is enabled.

{
      "uri": "configuration/entityTypes/Location",
      "label": "Location",
      "description": "",
      "typeColor": "#FF9900",
      "typeIcon": "images/base_type/house.png",
      "typeImage": "images/defaultImage/no-loc.png",
      "typeGraphIcon": "images/graphIcon/location-icon.png",
       “matchBeforeCreate”: false,
      "attributes": [
        {
          "label": "Name",
          "name": "Name",
          "type": "String",
          "hidden": false,
          "important": false,
          "system": false,
          "required": false,
          "searchable": true,
          "uri": "configuration/entityTypes/Committee/attributes/Name"
        },
      …….
]
}

Merging of Relationships

Relationships share the same basic architecture as entities. They are containers of crosswalks that hold attributes. They also can match and merge but the process is intrinsic and doesn’t require any match rules. Any two relationships of the same type, that each have entity E1 at one endpoint and entity E2 at their other endpoint, will merge automatically. Relationships can have simple and nested attributes (they do not support reference attributes) and they are multi-valued, just like with entities. So when they merge, just like with entities, the resulting merged relationship is an aggregate of the crosswalks, attributes and values of the two relationships.

Note: After you merge relationships, Reltio automatically removes the DCR on the loser relationships.

Unmerging of Relationships

Similar to how relationships merge automatically (see above) they unmerge automatically as well, as needed when the entities they are related to are unmerged.

Merging of Nested Attributes

When entities merge, the nested attributes within those entities aggregate into the merged entity just like simple and reference attributes do. However with a nested attribute, it is desirable for any duplicate nests to also merge. Consider the following two phone nest instances, one from entity A and one from entity B.

Phone
  • Type: Mobile
  • Number: 818-999-1111
  • Status: Active
Phone
  • Type: Mobile
  • Number: 818-999-1111
  • Rank: 1

Clearly these are referring to the same phone number and type, but the first has Status info where the second doesn’t. Conversely the second has Rank info whereas the first doesn’t. If we don’t merge these nests, they would both appear in the UI like you see above, and that isn’t very good.

Using MatchFieldURI in the metadata configuration, you can identify sub-attributes of a nest definition. If the sub-attribute(s) values are equal, the nests will merge. For example, if the MatchURI configuration identifies the Type and Number sub-attributes of the Phone nested attribute as the criteria for merging. For MatchFieldURI, there is no concept of match rules. The idea simply is that for the attributes you identify, if the values are equal, then the nests will merge. In this case, the merged nest will become the following:

Phone
  • Type: Mobile
  • Number: 818-999-1111
  • Status: Active
  • Rank: 1
Note: Consider the following points, when merging nested attributes:
  • When two entities merge, each with their own nests that also merge within the merged entity (the example above) then when the entity is unmerged, the individually restored entities will regain the values from their original nests.
  • If an entity is edited and during the edit a matching nest is added, then the new nest will merge with the existing one just as in the case where two entities had merged. However, in this scenario since the new nest didn’t come from a separate entity, the crosswalk of the additional nest will be associated with the current entity ID. Thus there is no ability to unmerge these new values out of the current entity ID.

Automatic Merging

When two entities match by the crosswalk, the entities are merged automatically and the Automatic merge on object read event is triggered. Automatic merging can not be disabled as it guarantees crosswalk uniqueness.