Active crosswalks missing from the Sources panel or _crosswalkTree, with multiple address values on the Golden Record

Summary

An entity’s crosswalks are active and contribute attribute values, but one or more do not appear in the Sources panel or in the GET /entities/{id}/_crosswalkTree response. The same entity may also show multiple address (or other reference) values on its Golden Record, all pointing to the same underlying object. This usually means the entity’s merge history (merge tree) is missing the entry for the entity that contributed those crosswalks. The Merge Tree Consistency task can rebuild the merge tree with Support’s guidance.

Symptoms

• A source record you loaded does not appear in the Sources / Crosswalks panel, but its attribute values show on the profile.
• GET /entities/{id}/crosswalks returns more crosswalks than GET /entities/{id}/_crosswalkTree.
• The entity shows several operational values for a reference attribute (for example, three addresses that are all the same address). In the entity JSON, each is a separate relation to the same Location, all with "ov": true.
• Merge history or event data shows more merged crosswalks than the merge tree contains.

Cause

GET /entities/{id}/crosswalks returns the crosswalks attached to the entity. GET /entities/{id}/_crosswalkTree shows them grouped under the entities that contributed them, built from the entity’s merge history. If a contributing entity has no entry in the merge history, its crosswalks have no place to attach in the tree, so they are left out even though they are active.

When this happens, relation crosswalks for the same contributor can be left out. A later update that carries the same relation crosswalk may then not match the existing relation and create a new one. That would explain the duplicate address values. The exact cause varies by case and isn't always identifiable after the fact.

How to confirm

Compare the two responses for the affected entity. Exclude Reltio-generated crosswalks (such as ReltioCleanser and ReltioFullNameBuilder) from the count.

GET {TenantURL}/entities/{entityId}/crosswalks
GET {TenantURL}/entities/{entityId}/_crosswalkTree

1. List the source crosswalk URIs returned by /crosswalks.
2. List the crosswalk URIs that appear in _crosswalkTree (both under merges[].losers[].crosswalks and in the root crosswalks).
3. A crosswalk that appears in the first list and not in the second confirms the symptom.
4. Look at the initialSource of the missing crosswalks in the /crosswalks or _changes output. If the missing ones all share one initialSource entity that appears nowhere in the tree, that is the pattern this article covers.

To check for duplicate relations:

GET {TenantURL}/entities/{entityId}

In attributes.Address (or your reference attribute), look for several values with "ov": true whose relations point to the same Location entity (refEntity.objectURI).

Resolution

Use the Merge Tree Consistency Based on Records task. Run it first in read-only mode, and contact Support before running it in repair mode.

Step 1. Run in read-only mode (fixInconsistency=false):

POST {TenantURL}/mergeTreeConsistencyCheckForRecords?fixInconsistency=false
Content-Type: application/json
Authorization: Bearer <access token>

{
  "entitiesToCheck": ["entities/{entityId}"],
  "checkAll": true
}

Use your tenant’s host and API path as documented for your environment. The task creates a task ID. Check its status with GET {host}/reltio/tasks/{taskId}. A result like this means the check found the problem:

{
  "type": "...MergeTreeConsistencyBasedOnRecordsTask",
  "status": "COMPLETED",
  "currentState": {
    "WinnersWithInconsistencyCount": 1,
    "WinnersWithInconsistency": ["<entityId>"],
    "EntitiesWithCrosswalkIssueCount": 1,
    "numberOfFailedToPublishEvents": 0
  }
}

Step 2. Contact Support with the task ID and the entity IDs. Repair mode changes merge-tree data, so it needs the right permissions and your approval.

Step 3. Repair mode (fixInconsistency=true, same request body). For a small list of entities, the task typically completes in seconds.

Verifying the repair

• _crosswalkTree now includes the missing crosswalks. They appear under a contributor entity marked as "phantomEntity": true, together with their relation crosswalks.
• The entity’s duplicate reference values may consolidate into one after the repair (for example, when the entity is next read). In a reported case, multiple identical addresses collapsed to one OV value. Check the entity JSON after the repair.
• Check any downstream consumer (such as a Databricks or Snowflake table, or an API client) that showed the duplicates.

The repaired merge-tree entries show the repair time, a generic merge reason (“Merge on the fly”), and no match rule. They restore the structure, not the original merge timing. The crosswalks’ own load dates do not change.

What not to do

• Do not delete and reload the record, or unmerge and re-merge it, to try to fix the tree. This does not rebuild the missing merge-history entry and risks data changes.
• Do not run the task across the whole tenant without Support. On large tenants, a tenant-wide scan can run for days or weeks.
• Do not treat a clean read-only result as proof that the problem is fixed, or an inconsistent one as approval to repair. Share the result with Support first.
• Reindexing does not help. The Sources view and _crosswalkTree come from merge history, not the search index.

When to contact Support

Open a ticket if you see this symptom, especially after a bulk or integration load. Include:

• Tenant ID, environment, and the affected entity IDs.
• Approximate time of the load or integration run that created the records.
• The /crosswalks and _crosswalkTree outputs, and the task ID if you ran the read-only check.
• Whether the records came from a batch, so Support can check others from the same load.

Report it soon after you notice. Event and activity logs are kept only for a limited time, and reporting quickly makes it more likely the cause can be found.