Designing a Scalable Salesforce Permission Model

A Salesforce permission model starts simple. One profile for sales reps, one for managers, one for admins. Then the company grows, roles multiply, acquisitions happen, products get added — and suddenly you have 47 profiles, nobody knows what any of them do, and changing a field permission takes three hours of testing because you’re not sure who’ll be affected.

This doesn’t have to happen. Here’s how to build a permission model that stays manageable as the org grows.

Understand the tools before you pick them

Salesforce gives you several layers:

Tool	Controls	Best used for
Profile	Object/field CRUD, app visibility, login hours/IP	Baseline access only — the minimum every user of that type needs
Permission Set	Same as profile, additive only	Specific feature or role additions on top of the profile
Permission Set Group	Bundles multiple permission sets	Assigning a complete “role package” to a user type
Muting Permission Set	Removes permissions within a PSG	Handling exceptions within a group

The key insight: profiles should be minimal, permission sets should do the real work.

The “minimum viable profile” approach

The most maintainable orgs we’ve worked in use 3–5 profiles:

Standard User — basic read/create on core objects, no sensitive fields, no destructive operations
Power User — edit and delete on most objects, moderate field visibility
Read Only — for contractors, auditors, integrations that only need to read
System Administrator — full access, only for actual admins
(Optional) Community / Portal User — for Experience Cloud

That’s it. Every variation in access — a sales manager who can see revenue fields, a support agent who can close cases, a marketing user who can only access campaigns — is handled by permission sets stacked on top of the base profile.

This means you can change a profile and know exactly who’s affected. It means onboarding a new user is assigning a profile + a few permission sets, not cloning a bespoke profile and manually tweaking 200 settings.

Naming permission sets that you can actually search

Three months after creating them, permission sets become impossible to find if they’re named like PS_SalesRep_V2_NEW or Full Access Marketing. Use a consistent naming convention:

[Object/Feature] — [Action/Level]

Examples:

Opportunity — Edit Revenue Fields
Case — Close and Delete
Reports — Create and Edit
CPQ — Full Access

When you search your permission set list looking for anything related to Cases, every relevant set shows up together. When you look at a user’s assigned sets, you can read what each one does without opening it.

Permission Set Groups: the “role package” approach

If a user type consistently needs 6–8 permission sets, bundle them into a Permission Set Group. Instead of assigning each set individually, you assign one group.

A field service manager might need:

Work Order — Edit and Close
Asset — View and Create
Service Appointment — Full Access
Reports — Create and Edit
Mobile App — Full Access

Bundle these into a group called Field Service Manager and assign that one thing. If the manager’s needs change, you update the group — and every manager gets the change automatically.

The dangerous permissions to watch

Some permissions are easy to over-grant and hard to audit. Review these regularly:

View All Data / Modify All Data — these bypass sharing rules entirely. Only integration users and system administrators should have them. Run this SOQL quarterly:

SELECT Name, PermissionsViewAllData, PermissionsModifyAllData
FROM PermissionSet
WHERE PermissionsViewAllData = true OR PermissionsModifyAllData = true

Manage Users — lets someone create users, assign permission sets, reset passwords. In the wrong hands, it’s a privilege escalation path.

API Enabled — necessary for integrations and developers, but shouldn’t be on every end-user profile. It’s a common vector in data exfiltration incidents.

Author Apex / Customize Application — these let users change org metadata. Unless someone is actually an admin or developer, they don’t need this.

Field-level security: the forgotten layer

Object access is the part everyone thinks about. Field access is the part that bites you.

A user with View access to Opportunities can still see every field unless FLS (Field-Level Security) restricts them. For sensitive fields — revenue, margins, personal data, social security numbers — set FLS explicitly on every profile and permission set, not just “it’ll default to hidden.”

When you add a new field to any object, ask: who actually needs to see this? Adjust FLS before the field goes live, not after someone notices it in a report.

Documenting the model

At a minimum, maintain a simple spreadsheet or Confluence page with:

Each profile: what user type it’s for, what makes it different from the others
Each permission set group: which user roles use it
Each standalone permission set: what it grants and which profiles it’s typically paired with

This document is your onboarding guide, your audit evidence, and your troubleshooting starting point when a user complains they can’t see a field they should be able to see.

Migrating off complex profiles

If your org has sprawled to 30+ profiles, you don’t have to fix it all at once. A practical approach:

Freeze profile creation — no new profiles without approval
For new user types, use permission sets from day one
Identify the 3–4 most-used profiles and leave them alone for now
When you have a reason to touch a profile (a new field, a new object), take 20 minutes to evaluate whether that profile can be consolidated into a standard one

Over 12–18 months, the count comes down naturally without a risky big-bang migration.

Is your permission model overdue for a review? We offer structured Salesforce security audits. Get in touch to find out where you stand.