Troubleshoot Identity Resolution

Use this page to diagnose common Identity Resolution (IDR) issues and choose the right fix path quickly.

Quick triage checklist

When a run fails or results look wrong:

1. Copy the full run error from IDR run details.
2. Confirm source models still exist and are accessible to the Hightouch role.
3. Verify each input model has:
   • a stable, unique primary key
   • a populated timestamp or updated_at column
4. Check IDR output tables in warehouse:
   • <prefix>_resolved
   • <prefix>_resolved_identifiers
   • <prefix>_unresolved
   • <prefix>_golden_records (if enabled)
5. Reproduce failing SQL in your warehouse under the same role/context as Hightouch.

Common IDR issues

Graph run fails

Common causes:

• Missing/renamed source object
• Warehouse permission changes
• Non-unique primary keys in input models
• Missing or null timestamp/updated_at fields

What to check:

1. Run details error text in Hightouch.
2. Warehouse object existence and role permissions.
3. Primary key uniqueness and timestamp completeness in input models.

How to fix:

• Repair source objects/permissions.
• Correct PK and timestamp issues upstream.
• Re-run graph after warehouse queries succeed under the Hightouch role.

Too many separate profiles (under-merging)

Common causes:

• Low identifier coverage (for example, missing email/phone on many rows)
• Deterministic rules too strict
• Limit rules too restrictive
• Probabilistic matching not enabled where needed

How to fix:

1. Improve identifier coverage upstream.
2. Revisit deterministic rule order (strongest identifiers first).
3. Loosen limit rules where legitimate multi-value behavior exists.
4. Enable probabilistic matching for messy/offline data if appropriate.

Over-merged profiles or superclusters

Common causes:

• Weak identifiers placed too high in rule priority
• Missing/loose limit rules
• Probabilistic settings too permissive

How to fix:

1. Tighten limits (for example, max 1 user_id per profile).
2. Demote/remove weak bridge identifiers.
3. Increase probabilistic confidence threshold for sensitive use cases.
4. Use Supercluster detection review and reprocessing workflow.

Large <prefix>_unresolved table

Common causes:

• Duplicate primary keys
• Missing required fields (especially PK/timestamp)
• Upstream data quality issues

How to fix:

1. Group unresolved rows by source and root-cause patterns.
2. Fix upstream ETL/model logic to enforce one row per entity and required fields.
3. Re-run and compare unresolved volume trend.

Golden Record values look wrong

Common causes:

• Survivorship strategy mismatched with business intent
• Source-priority ordering does not reflect trusted systems

How to fix:

1. Inspect profile-level source values vs selected Golden Record value.
2. Update survivorship rules (recency, frequency, source-priority) per field.
3. Consider multiple graphs if different regions/brands need different logic.

SQL troubleshooting for IDR tables

You can also see SQL compilation errors when building models, audiences, journeys, or syncs on top of IDR output tables.

Typical patterns:

• Object 'DB.SCHEMA.OBJECT' does not exist or not authorized
• invalid identifier ...
• [UNRESOLVED_COLUMN.WITH_SUGGESTION] ... cannot be resolved
• ambiguous column name ...

Fast checks for IDR-specific SQL issues:

1. Confirm the IDR output table exists in the expected schema/prefix.
2. Confirm the querying role has required access.
3. Validate referenced columns still exist in the selected output table/view.
4. Re-run SQL in warehouse with the same role/context as Hightouch.

For full SQL error patterns and fixes, see Resolve SQL compilation errors.

When to contact support

Include:

• Graph ID and run ID
• Full error text
• Query and result from warehouse reproduction under the Hightouch role
• Affected model/table names and expected behavior