Salesforce permissions are confusing. Here's the Best Practice approach.

Are you administering permissions in Salesforce? Is this how it makes you feel? You are not alone.

TLDR: The Best Practice for Salesforce permissions has been changing, and you should consider revising how you dole out permissions.

---

Current Best Practice

Keep profiles skinny. Use Dynamic Forms, Dynamic Actions, and Lightning Record Pages wherever possible — those let you control the UI experience with permission sets instead of relying on page layout assignments. Over time, this reduces dependency on profiles for layout. (Real world example below.)

• Profiles: Keep them as “bare minimum containers” for login, basic visibility, and defaults.

  • Assign just one profile per user.

  • Profile should handle only:

    • Login hours / IP ranges

    • Locale / time zone / default record type

    • Object tab visibility defaults

    • Record Type defaults

    • Page Layout assignments (controlled by record type + profile pair)

    • Password policies (if org-level isn’t enough)

    
    

• Permission Sets & Permission Set Groups (PSGs):

  
  

  • Use permission sets as the atomic building blocks 

    • Specific object permissions (Create, Edit, Delete)

    • Field-level security for specialized fields

    • Custom permissions

    • Apex class/Visualforce page access

    • Flow access

    • etc., based on putting together sets of permissions related to a Salesforce tool (like Action Plans, Cases, or other tools.)

    
    

  • Bundle those into permission set groups (PSGs) that align with job functions/roles 

    • Sales Rep Bundle

    • Service Agent Bundle

    • Power User Bundle

    • Manager Bundle

    • etc., based on function

    
    

  • Assign PSGs directly to users.

Why this shift?

• Profiles are rigid and don’t scale for modern orgs.

• There tended to be 1,000,000 profiles in a complex org.

• This is very difficult to audit or maintain

• Permission sets/PSGs allow layered, flexible, and auditable security.

• Easier to support hybrid roles without cloning/managing dozens of profiles.

So, what are profiles for now?

Profiles are basically:

• The login gate (when/where/how a user can access).

• A default baseline (what’s visible at login, default apps, record type defaults).

• The “skeleton” every user must have, but with as few permissions as possible.

Everything else—CRUD, FLS, Apex class access, system permissions—should live in permission sets and PSGs.

---

Real World Example:

Instead of creating profiles like:

• Sales Rep

• Sales Rep with Territory Management

• Senior Sales Rep

• Sales Manager

You'd have:

• Profile: Standard User (minimal baseline)

• Permission Sets: Sales Objects, Territory Management, Advanced Reporting, Manager Tools

• Permission Set Groups:

  • Sales Rep Bundle (Sales Objects)

  • Territory Sales Rep Bundle (Sales Objects + Territory Management)

  • Sales Manager Bundle (Sales Objects + Manager Tools + Advanced Reporting)

This way, if someone gets promoted or changes roles, you just assign different Permission Set Groups rather than changing their entire profile.

As always, please reach out to Rule Six Consulting if you want help setting this up correctly.