Primary Key
A primary key in Salesforce is the unique Record ID that identifies every row in every object.
Definition
A primary key in Salesforce is the unique Record ID that identifies every row in every object. The platform assigns it automatically when a record is created, and it never changes for the life of that record, even if the record is deleted and later restored from the Recycle Bin.
Every standard and custom object uses the same primary key mechanism. The Record ID lives in the read-only Id field, comes in a 15-character case-sensitive form and an 18-character case-safe form, and is globally unique across the entire org. Lookups, master-detail relationships, API calls, and reports all use this key to point at one specific record.
How the Record ID works as your primary key
One Id field, every object, assigned for you
The primary key in Salesforce is not something you design or declare. Every object, whether it ships with the platform or you build it yourself, automatically gets an Id field that holds the Record ID. Salesforce generates that value at the moment the record is created, so you never write code or set a field to populate it. The Id is read-only. You cannot edit it in the UI, set it on insert through the API, or change it later. This is a deliberate contrast with traditional databases, where a developer chooses a primary key column and sometimes manages sequences or auto-increment counters. Here the responsibility moves to the platform, which guarantees a unique value with no effort from you. Because the rule is identical across Accounts, Contacts, custom objects, and everything else, you can rely on one consistent identity model for the whole org. When you query records with SOQL, the Id comes back even if you do not list it. When you view a record in Lightning Experience, the Id sits in the browser address bar, for example the 5003000000D8cuIQAA inside a Case URL.
15 characters, 18 characters, and why both exist
A Record ID has two forms that point at the same record. The 15-character form is the original, and it is case-sensitive. To Salesforce, 000000000000Abc is not the same record as 000000000000aBC, because the casing of each letter carries meaning. That precision causes trouble in systems that treat text without regard to case. Microsoft Access and some spreadsheets would wrongly merge two distinct records that differ only by letter case. To solve this, Salesforce created the 18-character form. It is the same 15 characters with three extra characters appended that encode the casing of the first 15. The 18-character ID is case-safe, so any system can compare it as plain text and still get the right answer. The API returns 18 characters by default and gives no option for the 15-character form. The Reports tool queries the database directly, so it can surface a 15-character value. Both forms resolve to the same record inside Salesforce, but for any external comparison the 18-character form is the safe choice.
The key prefix tells you the object type
The first three characters of every Record ID are called the key prefix, and they identify which object the record belongs to. A User record such as 00561000000Mjya starts with 005, which is the prefix for the User object. A Case starts with 500. Standard objects have fixed, well-known prefixes that stay the same across every org, while custom objects get their own prefix assigned when you create them. This design means you can often recognize the type of a record just by glancing at the first three characters of its ID. In Apex you do not have to memorize prefixes. Calling getSObjectType() on an Id variable returns the object type directly. If you need to map a prefix to a name programmatically, Schema.getGlobalDescribe() lets you loop through every sObject type and match on its key prefix. The prefix is part of what makes the Record ID a true primary key: it is not just unique within one object, it is unique across the entire org, because the prefix plus the rest of the string never collides between object types.
How primary keys power relationships
A primary key is only half of the relational story. The other half is the foreign key, the value that one record stores to point at another. In Salesforce, lookup and master-detail relationship fields hold the Record ID of the related record. When you set the Account on a Contact, the Contact stores the Account's Record ID in its AccountId field. That stored ID is a foreign key, and the Account's own Id is the primary key it refers to. This is how the platform joins data without you writing JOIN statements by hand. Reports follow these relationships to combine parent and child rows. SOQL parent-to-child and child-to-parent queries walk the same links. External objects that connect to outside systems use the 18-character Record ID to associate related rows. Because every relationship resolves to a primary key, the integrity of your data model depends on those IDs staying stable. Salesforce protects that stability by making the Id immutable. A foreign key can never break simply because a parent record's identity shifted, since identities here do not shift.
Using IDs in integrations and data loads
When you connect Salesforce to another system, the Record ID becomes the anchor that keeps both sides in sync. A common pattern is to store the Salesforce 18-character ID on the matching record in the external system, then use it to update the right Salesforce record later. Always carry the 18-character form across system boundaries. Many external databases and middleware tools compare text without case sensitivity, and a 15-character ID can silently match the wrong record there. Data Loader and similar tools accept either length for matching on the Id field, but the 18-character form removes ambiguity. A subtle point: the Record ID is unique within one org, not across orgs. The same record migrated to a sandbox or another production org gets a brand new ID. If you build integrations that span environments, do not assume an ID means the same thing everywhere. For cross-system matching that must survive a migration, many teams add an External ID field with their own stable key, and use the Salesforce Record ID only for in-org operations.
What stays true about the Record ID
A few properties hold for every Record ID, and they are worth committing to memory. The value is generated by the platform, never by you. It is immutable, so once a record exists its ID is fixed for as long as the record or its Recycle Bin entry survives, and even an undelete returns the same ID. It is read-only, so no UI action or API write can change it. It is globally unique within the org, thanks to the key prefix plus the rest of the string. It comes in a case-sensitive 15-character form and a case-safe 18-character form that both point at the same record. Treat the Record ID as the canonical reference for a record in any tooling, automation, or integration you build. Do not try to invent your own primary keys for standard data when the platform already gives you a guaranteed-unique one. And when you hand an ID to something outside Salesforce, reach for the 18-character form by default. These habits prevent a whole class of duplicate-record and mismatch bugs that are painful to diagnose after the fact.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Primary Key.
Hands-on resources to go deeper on Primary Key.
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 the Primary Key in Salesforce?
Q2. What are the two ID formats?
Q3. Are Record IDs immutable?
Discussion
Loading discussion…