Permission
A permission in Salesforce is a single access right that controls one specific thing a user can do or see.
Definition
A permission in Salesforce is a single access right that controls one specific thing a user can do or see. Examples include reading a record on an object, editing a field, calling the API, or running a powerful operation like View All Data. Each permission is a small on or off switch, and a user's full access is the sum of every permission turned on for them.
Permissions are not assigned to users directly. They live inside profiles and permission sets, which are the containers that group permissions together. A user gets one profile plus any number of permission sets, and Salesforce adds up the permissions from all of them. If any container enables a permission, the user has it.
How permissions stack up across the Salesforce security model
The main categories of permission
Salesforce groups permissions into a few broad kinds, and knowing the kind tells you what it protects. Object permissions set the base level of access to records of one object. The six are Read, Create, Edit, Delete, View All, and Modify All. Field permissions, also called field-level security, decide whether a user can see or edit each individual field on an object. User permissions, sometimes called system permissions, control tasks and features rather than data, things like API Enabled, Manage Users, or access to specific Setup pages. On top of these sit permissions for Apex classes, Visualforce pages, custom permissions, tabs, and connected apps. The distinction matters in practice. Object access without field access still hides protected fields, and field access means nothing if the user cannot reach the object at all. When you plan access for a role, walk through each category in order rather than hunting for one master switch, because no single permission grants everything a user needs.
Profiles and permission sets are the containers
A user never receives a permission on its own. Permissions are defined inside two container types. A profile is the single base assignment every user must have, and historically it carried most access. A permission set is a reusable bundle of permissions that you assign on top of the profile to add capabilities. The rule that ties them together is additive. If a permission is off in the profile but on in a permission set the user holds, the user has that permission. Nothing in a permission set can take a permission away. Salesforce now recommends a thin profile plus layered permission sets, often starting from the Minimum Access - Salesforce profile. This keeps the base small and predictable, then grants each capability through a named permission set you can audit and reuse. Permission set groups bundle several permission sets into one persona-style assignment, and muting permission sets can switch off specific permissions inside a group when you need to trim a persona without editing the underlying sets.
Object permissions and the View All / Modify All exception
Object permissions are the floor for record access. Read lets a user view records, Create adds new ones, Edit changes them, and Delete removes them. These four still obey your sharing settings, so a user with Edit can only edit the records that sharing actually exposes to them. Two object permissions break that rule on purpose. View All grants the ability to view every record of an object regardless of sharing, and Modify All grants read, edit, delete, transfer, and approve on every record of that object, again regardless of sharing. They override organization-wide defaults, role hierarchy, sharing rules, and manual shares for that one object. Because they ignore sharing entirely, treat View All and Modify All as elevated grants. They are useful for an object owner or a support team that genuinely needs full visibility, but handing them out widely quietly defeats the sharing model you built. The org-wide cousins, View All Data and Modify All Data, are even broader and apply to almost every object at once.
Least privilege and powerful permissions
The guiding idea for permissions is least privilege. Grant only what a user needs to do their job, and nothing more. Salesforce builds this into its own guidance by recommending you assign the Minimum Access - Salesforce profile and then add permissions through permission sets rather than starting everyone with broad access. A short list of permissions deserves extra care because each one can undo other controls. Modify All Data and View All Data ignore object and record-level security across the org. Author Apex lets a user write and run code. Manage Users can reset access for other people. Customize Application and Modify Metadata change how the org itself behaves. Export Reports and the data loader pathways can move large volumes of data out. None of these are wrong to grant, but each should map to a clear business reason and a known set of people. Granting Modify All Data to too many users is one of the most common and most damaging security mistakes, because it silently bypasses every sharing rule and field restriction you put in place.
Where permissions live and how to inspect them
You manage permissions in Setup, under Profiles and under Permission Sets. Each profile or permission set page lists object settings, field-level security, and a long System Permissions area for user permissions. Two tools make auditing easier. The User Access Policies and the per-user access summary on a user record show which profile and permission sets combine to give that person their access. The View Summary on a permission set lists every permission it grants in one place. For larger reviews, Permission Set Groups show the net effect of several sets at once, and the muting permission set tells you what was deliberately removed. When you need to answer the question who can do this, do not read profiles one by one. Start from the user and expand the assignments, or start from the dangerous permission and find every container that enables it. The metadata API and tools like SOQL against PermissionSet and ObjectPermissions records let you script these audits, which is how mature orgs keep an eye on permission creep over time as people change teams and old grants linger.
A worked example: granting case delete to support leads
Say support leads need to delete Cases, but regular agents must not. You would not edit the shared Support Agent profile, because that would change access for everyone on it. Instead you create a permission set named Case Delete Access. Inside it you open Object Settings for Cases and enable the Delete object permission, leaving Read, Create, and Edit as they already come from the profile. You then assign that permission set only to the handful of support leads. Now the additive rule does the work. Each lead has the agent profile plus the new set, and because Delete is on in the set, those users can delete Cases while everyone else cannot. If a lead later moves teams, you remove the one assignment and the elevated access disappears cleanly, with no profile surgery. If the grant is temporary, you can set an expiration date on the assignment so it lapses on its own. This is the pattern Salesforce recommends: keep the profile thin, express each extra capability as a small named permission set, and assign by task rather than by title.
Grant a permission with a permission set
Permissions are enabled by configuring a permission set and assigning it. This walkthrough adds a single permission to users by layering a permission set on top of their existing profile, which is the access pattern Salesforce recommends.
- Create the permission set
In Setup, go to Permission Sets and click New. Give it a clear, task-based label such as Case Delete Access. Leave the License field set to None unless the permission requires a specific user license.
- Enable the permission
Open the new permission set and choose the right section. Use Object Settings for object and field access, or System Permissions for user permissions like API Enabled. Switch on only the specific permission you intend to grant and save.
- Assign it to users
On the permission set, click Manage Assignments, then Add Assignments. Select the users who need the capability and confirm. Set an expiration date if the access is meant to be temporary.
- Verify the net access
Open one assigned user record and view the access summary, or use User Access Policies, to confirm the permission now resolves as enabled from the combination of their profile and this permission set.
Where you set Read, Create, Edit, Delete, View All, and Modify All for an object, plus field-level security for that object's fields.
The list of user permissions such as API Enabled, Manage Users, Author Apex, and View All Data that control tasks and features rather than records.
Optional licensing scope for the permission set. Leave it as None for a set that should apply across users regardless of their permission set license.
An optional end date on an assignment so a temporary grant lapses automatically instead of lingering.
- Permission sets only add access. To remove a permission a profile grants, change the profile or use a muting permission set in a permission set group, not the permission set itself.
- Object access without the matching field-level security still hides protected fields, and field access is useless if the user cannot reach the object at all.
- View All and Modify All ignore your sharing settings for that object, so grant them deliberately and to as few users as possible.
- Editing a profile changes access for every user on that profile, which is why a dedicated permission set is safer for a one-off grant.
Prefer this walkthrough as its own page? How to Permission in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Permissions and Access SettingsSalesforce
- Object PermissionsSalesforce
Straight from the source - Salesforce's reference material on Permission.
- Permission SetsSalesforce
- Guidelines for Creating Permission Sets and Permission Set GroupsSalesforce
Hands-on resources to go deeper on Permission.
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 Permission in the Salesforce security model?
Q2. Through which Salesforce mechanisms are Permissions actually granted to a user?
Q3. Which Permission is described as one of the most common mistakes when it is granted too broadly?
Discussion
Loading discussion…