External IDs and External Relationships

External IDs and External Relationships in Salesforce – Complete Guide for Platform Developer 1

Why External IDs and External Relationships Matter

When working with Salesforce in real-world enterprise environments, you rarely operate in isolation. Data frequently flows between Salesforce and external systems such as ERPs, data warehouses, marketing platforms, and legacy databases. Each of these systems has its own unique identifiers for records. External IDs and External Relationships are the mechanisms Salesforce provides to bridge the gap between Salesforce's internal record identifiers (the 15- or 18-character Salesforce ID) and identifiers used in external systems. Understanding these concepts is critical for the Platform Developer 1 exam and for building robust integrations.

What Is an External ID?

An External ID is a custom field on a Salesforce object that is marked with the External ID attribute. This field stores a unique identifier from an external system, allowing you to reference Salesforce records using values that originate outside of Salesforce.

Key characteristics of External ID fields:

• Only certain field types can be designated as External IDs: Text, Number, and Email fields, as well as Auto-Number fields (though Auto-Number is less common for this purpose).
• A single object can have up to 25 External ID fields (for custom objects; standard objects have similar limits but some standard fields like Account.Account_Number__c can also be configured).
• Marking a field as an External ID automatically indexes the field, which improves query performance when searching or filtering on that field via SOQL or reports.
• An External ID field can optionally also be marked as Unique, which enforces that no two records on that object share the same value. Uniqueness can be configured as case-sensitive or case-insensitive.
• External IDs are heavily used with the Upsert operation to determine whether a record should be inserted or updated.

How External IDs Work with Upsert

The upsert DML operation (or the Upsert API call) uses an External ID field to decide whether to create a new record or update an existing one:

1. You specify which External ID field to match on.
2. For each record in the upsert operation, Salesforce looks for an existing record where the External ID field value matches the incoming value.
3. If a match is found, the existing record is updated.
4. If no match is found, a new record is inserted.
5. If more than one match is found (possible if the field is not marked as Unique), the operation fails with a duplicate value error for that record.

Example in Apex:

Suppose you have a custom field ERP_ID__c (Text, External ID, Unique) on the Account object.

Account acc = new Account();
acc.ERP_ID__c = 'ERP-10045';
acc.Name = 'Acme Corp';
acc.Industry = 'Technology';

upsert acc ERP_ID__c;

If an Account with ERP_ID__c = 'ERP-10045' already exists, it gets updated. If not, a new Account is created.

What Are External Relationships (External Lookup Relationships)?

Salesforce provides several types of relationship fields. An External Lookup Relationship is a relationship that links a Salesforce object (or an External Object) to an External Object. External Objects represent data stored outside Salesforce, accessed via Salesforce Connect (OData, cross-org adapters, or custom adapters).

There are three relationship types relevant to External Objects:

1. External Lookup Relationship – A relationship from a standard object, custom object, or external object to an external object. The relationship uses the external object's External ID (the standard External ID field on external objects) as the matching key. The child record stores the external ID value of the parent external object record.

2. Indirect Lookup Relationship – A relationship from an external object (child) to a standard or custom Salesforce object (parent). Instead of using the Salesforce record ID, this relationship matches the external object's field to a field on the parent Salesforce object that is marked as both External ID and Unique. This is critical because external objects do not store Salesforce IDs — they need another way to associate with Salesforce records.

3. Lookup Relationship – External objects can also have a standard lookup relationship to a parent object if the external data source contains the 18-character Salesforce ID. This is less common in practice.

Summary of Relationship Types for External Objects:

• Lookup: Uses the Salesforce 18-character ID. The child stores the parent's Salesforce ID.
• External Lookup: Parent is an external object. The child stores the parent's External ID value.
• Indirect Lookup: Child is an external object, parent is a standard/custom object. Matches on a field marked as External ID and Unique on the parent.

Why Are These Concepts Important?

1. Data Integration: External IDs are the cornerstone of data migration and integration. Without them, you would need to perform lookups by Salesforce ID, which external systems typically do not know.

2. Performance: External ID fields are automatically indexed, leading to faster SOQL queries that filter on these fields.

3. Data Integrity: When marked as Unique, External ID fields prevent duplicate records from being created during data loads.

4. Simplified Upsert Logic: The upsert operation eliminates the need for developers to write separate query-then-insert-or-update logic, reducing code complexity and governor limit consumption.

