Indirect lookup needs Salesforce Connect, a registered external data source, an external object, and a unique external ID field on the target Salesforce object. Once the prerequisites line up, the field is straightforward. The hard part is choosing the right join key and proving the keys actually match across both systems.
- Identify the business key that joins both systems
Talk to the data owner on both sides. SKU, customer number, transaction reference, employee badge ID: pick the identifier that both systems treat as authoritative. Avoid surrogate keys that one system can regenerate without notifying the other, because that produces silent breakage.
- Create the unique external ID field on the target Salesforce object
Object Manager, target object, Fields and Relationships, New, Text (or appropriate type). Check both External ID and Unique. Without Unique, the indirect lookup will not appear as an option in the external object configuration.
- Backfill the unique field with current values
Load the existing business keys into the new field through Data Loader. Validate that no duplicates exist before the Unique constraint catches them at load time. Plan a remediation step for any conflicts you find, because the source system may already have inconsistencies.
- Open the external object and create the indirect lookup field
Object Manager, the external object (suffix __x), Fields and Relationships, New, Indirect Lookup Relationship. Pick the target Salesforce object and the unique external ID field as the join key. Save and validate that the relationship resolves on a known matching record.
- Configure layouts and FLS
Add the indirect lookup to the external object page layout and to any related lists on the Salesforce parent object. Set field-level security per profile or permission set. Profiles without read access see the field as blank and may report it as missing data.
- Build the reconciliation report
Create a report that lists external object rows whose indirect lookup resolves to no Salesforce record. Schedule it to run daily and route the output to the integration team. This is the early warning system for missing keys before users complain.
- Document the recovery runbook
Write down the steps to handle the three common failure modes: a Salesforce record is deleted but external rows still reference it, a new external row arrives with no Salesforce match, and a duplicate key blocks a load. Hand the runbook to support before go-live so unresolved lookups do not escalate.
The standard or custom object the external row joins to. Selected during indirect lookup field creation.
Must have both External ID and Unique flags checked. Stores the business key the external system uses.
The __x object exposed through Salesforce Connect where the indirect lookup field lives. Holds the key value to resolve.
- The join field on the Salesforce side must be marked Unique, not just External ID. Without Unique, the field does not appear in the indirect lookup picker and the platform gives no clear error.
- An external row whose key has no matching Salesforce record shows as blank with no error. Users report it as missing data, and the integration team learns about it through support tickets.
- Merging or deleting Salesforce records breaks any external rows still holding the old key. There is no automatic cleanup on the external side because Salesforce cannot write to the source system.
- Indirect lookup needs Salesforce Connect. The field type is hidden if the add-on is not licensed, regardless of org edition or how many external systems you have.
- Changing the data type of the unique external ID later requires recreating the indirect lookup. Plan the field type (text, number, email) carefully before the first external row loads.