What are Permission sets?

Introduction

Permission Sets in Salesforce are granular access containers that extend a user's access beyond what their Profile provides. Administrators use them to grant additional object, field, app, and system permissions without changing the user's Profile, which keeps access management flexible and least-privilege.

Key concepts

Permission Sets are additive security constructs:

• They never remove permissions, only add to what a user already has from their Profile.
• A single user can have multiple Permission Sets assigned.
• Permission Sets can be grouped using Permission Set Groups for easier management.
• Some Permission Sets require a specific Permission Set License (PSL) and are limited by license availability.

Where Permission Sets apply

Permission Sets can grant:

• Object permissions (Create, Read, Edit, Delete, View All, Modify All)
• Field-level security (FLS) for specific fields
• App and Tab access
• Record-level access via sharing rules or permission set-based sharing
• System permissions (e.g., "Manage Public Reports", "Customize Application")

Permission Set vs Profile

The difference matters when you design an access model:

• Profile: Baseline permissions that every user must have. Every user must be assigned exactly one profile.
• Permission Set: Supplementary permissions assigned in addition to the profile. Users can have zero to many permission sets.

Use Profiles to define broad job-family access and Permission Sets to handle exceptions or temporary needs.

Common use cases

• Granting temporary access (e.g., project access, audits) without changing profiles.
• Enabling feature access for a small group of users (e.g., a beta feature or a soql-in-loops-security-review-impact-for-managed-packages/" class="auto-link">managed package).
• Applying field-level permissions to specific users.
• Using Permission Set Groups to bundle several Permission Sets for role-based access.

Best practices

• Keep Profiles minimal and role-oriented; use Permission Sets for exceptions.
• Prefer Permission Set Groups over too many individual Permission Sets to reduce assignment complexity.
• Document Permission Sets and use naming conventions (e.g., "PS: Finance - Edit Invoices").
• Use assignment automation (Permission Set Assignment in Flow or Apex) for scale.
• Review Permission Set Licenses to avoid assignment failures due to license constraints.

Assigning Permission Sets programmatically

You can assign a Permission Set to a user using Apex. Example:

Id psId = [SELECT Id FROM PermissionSet WHERE Name = 'My_Permission_Set' LIMIT 1].Id; PermissionSetAssignment psa = new PermissionSetAssignment(AssigneeId = '005xxxxxxxxxxxx', PermissionSetId = psId); insert psa;

Permission Set Groups

Permission Set Groups let you combine multiple Permission Sets into a single logical bundle that can be assigned together. They support:

• Muting Permission Sets to explicitly remove permissions from the group (use carefully).
• License enforcement for grouped Permission Sets.

Limitations and considerations

• Permission Sets are additive only; they cannot revoke access granted by a profile.
• The number of Permission Sets per org and per user has limits, so check Salesforce documentation for the current ones.
• Permission Set Licenses may restrict who can receive certain Permission Sets.

Interview tip

When answering interview questions, explain Permission Sets with a small example comparing two users: one uses a Profile for baseline access; the other gets additional CRUD or system permissions via a Permission Set for a temporary project. Cover administration simplicity and least privilege, and bring up Permission Set Groups when the question turns to scale.

Summary

Permission Sets grant additional permissions in Salesforce without changing profiles. Use them for least-privilege access, for temporary access needs, and to simplify management through Permission Set Groups.