Create, Read, Edit, Delete
เนื้อหานี้ยังไม่มีในภาษาของคุณ
Module 1 of 6 in the chapter Object and Field Security: What Users Can Touch, chapter 4 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.
The question this module answers: What does each object permission let a user do, which ones respect sharing and which override it, and how do you choose them for a set of users?
Here’s the question for this chapter. You’ve let someone in the front door, and you’ve given them a profile and their permission sets. Now they walk down the hall. Which offices can they go into, and what can they touch once they’re inside?
Offices, not file cabinets
Section titled “Offices, not file cabinets”I teach security as a building. In chapter 1, the front door asks who you are. Then, once you’ve entered the building, you start going into offices, and each office has its own reception, controlling who gets in. You’re allowed onto the first floor and the second floor. You’re allowed into the accounting office, but not into the HR office.
The offices are the objects, the fields, the tabs and the pages. I call this structural security: can I see this, or can I not? The file cabinets inside each office, which records you can open, come later in the course. Keep those two apart, because almost every confusing access question gets simpler once you know which one you’re in.
This chapter is the offices. This module is the door to each office: the object permissions.
The seven object permissions
Section titled “The seven object permissions”Salesforce describes object permissions as “the base-level access users have to create, read, edit, and delete records for each object.” Here they are, with Salesforce’s own description of each, and the column that matters most for an architect: does it respect sharing, or override it (Object Permissions (opens in a new tab), Salesforce Help, checked 2026-11-01).
| Permission | What it gives, in Salesforce’s words | Sharing |
|---|---|---|
| Read | “Users can only view records of this type.” | Respects |
| Create | “Users can read and create records.” | Respects |
| Edit | “Users can read and update records.” | Respects |
| Delete | “Users can read, edit, and delete records.” | Respects |
| View All Records | “Users can view all records associated with this object, regardless of sharing settings.” | Overrides |
| Modify All Records | “Users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings.” | Overrides |
| View All Fields | “Users can view all fields and field data in records of this type, regardless of assigned field permissions.” | Respects |
Read the second column slowly, because the permissions build on each other. Create includes Read. Edit includes Read. Delete includes Read and Edit. There’s no Edit without Read, and no Delete without Edit. But notice what Create doesn’t include: Edit. A user can have Create without Edit, and then they can create a record but not change it afterwards.
Most of them open the office, not the cabinets
Section titled “Most of them open the office, not the cabinets”Now the third column. Read, Create, Edit and Delete all respect sharing. That’s the part people get wrong. Read on Account doesn’t mean you can see every account. It means you’re allowed into the Accounts office. Which accounts you can open is the file cabinets’ job: sharing, which Part 2 of the course covers.
So an object permission is a ceiling, not a grant of records. Chapter 1, module 2 showed the other half: where the office and the cabinets meet, Salesforce doesn’t add them together. Edit on the object and Read Only on the record gives you Read.
The two that open every cabinet
Section titled “The two that open every cabinet”Two object permissions are different. View All Records and Modify All Records override sharing: they open every record of that object, “regardless of sharing settings.” This is the one place where a structural permission reaches into the file cabinets.
Chapter 1 covered both, and I won’t repeat it all here. Two points to carry with you:
- They’re a design decision, not a fix. The most common way they end up in an org is a deadline: a user can’t see some records, the sharing isn’t built yet, and someone grants View All Records to make the ticket go away. Chapter 1, module 3 tells that story and its side effects.
- They open records, not fields. View All Records and Modify All Records don’t override field-level security. Chapter 1, module 2 has Salesforce’s words.
View All Fields
Section titled “View All Fields”The seventh permission is the bridge to the rest of this chapter. View All Fields lets users “view all fields and field data in records of this type, regardless of assigned field permissions,” and “To see an object’s fields, the user must also have at least Read permission” (same page).
Notice its third column: it respects sharing. View All Fields opens every field, but only on the records the user can already see. It’s the field-level version of View All Records, and it’s just as powerful. If someone has both View All Records and View All Fields on an object, they can see every record and every field of it. Grant it with the same care.
Module 2 is about the normal way to control fields, one by one.
The detail and its master
Section titled “The detail and its master”One dependency catches people. When two objects are in a master-detail relationship, some permissions on the detail need permissions on the master. Salesforce lists them (same page):
| If the detail object has | The master object gets |
|---|---|
| Modify All Records, or View All Records | View All Records |
| View All Records, or Read | Read |
In Setup, Salesforce fixes a broken dependency for you “on the first save action for the profile or permission set.” Through the API, “you must manually fix broken permission dependencies.”
Take Paul’s airline. Say Runway is a detail of Airport. Give someone View All Records on Runway, and when you save, Setup also turns on View All Records on Airport. You meant to open every runway, and you opened every airport too. That’s fine if it’s what you intended. Make sure it is.
Choosing object permissions for a set of users
Section titled “Choosing object permissions for a set of users”So how do you choose? Start from the levels in chapter 3, module 3: view, normal, power and admin. The team that builds a subsystem ships a permission set for each level, at least read-only, user and admin, and those permission sets carry the object permissions. Each persona’s group then assembles the levels it needs from each subsystem. For the Airport object, a first design might look like this:
- View: Read. Finance can see airports and report on them.
- Normal: Read, Create and Edit. A dispatcher keeps the airports they work with up to date.
- Power: add Delete. A chief pilot can remove an airport that closed.
- Admin: Modify All Records, only for the people who run the area, and only because the job needs every record.
That’s an example, not a rule. Your levels and your objects will differ. But the shape helps: most people need less than they ask for, and the permissions that override sharing belong only at the top, written down with a reason.
Salesforce recommends setting all of this in permission sets and groups: “Because you can reuse smaller permission set building blocks, you can avoid creating dozens or even hundreds of profiles for each user and job function” (same page). And to see who has what on one object, use Object Access in Object Manager, from chapter 3, module 6.
What an architect decides here
Section titled “What an architect decides here”- For each object, which of the seven permissions each level of its subsystem’s permission sets carries, starting from Read.
- Who, if anyone, gets View All Records or Modify All Records on each object, and the written reason.
- Who, if anyone, gets View All Fields, knowing it bypasses field-level security on every record they can see.
- Which master-detail relationships will pull permissions up to the master, and whether that’s intended.
- That object permissions live in permission sets and groups, not on profiles.
Beyond the exam: what AI changes. An agent user needs object permissions too, and the same rule holds: Read first, add only what the agent’s job needs, and never one of the two that override sharing to make a demo work. An agent with View All Records on an object can find every record in it, and it will. Chapter 20 covers agents.
Explore
Section titled “Explore”- Object Permissions (opens in a new tab), Salesforce Help (checked 2026-11-01)
- “View All” and “Modify All” Permissions Overview (opens in a new tab), Salesforce Help (checked 2026-11-01, chapter 1)