5. Salesforce Connect: External relationships (External Lookup and Indirect Lookup) enable seamless integration with data that lives outside Salesforce, allowing users to view and interact with external data as if it were native Salesforce data.

How to Use External IDs in Data Loading

When using tools like Data Loader, Data Import Wizard, or third-party ETL tools:

• You can use the upsert operation and select the External ID field as the match field.
• You can also use External IDs to set relationship fields without knowing the Salesforce ID. For example, when loading Contacts, instead of providing the parent Account's Salesforce ID, you can reference the Account's External ID field. This is called relationship resolution via External ID.

Example: Loading Contacts with a CSV:

FirstName, LastName, Account.ERP_ID__c
John, Smith, ERP-10045

The Data Loader resolves the Account relationship by looking up the Account whose ERP_ID__c = 'ERP-10045' and associates the Contact with that Account — no Salesforce ID needed.

External IDs in Apex

In Apex, you can use the upsert DML statement with an External ID field:

List<Account> accounts = new List<Account>();
// populate accounts with ERP_ID__c values
upsert accounts ERP_ID__c;

You can also set parent relationships using External IDs in Apex by instantiating the parent sObject with only the External ID field populated and assigning it to the relationship field:

Contact con = new Contact();
con.FirstName = 'Jane';
con.LastName = 'Doe';
Account parentRef = new Account(ERP_ID__c = 'ERP-10045');
con.Account = parentRef;
insert con;

Salesforce resolves the Account relationship using the ERP_ID__c value. This avoids an extra SOQL query to look up the Account's Salesforce ID.

Common Scenarios and Edge Cases

• If you upsert without specifying an External ID field, Salesforce defaults to using the record ID as the match field.
• If the External ID field is not unique and duplicate values exist, the upsert will fail for the records that match multiple existing records.
• External ID fields on standard objects are limited; not all standard objects support custom External ID fields, but most do.
• Auto-Number fields are automatically External IDs, but since they are system-generated, they are not typically used for external system matching.

Exam Tips: Answering Questions on External IDs and External Relationships

1. Know the valid field types for External IDs: Text, Number, and Email. If a question mentions a Checkbox or Picklist as an External ID, that is incorrect.

2. Understand the upsert behavior: Remember the three outcomes — update (one match), insert (no match), error (multiple matches). Exam questions frequently test this.

3. Unique vs. Non-Unique External IDs: A field can be an External ID without being Unique. However, for Indirect Lookup Relationships, the parent field must be both External ID and Unique. This distinction is commonly tested.

4. Differentiate the three relationship types for External Objects: Know when to use Lookup (Salesforce ID available), External Lookup (parent is an external object), and Indirect Lookup (child is external, parent is standard/custom). Pay attention to which object is the parent and which is the child.

5. Remember that External IDs are indexed: This makes them efficient for SOQL WHERE clauses. If a question asks about improving query performance on an integration field, marking it as an External ID is a valid approach.

6. Relationship resolution in data loading: Know that you can reference a parent record's External ID field in data load operations to establish relationships without the Salesforce ID. The syntax uses dot notation (e.g., Account.ERP_ID__c).

7. Apex syntax for upsert with External ID: Be comfortable with the syntax: upsert recordList ExternalIdField__c; The field API name is specified after the list variable.

8. Limit of 25 External ID fields per object: While rarely tested directly, knowing this limit can help eliminate wrong answers.

9. Read questions carefully for context: Questions may describe a scenario involving data migration, integration, or Salesforce Connect. Identify whether the question is about simple External ID usage (upsert/data loading) or about External Object relationships.

10. Eliminate answers that confuse External IDs with record IDs: External IDs are custom fields with values from external systems. They are NOT the Salesforce 15- or 18-character record ID, unless the external system happens to store it (which is the exception, not the rule).

11. Practice scenario-based reasoning: If a question says "A developer needs to load data from an external system and must prevent duplicates while creating parent-child relationships without querying Salesforce IDs," the correct approach combines: marking a field as External ID and Unique, using upsert with the External ID, and referencing the parent's External ID for relationship resolution.

By mastering External IDs and External Relationships, you build a strong foundation for both the Platform Developer 1 exam and real-world Salesforce development. These features reduce complexity, improve performance, and enable seamless data integration — core skills every Salesforce developer needs.