Salesforce user management is built on three distinct, interacting access control systems – Roles, Profiles, and Permission Sets – and understanding how each works, what it controls, and how they interact is one of the most important skills for any Salesforce administrator. The most common admin mistake: confusing what each system controls and applying the wrong tool to an access problem, leading to either overly broad access (a security risk) or users locked out of what they need to do their jobs. This guide explains every component of Salesforce’s access control architecture with clear, practical definitions and configuration guidance.
The best guide is the one that helps the team keep access under control.
A practical explanation should make permissions feel manageable instead of confusing.
That means the guide should focus on structure and consistency rather than just terminology.
For many organisations, the goal is to give people enough access to do their work without exposing more data than they need.
It should also show how access design affects security, usability, and support overhead.
A good guide should explain how the pieces fit together and why the distinction matters.
That makes user management a core admin task rather than a background detail.
Salesforce user management is useful because teams need a clear way to control who can see, edit, and manage different parts of the CRM. Roles, profiles, and permission sets work together to shape that access.
The Salesforce Access Control Architecture
Salesforce access control operates on three independent axes:
- Object-level access: Can the user see, create, edit, or delete records of a specific object type (for example, can they see Opportunities at all)?
- Record-level access: Can the user see a specific record? A user may have access to the Opportunity object but only be able to see opportunities they own, not others’
- Field-level access: Can the user see or edit a specific field on a record? A user may see an Account record but not see the sensitive Annual Revenue field
Profiles and Permission Sets control object-level and field-level access. Roles and Sharing Rules control record-level access. These systems work in combination – getting one wrong does not fix the other.
Profiles: The Foundation of Object and Field Access
What Profiles Control
Every Salesforce user has exactly one Profile – it cannot be removed or left unassigned. The Profile defines the user’s baseline access to Salesforce objects and features:
- Object permissions: For each Salesforce object (standard and custom), the Profile grants or denies Create, Read, Edit, Delete, View All, and Modify All permissions. A sales rep Profile might have Read/Edit on Accounts, Create/Read/Edit on Contacts and Opportunities, but no access at all on Cases
- Field-level security: For each field on each object, the Profile controls whether the field is Visible (user can see the value) and Editable (user can change the value). A field can be visible but not editable – common for calculated or system fields that should be seen but not manually overridden
- App and tab visibility: Which Salesforce Lightning apps and tabs are visible and default for users on this Profile
- System permissions: Feature-level permissions – “Manage Users” (can create and edit users), “Export Reports” (can export report data to CSV), “Modify All Data” (can edit any record regardless of ownership), “View All Data” (can see all records regardless of sharing). These are powerful – only grant them to users whose roles genuinely require them
- Record Type assignment: Which Record Types users on this Profile can use when creating new records
- Page Layout assignment: Which page layout users on this Profile see for each object and Record Type
- Login access restrictions: Login IP ranges and login hours that restrict when and from where users on this Profile can log in
Standard Profiles vs Custom Profiles
Salesforce provides several standard Profiles that cannot be deleted or fully modified:
- System Administrator: Full access to all objects and features. Grant sparingly – every System Administrator can see all data and modify all settings
- Standard User: Basic access to core Salesforce objects – a starting point for customisation
- Read Only: View access to records without create or edit permissions – for executive reporting users who need data visibility without modification rights
- Chatter Free: Access only to Chatter, not full Salesforce CRM. Useful for internal stakeholders who need collaboration access without a full CRM licence cost
For most organisations, the right approach is to clone a standard Profile and customise it – not modify the standard Profile directly – preserving the standard Profiles as reference points. Create custom Profiles for each distinct user role: Sales Rep, Sales Manager, SDR, Marketing Coordinator, Service Agent, Read-Only Manager, Integration User, and so on.
Roles: Controlling Record Visibility
What Roles Control
Roles control which records a user can see – they operate independently of Profiles. The Role Hierarchy determines record visibility: users can see all records owned by users at their own role level and below them in the hierarchy. They cannot see records owned by users above them or in separate branches (unless the Organisation-Wide Default sharing model is set to Public, or sharing rules grant additional access).
Example Role Hierarchy for a sales organisation:
- CEO (top of hierarchy – can see all records)
- VP Sales (below CEO – can see all sales rep records)
- Regional Sales Manager – West (below VP Sales – can see West region reps’ records)
- Account Executive – West 1, AE – West 2 (leaf nodes – can see only their own records by default)
Role Hierarchy Does Not Equal Org Chart
A common misunderstanding: the Salesforce Role Hierarchy is a data access control mechanism, not an organisational chart. Two people with the same job title may have different Roles in Salesforce if they have different data access requirements. Configure Roles based on what records users need to see – not on HR reporting relationships.
Organisation-Wide Defaults (OWDs)
Organisation-Wide Defaults define the most restrictive level of record access – the baseline access for all users before Role Hierarchy, Sharing Rules, or manual sharing grants any additional visibility:
- Private: Only the record owner and users above them in the Role Hierarchy can see the record. The most restrictive setting – appropriate for sensitive data where visibility should be tightly controlled
- Public Read Only: All users can see the record but only the owner can edit it
- Public Read/Write: All users can see and edit any record. The least restrictive setting – appropriate for reference objects with no sensitivity
- Controlled by Parent: Used for detail records in master-detail relationships – the child record’s access follows the parent record’s access
Configure OWDs at Setup → Sharing Settings. Start with the most restrictive setting appropriate for your compliance requirements, then use Sharing Rules to grant additional access to specific groups where needed.
Permission Sets and Permission Set Groups
What Permission Sets Control
Permission Sets are additive to Profiles – they grant additional permissions beyond what the user’s Profile provides, without changing the Profile itself. A user can have multiple Permission Sets assigned. This is the modern Salesforce access control best practice: create a minimal baseline Profile, then use Permission Sets to grant specific additional access on a role-by-role or need-by-need basis.
Practical use cases for Permission Sets:
- Grant a specific sales rep access to Contracts (which their Profile does not include) because they are managing a complex Enterprise deal that requires it
- Grant the “Export Reports” system permission to specific analysts who need it, without granting it to all Standard Users via the Profile
- Grant access to a specific custom object or feature (a CPQ managed package, a custom approval process) to users who need it without modifying the broader Profile
- Grant Salesforce integration users the minimum permissions required for their API operations without assigning a broad Profile
Permission Set Groups
Permission Set Groups (available on Enterprise and above) bundle multiple Permission Sets into a single named group – assigned to a user as one unit rather than individually. For a “Senior Account Executive” role that needs access to 7 different feature-level Permission Sets, create a Permission Set Group called “Senior AE” and assign all 7 Permission Sets within it. This simplifies user setup and ensures consistent access assignment for every new user in that role.
Muting Permission Sets
Muting Permission Sets can remove specific permissions from within a Permission Set Group without editing the underlying Permission Sets – useful when a Permission Set Group is almost right for a user type but grants one permission that should be withheld. A Muting Permission Set within the group overrides specific permissions downward for users assigned to that group.
The Modern Best Practice: Profile + Permission Sets
Salesforce’s recommended access control architecture has moved away from “create many custom Profiles for every permutation of access” toward “create minimal Profiles and layer Permission Sets for specific access grants”:
- Create a small number of base Profiles – typically 3–8 for most organisations: Admin, Standard CRM User, Read-Only, Integration User, Community/Portal User
- Configure each Profile with the minimum object permissions appropriate for its user category – only grant the object access that every user in this category genuinely needs
- Create specific Permission Sets for feature access, system permissions, and object access that only certain users need – not every user in the category
- Assign Permission Sets to individual users, or use Permission Set Groups to bundle related Permission Sets for common user role types
This approach reduces Profile management complexity, enables granular access control at the user level via Permission Sets, and makes it much easier to audit and adjust access without creating Profile sprawl.
The best access model is the one that matches real job responsibilities. If the rules are too loose, security suffers; if they are too tight, productivity does.
Common Access Control Mistakes
- Creating too many Profiles: A Profile for every individual role variation becomes an administrative nightmare – 40 custom Profiles with subtle differences that are hard to audit and maintain. Use Permission Sets for variation instead
- Granting “View All Data” or “Modify All Data” too broadly: These system permissions override all record-level sharing – users with them can see and edit every record in the org regardless of OWD, Role, or Sharing Rules. Grant only to System Administrators and specific integration users who genuinely need full data access
- Confusing Profile permissions with Sharing/Role access: A user whose Profile gives them no access to Opportunities cannot see Opportunities even if a Sharing Rule grants them access to a specific Opportunity. Profile object permissions must allow access before record-level sharing can grant visibility to specific records
- Not using Permission Set Groups for role-based access: Assigning 5–10 individual Permission Sets to each new user is error-prone and inconsistent. Bundling them in Permission Set Groups ensures every new user in a role gets the same consistent access package
Fix: Implementing Permission Sets Instead of Multiple Profiles
Managing access through dozens of custom profiles becomes an administrative burden as organisational roles evolve. The modern Salesforce approach is to use a small number of base profiles (one per licence type) that grant minimal permissions, then layer Permission Sets on top for specific feature access. Permission Set Groups let you bundle multiple permission sets into a logical package (for example, “Sales Manager Access”) that can be assigned or revoked as a unit. This makes access management far more manageable as your organisation grows.
Fix: Automating User Lifecycle Management with Flows
Manual user onboarding and offboarding processes create security gaps when departing employees retain access or new hires wait days for proper configuration. Salesforce Flow can automate user provisioning workflows that trigger when HR systems mark an employee as hired or terminated. Integration with identity providers like Okta or Azure AD through Single Sign-On enables centralised user lifecycle management – ensuring Salesforce access is automatically granted, modified, or revoked in sync with the authoritative HR system of record.
What is the difference between profiles and permission sets in Salesforce?
Profiles are mandatory – every Salesforce user must have exactly one profile, which controls baseline object access, field-level security, page layouts, and system permissions. Permission Sets are optional add-ons that grant additional permissions beyond what the profile provides, without changing the profile itself. The recommended approach is to use minimal base profiles and grant additional access through permission sets, making it easier to give specific permissions to specific users without creating a proliferation of custom profiles.
How do Salesforce roles differ from profiles?
Profiles control what a user can do – what objects they can access, what fields they can see, and what system functions they can use. Roles control what data a user can see – specifically, they define the record visibility hierarchy based on the organisation’s reporting structure. A user in a child role can typically see records owned by users in parent roles above them (if the sharing model is set accordingly), enabling managers to see their team’s records while reps only see their own.
What is a Salesforce permission set license?
A Permission Set License (PSL) is an add-on licence that enables specific feature access beyond what the user’s base licence provides. For example, a Sales Cloud user might receive a Marketing Cloud PSL to access Marketing Cloud features without needing a full Marketing Cloud seat licence. PSLs are assigned to users through permission sets that require the corresponding PSL. They offer a more cost-effective way to extend access to specific features for users who do not need a full additional licence.
How many users can a Salesforce org have?
Salesforce does not impose a hard limit on the total number of users an organisation can have – the limit is based on the number of user licences purchased. Enterprise and Unlimited editions support unlimited customisation and typically accommodate organisations of any size. Very large implementations with tens of thousands of users exist, including global enterprises using Salesforce as their primary CRM. Performance and governor limits become more relevant than user count at extremely large scales.
Common Problems and Fixes
Challenge: Over-Permissioned Users Creating Security and Compliance Risks
Many Salesforce orgs accumulate permission creep over time as users are granted additional access to solve immediate problems – with no corresponding process to remove that access when the need passes. Following the principle of least privilege (giving users only the permissions they need to do their job) reduces the exposure surface for data breaches and supports compliance with data protection regulations like GDPR. Running a quarterly permission audit using Salesforce’s Permission Set usage reports and removing unused permissions is a sound administrative practice.