Object-Level Security
Object-Level Security in Salesforce is the access control layer that decides whether a user can read, create, edit, or delete records of a specific object such as Account, Case, or a custom object.
Definition
Object-Level Security in Salesforce is the access control layer that decides whether a user can read, create, edit, or delete records of a specific object such as Account, Case, or a custom object. The platform checks object permissions first, before it ever looks at sharing or fields. If a user has no object access, every record of that type is invisible to them, no matter how generous the sharing rules are.
Object permissions are declared on profiles and permission sets, and a user's effective access is the most permissive grant across the one profile and all assigned permission sets. This layer sits above Field-Level Security (which controls individual fields) and Record-Level Security (which controls which specific records a user sees). All three must allow access for a user to work with a given field on a given record, so knowing where each layer applies is the foundation of Salesforce security administration.
Where object permissions live and how they combine
The seven object permissions
Salesforce defines seven object permissions, and the official wording is precise. Read lets users view records of the object. Create lets users read and create. Edit lets users read and update. Delete lets users read, edit, and delete. The four build on each other, so Edit always includes Read and Delete always includes Edit. You cannot grant a higher permission without the ones beneath it. Three more permissions go further. View All Records lets a user see every record of the object regardless of sharing settings. Modify All Records lets a user read, edit, delete, transfer, and approve every record, again ignoring sharing. View All Fields lets a user see all fields and field data on the object regardless of field permissions, as long as they have at least Read on the object. The first four respect sharing; View All and Modify All override it. Treat the override permissions as high-risk grants and hand them out only when a role genuinely needs org-wide reach, such as a reporting analyst (View All) or a small admin group (Modify All).
Profiles and permission sets as the source
Object permissions are set in two places: profiles and permission sets. Every user has exactly one profile and can hold many permission sets, plus permission set groups that bundle several sets together. The grants are additive. If a profile gives Read on Opportunity and an assigned permission set gives Edit, the user ends up with Edit. Nothing in a permission set can take access away that a profile granted, which is why removing access usually means editing the profile or the org-wide model rather than the permission set. Salesforce now recommends permission sets and permission set groups as the primary way to manage object and field permissions, with profiles kept minimal. The reason is maintenance. A handful of focused permission sets ("Case Worker", "Quote Editor") can be mixed and matched across many users, while profile-based access tends to multiply into dozens of near-duplicate profiles. The additive model also makes auditing cleaner, because you can read a user's access as a base profile plus a short list of named grants.
Standard objects versus custom objects
Every standard object, including Account, Contact, Lead, Opportunity, and Case, ships with object permissions you can configure. Custom objects work the same way once created, with the identical Read, Create, Edit, Delete, View All, and Modify All settings exposed on profiles and permission sets. The important difference is the starting point. A brand new custom object grants no access to anyone except users with Modify All Data or the object's Modify All permission. Until an admin explicitly adds permissions through a profile or permission set, regular users will not even see the object's tab, list views, or records. This default-no-access behavior is a safety feature, not a bug. It prevents freshly built objects from leaking data before the team has decided who should reach them. A common rollout mistake is building a custom object, loading data, and then wondering why end users report a blank app. The fix is almost always a missing object permission on the relevant permission set rather than anything to do with sharing.
How object access combines with sharing
Object permissions and record sharing answer two different questions. Object Read answers "can this user interact with records of this type at all?" Sharing answers "which specific records can they see?" Both have to say yes. Read on Account tells the system the user may work with Accounts, but the organization-wide default, role hierarchy, sharing rules, and manual shares decide which Accounts actually appear. The two layers fail independently, and that trips people up. Grant a wide-open sharing rule but forget object Read, and the user sees nothing, because the gate above sharing is still closed. Grant object Read but leave the org-wide default at Private with no sharing rule, and the user sees only records they own. Neither situation throws an obvious error, so access bugs often hide here. View All Records is the deliberate exception: it bolts onto the object layer and bypasses sharing entirely, which is why it is so convenient for reporting and so dangerous when assigned by accident.
How object access combines with field-level security
Once a user can open a record, Field-Level Security (FLS) decides which fields inside it are visible or editable. Object Read and FLS are separate switches. A user with Read on Account but no field access to AnnualRevenue will open the Account and see a blank where that number should be. Flip it around and a hidden field stays hidden everywhere, including reports, list views, search results, and the API, because FLS is enforced at the data layer rather than just the page. This layering is powerful but easy to misread when troubleshooting. A single "I can't see this" report could be an object problem, a sharing problem, or an FLS problem, and they look similar to the end user. Salesforce provides Field Accessibility (under object management settings) to show the combined, effective result of object permissions plus FLS plus page layout for a given field and profile. Reaching for that view first saves a lot of guesswork, since it tells you which layer is actually blocking the field instead of leaving you to test each one by hand.
Object permissions in Apex and the API
Object-level security is not just a UI concept. The API and Apex respect it too, though the rules deserve attention. Apex now runs database operations in user mode in many modern contexts, which means object permissions and FLS are checked automatically. The with sharing and without sharing keywords only control record sharing, not object or field access, so a class declared without sharing still does not get a free pass on CRUD. To enforce object and field permissions in code on purpose, Salesforce offers several tools. The WITH USER_MODE clause and the AccessLevel.USER_MODE parameter on Database methods run a query or DML as the user, honoring CRUD and FLS. WITH SECURITY_ENFORCED checks read access on the fields in an SOQL query and throws if one is inaccessible. Security.stripInaccessible removes fields and objects the user cannot access, letting code degrade gracefully instead of failing. Code that explicitly bypasses these checks, often through system-mode operations, needs a security review, because skipping object permissions in code is a classic source of data exposure.
Where object security fits in the wider model
It helps to picture the data security model as a stack of gates a request passes through. Org-level controls (login hours, IP ranges, MFA) decide whether the user gets into Salesforce at all. Object-Level Security decides which types of records they may touch. Record-Level Security decides which specific records of those types they see. Field-Level Security decides which pieces of each record are visible or editable. A request has to clear every gate in turn. Object-Level Security is the broadest of the data gates, which makes it the cheapest place to lock something down and the easiest place to accidentally lock it open. Removing object access shuts off an entire object in one move, while adding it can quietly expose a lot of records if sharing is also permissive. Because of that reach, object permissions belong in any security review and any data audit. They are usually the first thing to check when a user reports either too much access or none at all, since the answer often sits at this top layer rather than deeper in sharing.
How to grant object permissions on a permission set
Object permissions are granted on a profile or, preferably, a permission set. Here is the modern point-and-click flow for granting object access on a permission set and assigning it to a user, so you add access without editing the user's profile.
- Open or create the permission set
In Setup, go to Permission Sets, then open an existing set or click New to create one. Give it a clear, role-based label such as Case Worker so its purpose is obvious to the next admin.
- Go to Object Settings
Inside the permission set, click Object Settings (or Assigned Apps then Object Settings). This page lists every object the permission set can grant access to, with the current permission level beside each one.
- Select the object and edit permissions
Click the object you want to grant, for example Case, then click Edit. Tick the object permissions the role needs, such as Read, Create, and Edit, and only add View All or Modify All when org-wide reach is truly required.
- Save the permission set changes
Click Save. Salesforce stores the object permissions on the permission set immediately, but no user has them yet until the set is assigned.
- Assign the permission set to users
From the permission set, click Manage Assignments then Add Assignments, pick the users, and save. Their effective object access now includes these grants on top of whatever their profile already allowed.
Lets the user view records of the object. The minimum required for the object to appear in the UI and API.
Layered write permissions; each includes the ones below it, so Delete implies Edit and Read.
Grants visibility of every record of the object regardless of sharing. Use for reporting or admin-style roles only.
Grants read, edit, delete, transfer, and approve on every record regardless of sharing. Treat as a near-admin privilege.
- Permission sets are additive only. To take access away you must edit the profile or the org-wide model, not the permission set.
- View All and Modify All ignore sharing rules. Granting them by accident can expose every record of the object at once.
- A new custom object grants no access until you add object permissions; a blank app for users is usually this, not a sharing problem.
- Object Read alone is not enough to see records. The org-wide default and sharing rules still decide which specific records appear.
Prefer this walkthrough as its own page? How to Object-Level Security in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Object PermissionsSalesforce
- Control Who Sees What (Salesforce Security Guide)Salesforce
Straight from the source - Salesforce's reference material on Object-Level Security.
- Object PermissionsSalesforce
- Enforce Object and Field Permissions (Apex Developer Guide)Salesforce
Hands-on resources to go deeper on Object-Level Security.
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. Through which mechanisms does Object-Level Security grant a user permission to read or edit an object?
Q2. How is a user's effective Object-Level Security calculated across profile and permission sets?
Q3. Where does Object-Level Security sit relative to the other Salesforce access layers?
Discussion
Loading discussion…