Object-Level Security in Salesforce: Control Create, Read, Edit and Delete

Hey friends,

Object-level security decides which objects a user can reach and what they can do with the records of each one: read, create, edit and delete, plus the wider View All Records and Modify All Records. You set it with object permissions, which Salesforce recommends managing in permission sets and permission set groups, and you check who has access to an object from the Object Access page in Object Manager. That is how Salesforce's Help page Object Permissions and the Trailhead unit Manage Salesforce Object Access describe it. I read both on October 28, 2026, and I mark my own opinions as mine.

I tested the steps in a Developer Edition org on that date, using the Contact object and a permission set I named Demo Read-Only. I did not log in as a restricted user, so I can't show you what a user without access sees. The checks below read the settings instead. This post is about whole objects. Its companion, my field-level security post, covers who can see each field inside an object.

What object-level security controls

Help says object permissions specify the base-level access users have to create, read, edit and delete records for each object. Trailhead calls it the simplest way to control data access: an object is a collection of records, like leads or contacts, and you decide whether a user can create, read, edit or delete any records of that type.

It is the first of three levels Trailhead describes: objects first, then fields, then individual records. This post covers the first. My take: set the object permission as small as the job allows, then tighten fields and records after.

The object permissions

Help lists seven object permissions. The first four build on each other, and the last three are the broad ones:

The Sharing column is Help's own: Read, Create, Edit and Delete respect the sharing rules and settings, and View All Records and Modify All Records override them. Which records a user can see is a separate layer, covered with roles and sharing in my security model post.

How to set object permissions in a permission set

Help recommends permission sets and permission set groups for managing your users' permissions, because you can reuse smaller building blocks instead of creating dozens or hundreds of profiles. If they are new to you, my permission sets post explains them. These are Trailhead's steps for adding object permissions to a permission set:

1. From Setup, enter Permission Sets in the Quick Find box, then select Permission Sets. Click New to make one, or open an existing one.
2. In the Find Settings box, search for the object you want and select it.
3. Click Edit.
4. Under Object Permissions, enable the permissions you need. Trailhead's example turns on Read, Create and Edit for a custom object.
5. Click Save.

Trailhead says you can assign a permission set directly to users, but its advice is to put the permission set in a permission set group first. A group stands for a persona, like a Sales Rep, and users in it get everything in its permission sets.

I opened my Demo Read-Only permission set, went to the Contacts settings and clicked Edit. Before my change every box in Object Permissions was empty. Here is the edit page with Read ticked:

Setup > Permission Sets > Demo Read-Only > Object Settings > Contacts > Edit: Object Permissions.

1. Read. I ticked only Read, so anyone given this permission set can view Contact records and nothing more. Create, Edit, Delete, View All Records, Modify All Records and View All Fields stay empty.
2. After I clicked Save, the page showed Read as enabled in view mode, with the other six still off.

How to check who has access to an object

After a few permission sets it gets hard to remember who has what. Trailhead gives a way to review it: in Setup go to Object Manager, select an object that supports object permissions, and click Object Access in the sidebar. The page lists the permission sets, permission set groups and profiles that grant access to the object, and the level of access granted. Help adds that you can edit object access there for custom permission sets and custom profiles. I did not edit anything from that page.

Here is the page for Contact in my org:

Setup > Object Manager > Contact > Object Access: who gets access to Contact.

1. The three tabs. Permission Sets, Permission Set Groups and Profiles each list one way access reaches the object. In my org they showed 34, 0 and 30. The columns are the seven permissions from the table above.
2. The Demo Read-Only row. A tick under Read and crosses under all the others. That matches the permission set I just changed.

On the Profiles tab, the Custom: Support Profile row in my org had ticks under Read, Create, Edit and Delete and crosses under View All Records, Modify All Records and View All Fields. Trailhead says a permission is only taken away when you remove it from the base profile and from every permission set, so a profile row like this one is worth checking.

Two more places show access. Trailhead says that from Users you can open a user and click View Summary to see all object, field and user permissions they have and how each is granted. You can also click View Summary on a permission set or permission set group to see what it includes.

Where profiles fit

Trailhead explains the split like this. A profile sets a user's defaults, such as assigned apps, record types and page layouts, and every user has one profile. Permission sets add object, field and user permissions on top, and a user can have many. For object access, Trailhead says the recommended route is permission sets and permission set groups, though you can also set object permissions in profiles.

• Standard profiles. Trailhead says you can't edit the object permissions on a standard profile, but you can clone a profile and adjust the clone.
• The Minimum Access - Salesforce profile. Trailhead recommends using it (or a clone) whenever possible, then granting only the needed permissions with permission sets and groups.
• Taking a permission away. Trailhead says you must remove it from the user's base profile and from any permission sets, or use a muting permission set if the user is in a permission set group.

View All Records and Modify All Records: use with care

These two override sharing for one object. Help's View All and Modify All overview says they are used by users who manage records for specific objects, and that they can be better alternatives to the org-wide View All Data and Modify All Data permissions. Those two are for managing all data in an organization, such as data cleansing, deduplication, mass deletion, mass transferring and approving records, and Help describes the people who need them as administrators of an entire organization.

Trailhead adds that View All Data and Modify All Data override all other sharing settings, so you should use caution assigning them to any profile other than System Administrator. If someone only needs metadata for deployments, Help points to the Modify Metadata Through Metadata API Functions permission, which gives the access without providing access to org data.

Help also has a note for master-detail relationships. If a child object has permissions the parent must have, a broken permission dependency exists. Salesforce fixes it on the first save for updates made in Setup, but for updates made with the API you have to fix the dependencies yourself.

Object-level security vs field-level security

Trailhead says field-level security comes after object-level access, so start here and then go to my field-level security post.

Mistakes to avoid

• Using Modify All Records when Edit is enough. Help says Modify All Records overrides sharing, while Edit respects it.
• Editing a standard profile. Trailhead says you can't change its object permissions. Clone it instead.
• Removing a permission in one place only. Trailhead says to remove it from the base profile and from any permission sets, so check both.
• Not looking at the whole picture. Use Object Access or a user's View Summary after you change something, as in my Custom: Support Profile example above.

FAQ

What is object-level security in Salesforce?

It is the base-level access users have to create, read, edit and delete records for each object, set with object permissions.

What are the object permissions in Salesforce?

Help lists Read, Create, Edit, Delete, View All Records, Modify All Records and View All Fields.

What is the difference between Edit and Modify All Records?

Edit lets users read and update records and respects sharing. Modify All Records lets them read, edit, delete, transfer and approve all records of the object regardless of sharing settings.

Where do I set object permissions?

In a permission set or profile, from the object's settings page. Salesforce recommends permission sets and permission set groups.

How do I see which permission sets and profiles give access to an object?

In Setup, open Object Manager, select the object and click Object Access.

Can I edit the object permissions on a standard profile?

No. Trailhead says you can't, but you can clone the profile and change the clone.

What is the difference between object-level and field-level security?

Object-level security controls what users can do with records of an object. Field-level security controls whether they can see and edit a particular field in it.

Where to go next

• Field-level security in Salesforce: the field layer that comes after this one.
• Salesforce security model explained: profiles, permission sets, roles and sharing in one place.
• Salesforce permission sets and permission set groups: how to reuse the building blocks.
• Administrator certification study guide: security is one of the exam's topics.
• Salesforce Admin certification: cost, exam format and study plan.
• Is the Admin certification worth it?: how to decide.
• Salesforce certification: how it works: where the exams fit.
• To practice security questions for free, try the free Admin Cert Lab.

Hope this helps!

Best,

Nick