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.

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's 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"
        },
      …….
]
}

The entity ID that was not created

When you POST a new entity and the merge on-the-fly/searchBeforeCreate feature is enabled, the match methods find matches in the tenant data and merge records on the fly. The entity ID of the original entity is retained. In the Sources view in the Profile, you'll see an entirely new entity ID for the new entity that was posted. Here's a sample:

Does this mean a new entity is created? No, this entity ID is created for internal use only. For example, to refer to the entity in the history or UI.

A search for this entity ID will not return any results. Neither will it be part of any event or report that you generate.

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.

If there are no changes to attribute values and crosswalks when entities and relationships are merged, the Updated time is also not affected. In other words, during merging, the Updated time only gets updated if there are any changes to the entity's attribute values or crosswalks.

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.

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:

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.