Salesforce Roles and Profiles control two completely different dimensions of user access, and confusing them causes the majority of Salesforce data visibility problems and over-permissioned orgs. Profiles control what a user can do – which objects they can create, read, edit, and delete, which fields they can see, which apps they can access. Roles control what data a user can see – which records are visible to them based on the role hierarchy. Every Salesforce user has exactly one profile. Roles are optional but are essential for any org with more than one user who should not see every record owned by every other user.
The best guide is the one that makes the difference easier to apply.
A useful explanation should help the reader see where each concept fits in the access structure.
That means the guide should focus on practical use rather than definitions alone.
For many teams, the value is in creating a permissions model that matches real responsibilities.
It should also show how access design affects visibility, data control, and support overhead.
A good guide should explain how the two pieces work together and why mixing them up causes problems.
That makes the distinction important for admins setting up the system correctly.
Salesforce roles vs profiles is a useful comparison because access control in the platform depends on understanding what each one does. Roles and profiles are related, but they solve different parts of the permissions problem.
What Profiles Control
A Salesforce Profile is a collection of settings that defines what a user can do within Salesforce. Profiles configure:
- Object permissions: for each standard and custom object, whether the user can Create, Read, Edit, Delete, View All, and Modify All records of that type. View All and Modify All bypass record-level security entirely – use these only when genuinely required.
- Field-level security: for each field on each object, whether the user can see and edit that specific field. A profile can grant Read access to Opportunities but hide the Gross Margin field from sales reps who should not see cost information.
- Tab visibility: which Salesforce tabs appear for users on this profile – Default On (visible), Default Off (not visible but accessible via customisation), Tab Hidden (inaccessible).
- App access: which Salesforce apps (Lightning apps configured in App Builder) are available to users on this profile.
- Record type access: which record types are accessible to users on this profile, and which is the default. Different record types drive different page layouts and picklist values – a profile determines which record types a user can create.
- Page layout assignment: per object and record type, which page layout is shown to users on this profile when they view a record.
- Login hours and IP restrictions: when users on this profile can log in and from which IP addresses.
- System permissions: high-level capabilities including API access, Data Export, Manage Users, Modify All Data, and hundreds of other system-level permissions that control Salesforce platform access.
Every Salesforce user is assigned exactly one profile. The profile cannot be removed – it can only be changed. Profile assignment is set at Setup ? Users ? [User] ? Profile.
What Roles Control
A Salesforce Role is a position in the role hierarchy that determines which records a user can access based on record ownership. The role hierarchy is a tree structure where users higher in the hierarchy can see records owned by users below them. Roles do not affect what a user can do with records – that is Profile’s job. Roles only determine which records are visible.
How role hierarchy data access works:
- A user at the bottom of the hierarchy (e.g., Sales Rep) sees their own records and only their own records – when Organisation-Wide Defaults (OWD) are set to Private
- A user in a parent role (e.g., Regional Sales Manager) sees their own records plus all records owned by users below them in the hierarchy
- A user at the top of the hierarchy (e.g., VP of Sales, or the CEO role) sees all records in the entire organisation
Role assignment is optional – a user without a role assigned has no role hierarchy access, meaning they only see records they own (when OWD is Private). Role assignment is set at Setup ? Users ? [User] ? Role.
The Interaction: Profiles and Roles Together
A user’s actual data access is determined by the combination of their Profile AND their Role, operating independently:
- Profile answers: “Can this user access Opportunity records at all, and which fields can they see?”
- Role answers: “Which specific Opportunity records are visible to this user?”
A concrete example: a Sales Rep profile grants Read, Create, Edit access to Opportunities. A “Western Region Rep” role makes the user’s own Opportunity records visible. The user can read, create, and edit Opportunities – but only their own (OWD = Private, no sharing rules broadening access).
Their manager, with the same Sales Rep profile but in the “Western Region Manager” role (parent of “Western Region Rep”), can also read and edit Opportunities – and can see all Opportunities owned by Western Region Rep users below them in the hierarchy.
The VP of Sales with a “VP Sales” role at the top of the Sales branch can see all Opportunities in the org – but is still constrained by their Profile in what they can do with records they can see.
The best access model is the one that matches the team’s real responsibilities. If roles and profiles are confused, the system becomes harder to manage.
Common Misconceptions
Misconception: “Assigning someone a Manager role gives them admin powers.” This is false. Roles are exclusively about data visibility. A “Manager” role does not grant the ability to modify user settings, change profiles, or access Setup. Those capabilities come from Profile system permissions (specifically “Manage Users” and “Customize Application”).
Misconception: “A higher-level role means more permissions.” Also false. A CEO at the top of the role hierarchy has access to see all records, but if their Profile is “Standard User,” they cannot do anything in Setup, cannot export data, and cannot modify other users’ records if their profile lacks Edit permissions on those objects.
Misconception: “I need to create a new profile for every team.” This was Salesforce’s historic best practice but is no longer recommended. The current guidance is to use a Minimum Access User profile (or Standard User profile) as the baseline for all users, then grant specific additional capabilities via Permission Sets. This reduces profile proliferation and simplifies maintenance.
Permission Sets: The Third Layer
Permission Sets are additive collections of object permissions and field-level security that are assigned to users on top of their profile. Permission Sets allow granting specific additional access without changing the user’s profile or creating profile variants.
Example: A Standard User profile gives Read/Create/Edit access to standard CRM objects. A “Campaign Manager” Permission Set adds Create, Edit, and Delete access to Campaigns – granted to the marketing team members who manage campaigns, while the rest of the org remains on Standard User without Campaign management rights.
Permission Set Groups bundle multiple permission sets together for easier assignment – a “Field Sales Full Access” Permission Set Group might combine “Opportunity Management,” “Lead Management,” “Call Logging,” and “Mobile App Access” permission sets into a single assignment.
The modern Salesforce security model recommendation:
- Assign all users the Minimum Access User profile (or a minimal-access custom profile)
- Grant all standard CRM access (Leads, Contacts, Accounts, Opportunities) via a base Permission Set assigned to all users
- Grant role-specific additional access via targeted Permission Sets or Permission Set Groups
- Use Roles and sharing rules to control which records each user can see
This approach eliminates the maintenance burden of maintaining 15 different profiles where the only differences are two or three checkbox permissions.
When to Create Custom Profiles
Custom profiles remain necessary when users need different login restrictions (IP ranges, login hours) or different page layout assignments – since these cannot be controlled via Permission Sets. Create custom profiles when:
- A user group needs login restricted to specific IP addresses (contractor profile with office IP restriction)
- A user group needs a different page layout on the same record type (executive view vs standard rep view of Opportunity)
- A user group needs different record type defaults (inside sales reps create “Inbound” Opportunity record type by default; field reps create “Enterprise” Opportunity record type by default)
For all other differentiation (object access, field access, system permissions), Permission Sets are the preferred mechanism over profile cloning.
Auditing Profiles and Roles
Regular audits of profile and role configurations identify over-permissioned users and orphaned configurations:
- Profile audit: Setup ? Profiles ? [Profile] ? Assigned Users – review who is on each profile, particularly any profile with elevated permissions (View All Data, Modify All Data)
- Permission Set audit: Setup ? Permission Sets ? [Permission Set] ? Manage Assignments – see all users with a given permission set assigned
- Role audit: Setup ? Users ? Roles – review the role hierarchy structure. Roles that have no users assigned to them are candidates for deletion (unused roles create hierarchy gaps that affect forecasting roll-ups).
- Unused profile cleanup: a profile with zero users assigned can be deleted – Setup ? Profiles, check the Users column for each profile
Practical Setup: A Mid-Size Sales Org Example
A 50-person B2B sales org with inside sales reps, account executives, sales managers, and a VP of Sales might structure profiles and roles as follows:
Profiles (3 profiles total, minimal-access approach):
- Minimum Access User (base for all) + Standard CRM Access permission set assigned to all
- Sales Manager profile (same as above, with custom page layout for manager-view Opportunity pages)
- System Administrator profile (IT and Salesforce admin team only)
Permission Sets:
- Inside Sales Access (add Leads module Create/Edit, email templates)
- AE Full Access (add Contracts module, Quotes, custom pricing fields)
- Marketing Access (add Campaigns Create/Edit/Delete)
- Manager Reporting (add report folders access, forecasting tools)
Role Hierarchy:
- VP Sales (top)
- ? Regional Sales Manager (West), Regional Sales Manager (East)
- ?? Account Executive (West 1-5), Account Executive (East 1-5)
- ?? Inside Sales Rep (West 1-5), Inside Sales Rep (East 1-5)
OWD set to Private on Accounts and Opportunities. Each rep sees only their own records. Regional Managers see all records in their region. VP sees all records. Sharing rules added to allow AEs and their supporting ISRs to see each other’s records when working a shared territory.
How long does it take to see ROI from Salesforce?
Most organizations see measurable ROI from Salesforce within 6-12 months of go-live, assuming the implementation was done correctly and adoption is active. Early wins typically come from pipeline visibility (fewer deals falling through the cracks) and time savings from automation (fewer manual follow-up reminders). Larger ROI gains – from better forecasting accuracy, improved win rates, and shorter sales cycles – typically take 9-18 months as the system accumulates enough data to reveal patterns. Companies that invest in change management alongside the technical implementation consistently reach ROI faster than those that treat it as a pure software deployment.
What’s the biggest mistake companies make with Salesforce?
The most common mistake is configuring Salesforce to match a generic best-practice template rather than the company’s actual sales process. When the CRM doesn’t reflect how the team works, reps build workarounds and CRM usage becomes performative – they update it because they have to, not because it helps them. The second most common mistake is under-investing in data quality from the start. Importing dirty, duplicate, or incomplete data as a “we’ll clean it up later” plan almost never results in cleanup – the bad data compounds and eventually undermines trust in the system.
How many users does Salesforce work well for?
Salesforce scales from individual users to enterprise organizations with thousands of seats, though the right tier and configuration differs significantly by team size. Small teams (under 10 users) benefit most from simplicity – stick to standard features, avoid over-customization, and prioritize adoption over sophistication. Mid-market teams (10-100 users) need more process definition, automation, and reporting structure. Enterprise implementations require dedicated admin resources, governance policies, and often external implementation support. Match the complexity of your Salesforce setup to the maturity and size of your team.
Can Salesforce integrate with our existing tools?
Most modern CRM platforms including Salesforce offer native integrations with common business tools – email clients (Gmail, Outlook), calendar apps, marketing platforms, support desks, and accounting software. For tools without native connectors, middleware platforms like Zapier, Make, or dedicated integration tools fill the gap. Before assuming an integration is available, verify whether it’s native (built and maintained by the CRM vendor), partner-built (listed on their marketplace but maintained by a third party), or middleware-dependent (requires Zapier or similar). Native integrations are generally more reliable and require less maintenance than middleware-based connections.
Problem: Configuration Completed Without Documenting the Setup
Salesforce configurations built without documentation create fragility – when the admin who set it up leaves or is unavailable, nobody understands why things are configured the way they are. Undocumented customizations, workflows, and field choices become institutional knowledge that walks out the door. Fix this by maintaining a living configuration document that records every non-default setting: custom fields and their purpose, automation rules and their trigger logic, permission sets and who holds them. Store it in a shared location and update it whenever the configuration changes.
Problem: Team Adoption Stalls Because Training Was One-Time Only
Organizations that run a single training session at launch and then leave users to figure things out on their own see adoption rates decline within 60 days as habits revert to spreadsheets and email threads. New hires get no structured Salesforce training at all. Fix this by building a recurring training cadence: a 30-minute monthly “tips and tricks” session for the whole team, a structured onboarding checklist for new users (covering the 10 most common tasks), and recorded walkthrough videos for each role stored in a shared knowledge base. The best-adopted Salesforce implementations treat training as a continuous program, not a one-time event.
Problem: Reports Built for Management Don’t Help the Frontline Team
Most Salesforce dashboards are designed to give managers visibility into team metrics – pipeline totals, activity counts, conversion rates. Reps who only see management-facing reports get no personal value from the CRM, which reduces their motivation to keep data clean and current. Fix this by building personal dashboards for each user role: a rep sees their own pipeline, their overdue activities, and their win rate this quarter versus last quarter. When individual contributors see Salesforce as a tool that helps them close more deals rather than just a reporting layer for management, data quality improves significantly.