Salesforce Record ID
A Salesforce Record ID is the system-generated unique identifier that the platform assigns to every record the moment it is created.
Definition
A Salesforce Record ID is the system-generated unique identifier that the platform assigns to every record the moment it is created. It comes in two forms: a 15-character case-sensitive version and an 18-character case-insensitive version that appends a 3-character checksum. The ID is the primary key Salesforce uses to find, query, relate, and link records across the database.
Record IDs are immutable. Once assigned, an ID stays with that record for life and is never reused, even if the record is deleted and later restored from the Recycle Bin. The first three characters, called the key prefix, identify which object the record belongs to, so 001 always means Account and 003 always means Contact.
How Record IDs Work Under the Hood
15-character versus 18-character IDs
Every Salesforce record has a 15-character ID and an equivalent 18-character ID that point to the exact same row. The 15-character form is case-sensitive, which means a0Bd0000001abCD and a0Bd0000001aBcd are two different IDs. That distinction matters inside Salesforce, where uniqueness depends on case. It causes trouble outside Salesforce, because many systems (Excel, some databases, certain file formats) treat text as case-insensitive and would collapse those two IDs into one. The 18-character form solves that. It takes the original 15 characters and adds a 3-character suffix that encodes the capitalization of the first 15. A case-insensitive system can read all 18 characters and still tell the records apart, because the suffix preserves the casing information. All Salesforce API calls return 18-character IDs by default. The two forms are interchangeable as input: when you pass a 15-character ID to the API or to Apex, the platform accepts it and works correctly.
The key prefix and what it tells you
The first three characters of any Record ID are the key prefix, and they identify the object the record lives on. Salesforce documents this in the Entity Key Prefix Decoder. Standard objects share the same prefix in every org, so you can recognize them on sight. Account is 001, Contact is 003, User is 005, Opportunity is 006, Lead is 00Q, and Case is 500. This is genuinely useful in day-to-day work. If a log or an error message hands you a bare ID like 006Hp00001abcXYZ, the 006 tells you it is an Opportunity before you ever query it. Custom objects also get a prefix, usually starting with a0 or a higher letter, but those prefixes are assigned per org and are not guaranteed to match between a sandbox and production. So treat standard prefixes as fixed knowledge and look up custom ones with a quick describe call or by checking a known record. Never hard-code a custom-object prefix that you assumed would be stable across environments.
Why IDs are the backbone of relationships
Record IDs are how Salesforce stitches data together. A lookup or master-detail field does not store the related record name. It stores that record ID. When a Contact points to its Account, the AccountId field on the Contact holds the parent Account ID, and Salesforce resolves the name for display. Every relationship in the platform works this way, which is why an ID is described as the primary key for the object. This has practical consequences. When you migrate data, you cannot just match records by name, because names are not unique and can change. You match on IDs, or on an External ID field that maps your old system keys to Salesforce records. URLs also embed the ID: a record page reads like /lightning/r/Account/001Hp00001abcXYZ/view, and the ID in that path is what loads the record. Reports, list view filters, formula fields, and SOQL queries all reference records through this same identifier, so a solid grasp of IDs underpins almost everything else.
Where Record IDs come from and finding them
You never create a Record ID yourself. Salesforce generates it during insert, and there is no supported way to set or override it. That is by design, because the platform guarantees global uniqueness and immutability, and manual IDs would break both promises. Finding an existing ID is easy once you know where to look. The simplest method is the browser address bar: open any record and the ID sits in the URL after the object name. You can also add the record ID as a column to a report, since most objects expose an ID field for reporting. A third option is a formula field of type Text that returns the ID, which then shows on the detail page and in list views. For bulk work, exports from Data Loader and the Weekly Data Export both return 18-character IDs, which makes them safe to drop into spreadsheets. If you already have a 15-character ID and need the 18-character version, the CASESAFEID formula function converts it.
Record IDs in Apex and the API
In Apex, Id is a primitive data type, not just a String. Declaring a variable as Id means Apex validates the value as a real 15 or 18 character Salesforce ID and rejects malformed input at assignment. That validation is a small but real safety net compared to passing raw strings around. You can call getSObjectType() on an Id to learn which object it belongs to at runtime, which is handy in generic code that handles records of many types. Across the API layer, IDs are equally central. SOQL queries return the Id field whether or not you ask for it on a single-object query, and you filter and bind by Id constantly. The Bulk API, REST API, and SOAP API all return 18-character IDs. When you build an integration that stores Salesforce IDs in an external database, always persist the 18-character form. External systems that lowercase or uppercase text will corrupt a 15-character ID and silently point at the wrong record, or at no record at all.
Common mistakes and how to avoid them
The most frequent ID bug is the 15-versus-18 mismatch. A spreadsheet stores 15-character IDs, someone sorts or de-dupes case-insensitively, and two distinct records merge into one. The fix is to standardize on 18-character IDs everywhere data leaves Salesforce. Always export and store the 18-character form, and convert any 15-character IDs you receive. A second mistake is assuming a custom-object prefix is portable. Prefixes for custom objects are assigned per org, so code that branches on a hard-coded a0X prefix can break after a deployment or in a new sandbox. Look the prefix up at runtime instead. A third trap is treating an ID as a meaningful business key in front of users. IDs are stable and unique, which is exactly why they make great join keys, but they are opaque strings, so people should match on readable fields and let the system handle IDs behind the scenes. Finally, remember that IDs are never recycled, so an ID you saw last year still refers to the same record (or to a deleted one), never to something new.
Trust & references
Cross-checked against the following references.
- CASESAFEID Formula FunctionSalesforce
- Locate the Unique ID of a Record in SalesforceSalesforce
Straight from the source - Salesforce's reference material on Salesforce Record ID.
- Salesforce Entity Key Prefix DecoderSalesforce
- Id Class, Apex Reference GuideSalesforce
Hands-on resources to go deeper on Salesforce Record ID.
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 Record ID?
Q2. Why use 18-character IDs?
Q3. What do the first 3 characters indicate?
Discussion
Loading discussion…