Object-Level Security
Object-Level Security in Salesforce is the access control layer that determines whether a user can read, create, edit, or delete records of a specific object.
Definition
Object-Level Security in Salesforce is the access control layer that determines whether a user can read, create, edit, or delete records of a specific object. The platform enforces object permissions through profiles and permission sets: each profile or permission set declares per-object permissions (Read, Create, Edit, Delete, View All, Modify All). A user's effective object permissions are the most permissive grant across their profile and assigned permission sets. Without the appropriate object permission, the user cannot access any record of that object regardless of sharing rules or record-level access.
Object-Level Security is the broadest access control layer, sitting above Field-Level Security (which restricts specific fields) and Record-Level Security / Sharing (which restricts specific records). All three layers must permit access for the user to interact with a specific field on a specific record. Confusing these layers produces frequent misconfiguration: granting record sharing without object access produces nothing; granting object access without field access shows the record but blank fields. Understanding the layering is foundational to Salesforce security administration.
How Object-Level Security works
The CRUD model
Object permissions follow the CRUD acronym: Create (insert new records), Read (view existing records), Update (edit existing records), Delete (remove records). Salesforce uses CREd in the UI (Create, Read, Edit, Delete) with the same meaning. Each is independent: a user might have Read on Account but not Edit. Edit implies Read; Delete implies Edit; you cannot have higher permission without the lower.
View All and Modify All
Beyond the basic CRUD, View All and Modify All are object-level overrides. View All ignores sharing rules and lets the user see every record of the object. Modify All extends to edit and delete every record. These are powerful permissions; assign sparingly. View All is common for reporting roles needing org-wide visibility; Modify All is typically only system administrators.
Profile versus Permission Set
Profiles declare baseline object permissions (and historically were the only mechanism). Permission Sets add additive grants on top. A user with profile granting Read and a permission set granting Edit has effective Edit. Modern best practice: minimal profiles, additive permission sets for specific access needs. Permission sets are easier to manage than profile sprawl.
Standard versus custom objects
All standard objects have object permissions. Custom objects also have object permissions, configurable identically. New custom objects start with no permissions granted; admins must explicitly add permissions through profiles or permission sets to enable access. The default-no-access for new custom objects is a safety mechanism.
Interaction with sharing
Object permissions are necessary but not sufficient. Read on Account lets the user know Accounts exist; sharing determines which specific Accounts they see. The org-wide default (OWD) plus sharing rules and manual sharing combine to grant record access. Without object Read, no sharing grant helps; without sharing, object Read shows nothing.
Interaction with FLS
Object Read lets the user see records; FLS determines which fields appear within those records. A user with Read on Account but no FLS on AnnualRevenue sees the Account but blank AnnualRevenue. The layered model means a single user access bug can be at the object, sharing, or FLS layer; Field Accessibility surfaces the effective combined access.
Apex and the "without sharing" keyword
Apex code typically runs in the calling user's context, respecting object permissions and sharing. Code marked "without sharing" bypasses sharing but still respects object and FLS permissions in many contexts (depending on how the code accesses data). Apex code that bypasses CRUD/FLS explicitly (System.runAs, certain dynamic SOQL patterns) requires careful review for security implications.
Configure object permissions
Configuring Object-Level Security involves declaring permissions per profile and per permission set, then validating the effective access. The steps below cover the standard workflow.
- Identify the object and user population
Determine which users need access to which objects with what level. Document the matrix before configuring.
- Edit the profile
Setup > Profiles > select profile > Object Settings. For each object, set the CRUD permissions and View All/Modify All if needed.
- Create permission sets for variants
For access needs that vary among users with the same profile, create permission sets. Assign to specific users.
- Test with a sample user
Login As. Confirm the user can access the object as expected. Test create, edit, delete operations to verify CRUD permissions.
- Cross-check sharing
Object access shows records exist; sharing determines specific record visibility. Confirm sharing rules align with object access intent.
- Document the matrix
Maintain a documented profile/permission set matrix showing object access per user population. Future admins will need this.
- Audit quarterly
Review permissions periodically. View All and Modify All assignments are particularly worth verifying; over-assignment is a security risk.
View existing records. The baseline access permission.
Insert new records.
Update existing records. Implies Read.
Remove records. Implies Edit.
Override sharing to see/edit all records of the object.
- Object access without sharing shows no records. The user knows the object exists but sees an empty list view.
- Modify All bypasses sharing entirely for that object. Sensitive permission; audit assignments.
- New custom objects default to no access. Admins must explicitly add permissions; the default is intentional safety.
- Permission sets are additive. A user gets the most permissive grant across their profile and all permission sets.
- Apex "without sharing" still typically respects CRUD and FLS. The bypass is specifically for record sharing, not all security layers.
Trust & references
Straight from the source - Salesforce's reference material on Object-Level Security.
- Set Field Permissions in Permission Sets and ProfilesSalesforce Help
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 Object-Level Security?
Q2. What are the three Salesforce security layers?
Q3. What's the relationship to sharing?
Discussion
Loading discussion…