Salesforce External ID vs Record ID in Integrations
A Salesforce record ID and an External ID solve different problems.
A Salesforce ID answers:
Which record is this inside Salesforce?
An external identifier can answer:
Which business entity do Salesforce and another system agree this represents?
Why the Difference Matters
Imagine a customer originates in an ERP with identifier:
ERP-CUSTOMER-48392
Salesforce creates an Account with its own Salesforce record ID. If integrations exchange only the Salesforce ID, the ERP still needs a mapping table to understand that identity.
A designated external ID can make the relationship explicit:
ERP customer 48392
<->
Salesforce Account where ERP_Customer_Id__c = 48392
Upsert Becomes Natural
External IDs are especially useful with upsert-style synchronization:
if external identity exists -> update
otherwise -> insert
This can make repeated synchronization safer than treating every inbound record as a new create.
Do Not Invent a Weak Key
An external ID should be stable and authoritative for the integration context. Email address, display name or another mutable attribute is often a poor identity simply because it happens to be available.
Ask:
- Who owns the identifier?
- Can it change?
- Is it unique in the required scope?
- Can it be reused?
- Is the same identity available during retries and reprocessing?
Salesforce IDs Still Matter
Once a Salesforce record has been resolved, its Salesforce ID remains useful for Salesforce-specific relationships and operations. This is not an either/or choice.
A common pattern is:
external ID -> cross-system identity
Salesforce ID -> Salesforce-native identity
Final Principle
Use Salesforce record IDs when you need to identify records inside Salesforce. Use well-designed external IDs when integrations need a stable identity across system boundaries.