Salesforce's permission model is genuinely flexible. You can grant access to specific objects, fields, apps, and features without touching a user's base profile. In theory, this lets you build a security model that's precise, auditable, and easy to maintain.
In practice, most orgs end up with a sprawling collection of permission sets with names like "Sales Team Extra Access" and "Temp Admin Permissions - Delete When Done" (that never gets deleted).
This guide is about doing it right — whether you're starting fresh or cleaning up an existing mess.
Profiles vs. Permission Sets: The Right Mental Model
Profiles should define the minimum access a user needs to do their job. Permission sets extend that access for specific needs.
The mistake most orgs make is putting too much in profiles — creating a handful of bloated profiles that grant far more access than most users in that group actually need. Then they layer permission sets on top to handle edge cases, and the model becomes impossible to audit.
A better approach:
- Profiles: minimum access, baseline settings (login hours, IP restrictions, record types)
- Permission Sets: grant additional access for specific roles, features, or projects
- Permission Set Groups: bundle related permission sets for a job function
Understanding Permission Set Groups
Permission Set Groups (PSGs) are the feature that makes large-scale permission management actually manageable. Instead of assigning five separate permission sets to every Sales Manager, you create a "Sales Manager" PSG that includes all five — and assign the group.
When you need to add access to all Sales Managers, you update the group. One change, instant effect across all members.
PSGs also support muting permission sets — a way to remove a specific permission from a user who is in a group, without removing the whole group. This is useful when most members of a group need a permission, but one or two shouldn't have it.
The Most Common Permission Set Mistakes
1. Granting "Modify All Data" or "View All Data" too freely
These are org-wide permissions that bypass all sharing rules and record-level security. They're intended for system administrators and integration users, not business users. I regularly see them granted in permission sets to "solve" a sharing issue without understanding the security implications.
2. Creating permission sets for individuals rather than roles
"John's Extra Access" is a sign of a broken process. Access should be role-based, not person-based. When John leaves, nobody knows what to remove — or why it was there.
3. Never auditing assigned permission sets
Users change roles. Departments reorganise. Projects end. But permission sets rarely get removed when circumstances change. Run an audit every quarter: list all permission set assignments and verify each one is still appropriate.
4. Duplicate access across profiles and permission sets
If a profile already grants Read access to Accounts, there's no value in also granting it via a permission set. Duplicate access doesn't cause errors, but it makes your security model harder to understand and audit.
How to Structure Permission Sets Well
A framework that works well for mid-to-large orgs:
Tier 1 — Feature Access Sets One permission set per major feature or app. Example: "Einstein Analytics Access", "Service Cloud Voice", "Territory Management". These are assigned to anyone who uses that feature, regardless of their role.
Tier 2 — Role-Based Sets Permissions that are specific to a job function. Example: "Sales Rep — Opportunity Write", "Service Agent — Case Escalation". These get bundled into PSGs.
Tier 3 — Temporary / Project Sets Short-lived access for migrations, integrations, or projects. These must have an expiry date set in the description field — and someone must own the task of removing them.
Auditing Existing Permission Sets
If you've inherited an org with permission set chaos, here's a practical starting point:
- Export all permission sets and their assignments (available via Reports or Data Loader)
- Mark each permission set as: active role need / legacy / unknown / duplicate
- For anything marked legacy or unknown, track down the original requester
- Consolidate duplicates before removing — check if they have different field-level settings
This takes time, but it's worth doing once properly rather than half-doing it repeatedly.
MeetTheMind Insight 💡
The cleanest permission models I've seen were built by teams that treated permissions like code: every change is documented, reviewed, and tracked in a changelog. The messiest ones were built by teams that treated access as a support ticket — someone asks, someone grants, nobody reviews.
If you're starting a new org or a major cleanup, spend a day writing down your permission model on paper before touching Setup. The exercise of documenting forces decisions that would otherwise get deferred forever.
Key Takeaways
- Profiles = minimum access; permission sets = extensions for specific needs
- Use Permission Set Groups to manage role-based access at scale
- Avoid granting "Modify All" or "View All" outside of admin/integration users
- Build for roles, not individuals — "John's Access" is a process failure
- Audit quarterly; most orgs have significant permission drift within 12 months
- Document the permission model before building it — the design session is worth it