Salesforce Permission Sets

What Salesforce permission sets do

Permission sets are Salesforce’s additive way to extend access beyond a user’s base profile. That makes them a precise tool for exceptions, temporary elevation, and task-specific entitlements, but also a common source of permission sprawl when organisations treat them as a quick fix instead of a governed access layer.

Because they add capability rather than replace the profile model, they are best understood as a second control plane for authorisation. A well-run setup keeps the profile relatively stable and uses permission sets to grant narrowly defined business functions, while poorly governed usage can hide who really has access to export data, modify objects, or run sensitive automation.

How permission sets differ from profiles and permission set groups

Profiles define the baseline of what a Salesforce user can do, while permission sets add incremental access on top. That distinction matters because access reviews must account for both layers: a user may appear ordinary at the profile level but still hold substantial extra authority through assigned permission sets.

Permission set groups help bundle multiple permission sets into a reusable package, which improves manageability but does not change the underlying principle. The control problem shifts from “who has one permission set?” to “which combinations of exceptions are creating effective access beyond the intended role?”

In practice, this is why permission sets are often paired with role design, access review, and change control. They work best when the organisation can explain why an extra permission exists, who approved it, and when it should be removed.

Why Salesforce permission sets matter for security

Permission sets are powerful because they can unlock administrative actions, data visibility, object-level rights, Apex class access, and other sensitive capabilities without altering a user’s profile. That flexibility is useful for least privilege, but it also means a single overbroad assignment can bypass the spirit of role separation.

They are especially important in Salesforce environments where business teams expect rapid access changes. A fast approval path is not the same as a safe one, because additive permissions can accumulate quietly across projects, emergency fixes, and temporary exceptions.

For Salesforce-specific hardening and monitoring patterns, NHIMG’s Salesforce Security Guide is the best starting point for understanding how permission sets fit into broader org security.

Common failure patterns in Salesforce permission set design

The main failure mode is entitlement drift. Over time, users collect permission sets that were justified for a one-off need but never removed, leaving access broader than the current job function.

Another common problem is using permission sets as a substitute for proper role engineering. That often creates a large pile of exceptions that is hard to review, hard to explain, and easy to overgrant. It also makes segregation-of-duties decisions less visible, because the effective permission picture is fragmented across the profile and many add-ons.

Monitoring matters because permission set changes can be just as security-significant as profile changes. In a mature setup, the question is not only whether a permission set exists, but whether its assignments, contents, and changes are continuously visible and justified.

Practitioner Guidance

Governance implication: Treat permission sets as controlled exceptions, not as a general-purpose access bucket. Each one should have a clear business purpose, an owner, and a review point so you can distinguish temporary elevation from permanent entitlement.

What to watch for: Watch for broad permission sets that accumulate administrative rights, data access, or object modification capability across many users. If a permission set becomes the default answer to every access request, the organisation is usually creating avoidable privilege sprawl.

Practitioner takeaway: The safest Salesforce model is stable profiles plus tightly justified permission sets, with regular review of both the assignment and the permission content.

Related resources from NHI Mgmt Group

• How should security teams reduce Salesforce access risk when profiles, permission sets, and sharing rules overlap?
• How should security teams enforce least privilege in Salesforce environments with complex roles and permission sets?
• What is the difference between Salesforce roles and permission sets?
• What is the difference between Salesforce permission sets and privilege governance?