Record
A record in Salesforce is a single row of data stored inside an object.
Definition
A record in Salesforce is a single row of data stored inside an object. If an object such as Account or Contact is the table, then a record is one entry in that table, with values filling each field the object defines. One Account, one Case, one Opportunity: each of those is a record.
Every record carries a unique Salesforce ID and the field values set by your schema. Records are the working units of the platform. People create, read, edit, share, and report on them through the user interface, the APIs, and automation like flows.
How a record fits the Salesforce data model
The spreadsheet model: object, field, record
The clearest way to picture a record is a spreadsheet. Salesforce maps a familiar database structure onto three friendly words. A table becomes an object, a column becomes a field, and a row becomes a record. Trailhead teaches it exactly this way: in Salesforce CRM, you think about tables as objects, columns as fields, and rows as records. So a record is one row inside one object, holding a value for each field that object defines. Take the standard Account object. It ships with fields like Account Name, Phone, and Billing Address. Create an account for a company, and you now have one Account record whose fields hold that company's values. Add a second company and you have a second record. The structure stays identical from row to row, because every record of an object follows the same field definitions. That shared shape is what lets you list, filter, sort, and report across thousands of records at once. The object sets the schema; each record fills it in with real data.
Standard and custom objects both store records
Records live in two kinds of objects. Standard objects are the ones Salesforce builds for you, including Account, Contact, Lead, Opportunity, and Case. They cover the entities most businesses already track, so the moment you log in you can start creating records in them. Custom objects are the ones you build to hold data specific to your company or industry. A real estate org might add a Property object; a school might add a Course object. Each new custom object gets its own set of records the same way a standard object does. The distinction matters for naming, not for behavior. A record behaves the same whether its object is standard or custom. It still gets an ID, still holds field values, still respects sharing and validation. Custom object and field API names carry a __c suffix, which is how you spot them in code and integrations. Whether the row sits in Account or in your own Property object, it is a record, and the platform treats it with the same set of rules.
Every record has a unique Salesforce ID
Each record is identified by a Salesforce ID that is unique across your org. You see it in the browser address bar when you open a record, and it is how the API, formulas, and automation point to one exact row. The ID comes in two lengths. The 15-character form is case sensitive and is what you usually see in the user interface and in reports. The 18-character form is case safe, adding three characters that encode the case of the first 15. The reason both exist is practical. Some external tools, like older spreadsheet or database programs, compare text without respecting case. To them, two 15-character IDs that differ only in letter case look identical, which would collide. The 18-character ID solves that, so every API call returns the case-safe version. The guidance is simple: use the 18-character ID for integrations, data loads, and anything that compares IDs outside Salesforce. Inside the platform, either form resolves to the same record, because Salesforce always knows the difference.
Create, read, update, delete: the record lifecycle
Records support four basic operations, often shortened to CRUD: create, read, update, and delete. You can run all four from the user interface by clicking New, opening a record, editing fields, or deleting it. The same operations are available through the REST and SOAP APIs, through Apex DML statements like insert and update, and through declarative automation such as record-triggered flows. A record created by a flow is the same kind of record a person creates by hand. Reading records at scale uses SOQL, the query language that pulls back sets of records and their field values. A list view is a saved, filtered read over many records of one object. Reports and dashboards read across records to summarize them. The point is that a record is not tied to one tool. The UI, code, and automation all act on the same underlying row. That consistency is why an Opportunity created by a salesperson, by an integration, and by a flow are indistinguishable once saved. They are all just records of the Opportunity object.
Records are the unit security is applied to
Sharing in Salesforce is decided record by record, which is why record-level security is its own layer. First, object permissions on a profile or permission set decide whether a user can create, read, edit, or delete that type of record at all. Above that sits record-level access, which decides which specific records a permitted user can actually see. Salesforce controls record access through four tools, listed from most to least restrictive. Org-wide defaults set the baseline level of access to other people's records. Role hierarchies let managers reach the records their team owns. Sharing rules open up records to groups as exceptions to the baseline. Manual sharing lets a record owner grant access to one person directly. Org-wide defaults usually lock data down, and the other tools open it back up where the business needs it. A few broad permissions, such as View All and Modify All, override the hierarchy entirely. The takeaway: a record is the exact thing access rules grant or withhold, so designing data security always comes back to which records each user should touch.
Why record is the word to use
Record is not casual shorthand, it is the platform's own vocabulary, and using it keeps you aligned with every menu, doc, and feature name. The concept shows up everywhere once you notice it. Record types segment records by business process. Lightning record pages are the layouts you build for viewing one record. Record-triggered flows fire when a record is created or updated. Record-level security, covered above, governs who sees which record. Each of those feature names assumes you already mean a single row of object data. If you reach for row, entity, or document instead, you add a translation step every time you read Salesforce material, because the help articles and Trailhead modules never use those words for this. Defaulting to record removes that friction. It is also precise: a record is always one row in one object with one ID, never a vague blob of data. So in conversation, in tickets, and in design docs, calling it a record is both the correct term and the one that makes the rest of the documentation line up with what you are describing.
How to create a record in Lightning Experience
Creating a record in Lightning Experience means adding one new row to an object and filling in its fields. The same flow works for standard objects like Account and for your own custom objects. Here is the typical path from the UI.
- Open the object
From the navigation menu or the App Launcher, select the object you want, such as Accounts or Contacts. This lands you on a list view of that object's existing records.
- Click New
Select the New button, usually in the top right of the list view. If the object has record types enabled, Salesforce first asks which record type to use, which sets the page layout and picklist values.
- Fill in the fields
Enter values for the fields on the create panel. Required fields are marked with a red bar, and you cannot save until each one has a value. Lookup fields let you link this record to another, like setting a Contact's Account.
- Save the record
Click Save to create the record, or Save & New to create it and immediately start another. Salesforce assigns the new record a unique ID and opens its record page.
Most objects have a required name or number field, such as Account Name or Last Name on a Contact, that identifies the record.
Fields set as required on the layout or by a universally required field setting must be filled before the record will save.
When an object has multiple record types and you have access to more than one, you choose the record type before the field panel appears.
- You need create permission on the object through a profile or permission set, or the New button will not appear.
- Validation rules can block a save even after required fields are filled, so read the error and correct the flagged values.
- Duplicate rules may warn you or stop the save if the new record matches an existing one, depending on how the rule is configured.
Prefer this walkthrough as its own page? How to Record in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Record.
Hands-on resources to go deeper on Record.
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 Record in Salesforce data architecture?
Q2. How is a Salesforce Record uniquely identified?
Q3. What does a Record carry beyond its ID and visible field values?
Discussion
Loading discussion…