ID
An ID in Salesforce is the platform's unique identifier for every record, sObject, metadata component, and configuration item.
Definition
An ID in Salesforce is the platform's unique identifier for every record, sObject, metadata component, and configuration item. Each ID is a string in one of two formats: 15-character case-sensitive or 18-character case-insensitive, with the 18-character version including a 3-character checksum that makes the ID safe to handle in case-insensitive systems like Excel and certain database tools. The first three characters of the ID identify the sObject type: 001 for Account, 003 for Contact, 006 for Opportunity, 500 for Case, and a unique prefix per object including custom objects.
Every API call, SOQL query result, and URL path uses IDs. They appear in the record URL, in lookup fields, in EmailMessage relationships, in audit trails. Understanding the ID format saves countless debugging hours: when an integration fails because an ID was truncated, when a CSV import lookup fails because of case sensitivity, when an admin needs to query "all records of type X" using the prefix filter. IDs are the platform's connective tissue, and fluency with their structure is one of the markers of an experienced Salesforce practitioner.
The anatomy of a Salesforce ID
15 versus 18 character format
The 15-character ID is the platform's native format: case-sensitive. Two records can have IDs differing only in case (one ending in "Aa" and another in "AA" are distinct). The 18-character ID extends this with a 3-character checksum suffix, making the ID safe to handle in case-insensitive systems. Both formats refer to the same record; passing either to an API call works. APIs return 18-character IDs by default; SOQL Id fields are exposed as 18-character.
The 3-character object prefix
The first three characters of an ID identify the sObject type. 001 = Account, 003 = Contact, 005 = User, 006 = Opportunity, 500 = Case, 00Q = Lead, 701 = Campaign. Custom objects get their own prefix like a02, a03, etc., assigned when the object is created. The prefix is the same across all orgs for standard objects, so 001 always means Account. Knowing the prefix lets you identify what type of record an ID refers to without querying.
ID stability and reassignment
Once assigned to a record, an ID is permanent. Deleting a record does not free up its ID; the ID remains in the recycle bin and in audit trails. Even after permanent deletion, the same ID will never be reused; the platform generates new IDs without recycling. This stability matters for integrations: an external system storing Salesforce IDs can trust them as durable references even across record deletion and re-creation.
Querying with the prefix
The 3-character prefix lets you query all records of a type without specifying the object name. SELECT Id FROM <any sobject> WHERE Id LIKE '001%' returns all Account records. This is occasionally useful for cross-object debugging, though in practice using the object name (SELECT Id FROM Account) is clearer.
Converting between 15 and 18
The conversion from 15 to 18 characters is deterministic: a checksum algorithm produces the 3-character suffix. Excel formulas exist for this conversion (the standard Salesforce-supplied formula uses MID and CHOOSE). Going the other way is trivial: drop the last 3 characters. Most modern Salesforce tools handle the conversion automatically; awareness matters mainly when working with legacy data sources or building custom integrations.
Salesforce IDs in URLs
Record URLs follow the pattern instance.salesforce.com/<recordId>. The platform accepts both 15 and 18 character IDs in URLs; both resolve to the same record. URL shortening or bookmarking can lose the ID; ensure full IDs are preserved when sharing record links. The Lightning Experience URL structure also includes object name and view: /lightning/r/Account/<id>/view, which is more verbose but more navigable.
Common ID-related bugs
Two ID-related bugs dominate support tickets. First, case-sensitivity: a CSV-driven integration that lowercases IDs may produce match failures. Always store IDs in 18-character format if the downstream system is not case-sensitive. Second, truncation: copying IDs through email clients or chat tools sometimes drops trailing characters. The 18-character format includes the checksum which makes truncation detectable; the 15-character format does not.
Work with Salesforce IDs effectively
Working with Salesforce IDs is mostly a debugging skill rather than a configuration task. The steps below cover the common scenarios where understanding ID structure matters.
- Identify the object type from an ID
Take the first three characters of the ID. Match against the prefix list (001 = Account, 003 = Contact, etc.) or query Schema.SObjectType in Apex with the prefix.
- Convert 15 to 18 character ID
Use the standard Excel formula or the Apex Id.toString() method. APIs already return 18-character IDs; this is mostly for legacy data sources.
- Query records by ID
SOQL: SELECT Fields FROM Object WHERE Id = '<id>'. Both 15 and 18 character IDs work. Bulk: WHERE Id IN ('id1', 'id2', ...).
- Audit ID handling in integrations
For any integration touching IDs, confirm 18-character format is used. CSV files and Excel sheets especially need 18-character IDs to avoid case-sensitivity bugs.
- Trace ID through audit logs
Setup Audit Trail, EmailMessage, and most history objects reference records by ID. Use the ID to trace a record's lifecycle across audit data.
- Find records when only partial ID is known
Use the prefix filter: SELECT Id FROM <object> WHERE Id LIKE '<prefix>%'. Useful when an ID was truncated and you need to find the full one.
- Document custom object prefixes
Maintain a quick-reference doc mapping custom object prefixes to object names. New admins inheriting the org will appreciate the cheat sheet.
Native case-sensitive format. The platform's internal representation.
15-character with 3-character checksum suffix. Safe for case-insensitive systems.
First 3 characters identifying the sObject type. Stable across orgs for standard objects.
Custom field marked as External ID. Separate matching key for integration scenarios; not a Salesforce ID.
Strongly typed Id class in Apex. Conversions to/from String supported through valueOf() and toString().
- 15-character IDs are case-sensitive. Storing them in case-insensitive systems (Excel, some databases) produces silent match failures. Always use 18-character for those systems.
- URL truncation through email or chat can drop trailing characters. The 18-character format includes a checksum which lets you detect truncation; 15-character does not.
- IDs are not reusable. Deleting a record does not free its ID for future use; the ID stays in audit trails forever.
- The 3-character prefix is per-object but the same across orgs for standard objects. Custom object prefixes are stable within an org but may differ between orgs.
- Apex Id type is strict. Passing a String where Id is expected produces a compile error; always use valueOf() to convert explicitly.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Salesforce ID?
Q2. What are the two ID formats?
Q3. What do the first three characters of an ID indicate?
Discussion
Loading discussion…