Salesforce Users, Profiles, and Permission Sets

Published 26/09/2025 & Updated 15/09/2026By James Winter

An administrator assigns keys, shields, app access, and identity permissions to users beneath a role hierarchy

In How the Salesforce Platform Works, you explored Salesforce as a platform: its structure, editions, environments, and the Lightning Experience. Now we move from the big picture into the foundations that control who uses the platform and what they can access.

Users, profiles, permission sets, and roles are the mechanisms that shape every Salesforce implementation. Getting this layer wrong causes problems that are surprisingly hard to trace. In project work, I regularly see situations where a feature worked correctly in testing but failed silently in production, this is not because the logic was wrong, but because field-level security or sharing settings weren’t aligned with real user access. This is one of the most common sources of “the data looks wrong” incidents, and it almost always traces back to a security model that was created and assigned to users in a hurry.

🔧 User Management and Security

Ensuring that the right people have the right access to the right data is a critical aspect of Salesforce administration. Salesforce provides a robust security model that allows you to control access at various levels, ensuring data integrity and compliance.

👥 Users in Salesforce

In Salesforce, a “user” is any individual or system identity that is authorised to access the Salesforce platform. A user may authenticate directly with Salesforce or through an external identity provider such as Single Sign‑On (SSO). Regardless of how they authenticate, each user has a licence, a profile, and permissions that determine what they can see and do. Users can be categorised into several types, each serving different roles within an organisation:

Employees: These are internal users who utilise Salesforce to perform their daily tasks, such as sales representatives, customer service agents, and marketing professionals. They interact with Salesforce to manage customer relationships, track sales activities, and analyse data.
Partners: External users who collaborate with the organisation, such as resellers, distributors, or service providers. Partners typically access Salesforce through a partner community, allowing them to engage with the business, share information, and manage joint opportunities.
Customers: In the context of Experience Cloud, customers can also be users who log in to access self-service portals, communities, or forums. This allows them to interact with the organisation, find information, submit service requests, and engage with other community members.
Integration Users: These are non-human users created specifically for system integrations. Integration users facilitate the connection between Salesforce and other systems, enabling data exchange and process automation. They are often used for API access and are assigned specific permissions to ensure secure and efficient data handling.

Each user in Salesforce is assigned a unique username and requires a licence to access the platform. The type of licence determines the level of access and functionality available to the user, ensuring that they have the appropriate tools to perform their roles effectively.

🍎 Core User‑Management Capabilities

Creating, Updating, and Organising Users

User creation (single and bulk) — Add users individually, use Add Multiple Users, or load them via Data Loader for large onboarding waves.
Editing user details — Update roles, profiles, time zones, locale, email, manager, and feature access as people change jobs or responsibilities.
Assigning licences and permission sets — Control what each user can access by combining user licences, feature licences, and permission sets.

Controlling Access and Availability

User deactivation and freezing — Freeze a user to block login temporarily or deactivate them when they leave the organisation. Users cannot be deleted, so deactivation is the long‑term state.
Login restrictions — Set login hours and login IP ranges on profiles to control when and where users can log in. The separate Login Access Policies setting controls account access for Salesforce admins and publishers.
Session Management — View and revoke active sessions, enforce session timeouts, and manage session security levels.

Monitoring and Troubleshooting

Login history and login forensic data — Review successful and failed logins, identify unusual access patterns, and troubleshoot authentication issues.
Password management — Reset passwords, unlock users, and enforce password policies.
Health checks for user access — Identify users with excessive permissions, unused licences, or misaligned access.

By effectively managing users and their access, organisations can ensure that Salesforce is used efficiently and securely, supporting business operations and growth.

Trailhead Module Recommendation: For the overal security of your org, look at the Security Basics module. The User Management module shows how to set up users and control how they can view or edit your business data. It would be useful to follow this up with User Authentication to secure your org with multi-factor authentication, My Domain, and single sign-on.

Security BasicsEducate your users, protect your Salesforce org, and encourage a culture of security.

User ManagementExplore how to set up users and manage their access to business data effectively with this user management guide…

User AuthenticationBoost org security with multi-factor authentication, My Domain customisation, and single sign-on setup for a robust…

🧑‍💻 Profiles, Permission Sets, and Roles

Within Salesforce’s user management framework, Profiles, Permission Sets, and Roles play a pivotal role in defining and controlling user access and permissions. These components work together to maintain data security and ensure users have the appropriate level of access to perform their tasks effectively.

👤 Profiles

Every Salesforce user has one profile. Profiles can still contain broad permissions, but in a permission set-led design their main job is to provide the minimum baseline and settings that still depend on profiles. Key capabilities include:

Object-Level Access: Profiles control access to Salesforce objects, specifying which objects a user can view, create, edit, or delete. This ensures that users only interact with the data relevant to their roles.
Field-Level Security: Within each object, profiles can restrict access to specific fields, allowing users to view or edit only the fields necessary for their tasks. This granular control helps protect sensitive information.
App and Tab Access: Profiles determine which apps and tabs users can access, tailoring the Salesforce interface to their specific needs and responsibilities.
System Permissions: Profiles include system permissions that grant users the ability to perform certain actions, such as exporting data or managing reports.

🔐 Permission Sets

Permission Sets offer much of the same control as Profiles, providing an additional layer of flexibility in Salesforce’s security model. They allow for more granular and dynamic permission management. Key aspects of Permission Sets include:

Multiple Assignments: Unlike Profiles, administrators can assign multiple permission sets to a single user, making it easier to combine different access levels as needed. Permission Sets are additive, meaning they only add permissions and cannot remove or restrict permissions that exist in the profile.
Granular Control: Permission Sets offer more granular, flexible, and scalable permission management, enabling admins to assign and layer permissions without creating numerous profiles.
Flexible Assignment: Permission sets can be assigned individually, grouped by job function, given an expiry where supported, or managed through an approved access-automation process without changing the user’s profile.
Permission Set Groups: These allow administrators to bundle multiple permission sets into a single group, streamlining the assignment process and making it easier to manage complex permission structures. This feature enhances scalability and simplifies the management of user permissions.
Current Direction: Salesforce is focusing access-management guidance and enhancements on permission sets and permission set groups. Migrate deliberately: map access to job functions, test with representative users, and remove profile permissions only after the replacement assignments are proven.

Trailhead Module Recommendation: The Data Security module shows how to control access to data using point-and-click security tools then look at Permission Set Groups to understand how to bundle permission sets for a job function:

Data SecurityControl access to data using point-and-click security tools.

Permission Set GroupsLearn how to efficiently bundle permissions for job roles using Permission Set Groups in Salesforce for secure data…

🏦 Roles

Roles in Salesforce help govern record-level access and are organised in a hierarchy based on data visibility needs. Users higher in the hierarchy can gain access to records owned by or shared with users below them, subject to object permissions and the object’s hierarchy behaviour. Key aspects of roles include:

Record-Level Access: Roles determine which records a user can view or edit, based on their position in the role hierarchy. This access is crucial for maintaining data visibility and collaboration across teams.
Hierarchical Structure: The role hierarchy does not need to copy the organisational chart. Combine job titles when their record-visibility needs are the same, and add roles only for a defined access or reporting purpose.
Collaboration and Reporting: Roles enable effective collaboration by ensuring that team members have access to the records they need. They also support reporting by allowing managers to view data across their teams.

By effectively managing profiles, permission sets and roles, organisations can ensure that users have the appropriate access to Salesforce features and data, enhancing security and productivity.

🔒 Other Security Concepts

In addition to Profiles, Permission Sets, and Roles, Salesforce offers several other security concepts that help manage data access and ensure compliance with organisational policies. These concepts provide additional layers of control and flexibility in managing user access.

Record Access

Organization-Wide Defaults (OWD): Organization-Wide Defaults establish the baseline level of access to records for all users within the Salesforce org. They determine the default visibility of records, such as whether records are public, private, or read-only. OWD settings are crucial for setting the foundation of data security and ensuring that sensitive information is protected by default.
Sharing Rules: To let teams collaborate beyond the Organization-Wide Defaults, use sharing rules to grant additional record access to users in public groups, roles, or territories. Rules select records by ownership or field criteria. To include specific individuals, add them to a public group and use that group as the recipient.
Manual Sharing: Manual Sharing allows individual users to share specific records with other users on an ad-hoc basis. This feature provides flexibility for users to collaborate on specific records without altering the overall security model.

Monitoring and Compliance

Audit Trail and Monitoring: Salesforce offers audit trail and monitoring tools to track changes made to data and configurations. These tools provide visibility into user actions and help identify potential security issues or compliance violations.

By leveraging these security concepts, organisations can create a comprehensive security framework that protects data, supports compliance, and facilitates collaboration across the Salesforce platform.

📏 Best Practices for Managing Access

Effective access management is crucial for maintaining security and ensuring that users have the appropriate permissions to perform their roles. Here are some best practices to consider:

Implement the Principle of Least Privilege: Assign the minimum necessary access to users, ensuring they have only the permissions required to perform their tasks. This minimises the risk of unauthorised access and data breaches.
Use Profiles, Roles, and Permission Sets Appropriately: Assign users a minimal baseline profile for foundational permissions, use roles to define record-level visibility hierarchies, and leverage permission sets and permission set groups to grant flexible, task-specific permissions without creating excessive profiles, ensuring a scalable and secure access management model
Implement Permission Set Groups: Bundle related permission sets into groups for easier assignment to users with common roles, simplifying permission management and enhancing scalability.
Regularly Audit User Access: Conduct scheduled reviews to remove unused permissions and update access when job requirements change. Use User Access Summary and assignment reports to understand effective access, and Setup Audit Trail to investigate relevant configuration changes.
Define Clear Organization-Wide Defaults (OWD): Set the baseline level of access at the org level, considering security and collaboration needs. OWD settings establish the default visibility of records and ensure sensitive information is protected.
Use Sharing Rules and Public Groups for Flexible Access: Grant exceptions to OWD through sharing rules based on roles, criteria, or groups, allowing for dynamic customisation of access.
Enforce Multi-Factor Authentication (MFA): Salesforce requires MFA for internal user-interface logins to active production orgs and sandboxes. Privileged users, including admins, must use phishing-resistant verification methods under the current MFA requirements. The practice-org chapter explains who qualifies, the rollout schedule, and the exemption for free practice orgs.
Implement SSO: Single Sign-On (SSO) can strengthen Salesforce security by consolidating user authentication into a single, centrally managed process. It eliminates multiple credentials across systems, ensures the use of secure authentication standards, and gives administrators centralised control over user access and monitoring.
Restrict Logins by IP and Time: Limit login access based on IP ranges and login hours in profiles to reduce the risk of unauthorised access.
Automate Access Management Carefully: Where available and appropriate, use User Access Policies to assign or remove permission sets, permission set groups, package licences, and related access from defined user criteria. Keep an approval and exception process for privileged access rather than hiding access logic across unrelated Flows or Apex.

By following these best practices, organisations can ensure that Salesforce access is managed securely and efficiently, supporting both operational needs and data protection.

🧾 Minimum evidence for an access change

A production access request should leave enough evidence for somebody else to review it later:

Business reason and owner — what job does the access enable, and who approved that need?
Requested capability — name the permission set or group rather than asking for a copied user or a broad profile.
Scope and duration — state which environment, data scope, and expiry apply, especially for privileged or temporary access.
Validation — test that the user can complete the intended task and cannot cross a sensitive boundary.
Review or removal point — link access to a role change, contract end date, or periodic recertification.

This small record turns least privilege from a design slogan into an operational control.

Trailhead Module Recommendation: The Protect Your Data in Salesforce is a hands-on project to guide you through securing your Salesforce org by controlling login and data access for users

Protect Your Data in SalesforceLearn how to control login hours, IP ranges, create users, sharing rules, and more to secure your Salesforce org

✅ Checkpoint: map, onboard, and offboard a persona

This chapter’s evidence is three artefacts: a persona-to-permission matrix, a completed onboarding checklist, and a completed offboarding checklist, all rehearsed on one spare test user in your practice org. The three sections below produce them in that order.

📋 Map each persona to its access

An individual access request tells you why one person needs a permission. A persona describes a repeatable job, such as someone submitting equipment requests or a team lead reviewing them. A persona-to-permission matrix gives you a starting point for the next joiner and a list of grants to revisit when somebody changes jobs.

Use the proposed Equipment Request app as the design example in the matrix below. You will meet its objects and fields in the next chapters; draft the access decisions now, then add the observed results as you build. The permission sets and sharing rules named here are the ones Salesforce Admin Essentials creates (the build calls the requester persona Staff); none of them exists in your org yet.

Access decision	Requester	Manager	IT	Finance	Temporary reviewer
Job	Submit and track their own requests	Review and decide their team’s requests	Fulfil approved requests	Report on cost across all requests	Read an agreed set during an absence
User licence	Salesforce	Salesforce	Salesforce	Salesforce	Salesforce
Profile	Minimum Access – Salesforce	Minimum Access – Salesforce	Minimum Access – Salesforce	Minimum Access – Salesforce	Minimum Access – Salesforce
Permission set	Equipment Request — Staff: create, read, and edit requests; edit Equipment Type and Business Justification only	Equipment Request — Manager: read and edit; edit Status and Rejection Reason only	Equipment Request — IT: read and edit; edit Status, Expected Delivery Date, and Estimated Cost	Equipment Request — Finance: read only, limited to Status, Equipment Type, Estimated Cost, Days Open, and Weekdays Open	Equipment Request — Finance is enough; don’t create a fifth set for a short cover
Record access (Private baseline)	Their own requests	Their team’s requests through the role hierarchy, with Grant Access Using Hierarchies left on	Every request, Read/Write, through the All Requests to IT sharing rule to the IT public group	Every request, Read Only, through the All Requests to Finance sharing rule to the Finance public group	Added to the Finance public group for the cover period, removed on the end date
Allowed check	Edit their own open request	Change Status on a team member’s request	Set Expected Delivery Date on any request	Open any request from the cost report	Read a shared request
Denied check	Read another team’s request, or edit Status	Read an unrelated team’s request	Edit Business Justification	Edit anything	Edit a request, or open one after the cover ends

The licence is a capability boundary, not a permission assignment. This example uses the Salesforce licence available for your practice user; it is not a purchasing recommendation. For a real custom-app-only job, assess the available Platform licences against the full requirement. Check Salesforce’s user licence guidance before selecting a licence, including any additional feature or permission set licences needed.

Keep the two access layers separate: permission sets grant object and field capabilities; ownership and sharing determine which records those capabilities apply to. A read-only sharing grant cannot remove edit access obtained elsewhere. For each row, record the business owner, approved scope, start/end dates, exact assignments, and any exception. The Record Access chapter teaches the sharing mechanisms later in this section; carry your matrix forward and test its predictions there.

📥 Onboarding checklist

A new user is ready when two things are true: they can do the job you agreed, and somebody owns that access. This checklist is for an internal employee. External users and integration users need their own licence and login design, which this chapter doesn’t cover.

It is written for a real onboarding. Rehearse it in your practice org with the spare test-user licence you freed up in the previous chapter: keep using your own administrator account for the admin steps, give the test user an invented name and an email inbox you control, and where a step involves the real person, do the rehearsal version the step describes. For every check, record one of Passed, Failed, Not run, or Not applicable, with a reason.

Confirm the job and who approves it. Pick one row of your persona matrix. Write down who approved the access and the date it starts. If this person needs anything beyond the row, list it as an exception rather than widening the row. Don’t copy an existing colleague’s assignments: look at them to see what is normal, then grant only what the row says.
Create the user. In Setup → Company Information, check that a Salesforce licence is free. Then go to Setup → Users → Users → New User, fill in the details, and choose the licence and a profile that matches it. For this practice user, choose Salesforce and Minimum Access – Salesforce. Check the locale and time zone. Salesforce’s guide to adding a user covers the username rules and the activation email. Don’t write the password anywhere in your evidence.
Grant only the approved access. Assign the permission sets or permission set groups, the role, and any public group or queue memberships from the matrix row, and write down exactly what you assigned. If the Equipment Request permission sets don’t exist yet, leave that part open: your first check is simply that the user can log in with the minimum profile, and you add the job access as the app is built. Don’t give the user an administrator profile to make things work in the meantime.
Confirm the first login and one check. In a real onboarding, the person activates the account from the email, sets a password, registers MFA, and logs in themselves. Once their job access exists, ask them to try one allowed action and one denied action from the matrix and tell you what happened, or sit with them while they do. Don’t log in as them to do it for them. In your rehearsal, you are the new user: open the activation email in the inbox you control, set the password, register MFA if your practice org asks for it, log in with the test user’s own credentials, and do the two checks. Write down what you expected and what happened. A check you ran from your administrator session doesn’t count.
Write the handover, and set a review date. In a real onboarding, you tell the person where the app is, who to contact for help, and when their access will be reviewed, and you don’t close the handover until every required job check has passed. In your rehearsal, write that note as if you were about to send it, record the review date against the matrix row, and leave the app checks marked Not run until the app exists.

📤 Offboarding checklist

Offboarding is two jobs: stopping the person’s access, and moving their work to somebody else. Before you touch anything, write down two things: the time their access is to end, and who takes over their work. Salesforce is usually one of several systems the person can sign in to, so agree the cutoff with whoever runs your organisation’s sign-in service.

List what depends on this user. Note the records they own, any approvals waiting on them, scheduled jobs that run as them, dashboards that run as them, and any integration that logs in with their identity. Against each one, write who takes it over. Don’t solve a dependency by giving the replacement more access than the job needs. An integration running under a person’s login is a problem to fix rather than hand on: move it to a dedicated integration user with its own API-only licence and credentials, not to the replacement’s account.
Stop their login at the agreed time. Deactivate the user if Salesforce lets you. If something blocks deactivation, freeze the account instead, and clear the blockers in the next steps. Freezing stops the person logging in, but it doesn’t free their licence; only deactivation does that.
Revoke sessions and app access. Blocking the login isn’t enough on its own: an open session or an authorised app can keep working after it. End any active sessions, and with the integration owner, revoke the user’s app authorisations through the Connected App or External Client App settings. Ask the sign-in service owner to remove the person there too. A password reset is not offboarding.
Move the work. Transfer the records and the dependencies from step 1 to their new owners, then check that the work still runs: open a transferred record, run the scheduled job, view the dashboard. Deactivating a user doesn’t move any of this for you. Salesforce’s considerations for deactivating users lists the things that block deactivation and the side effects to expect.
Deactivate and tidy up. Once nothing blocks it, go to Setup → Users → Users, edit the user, and clear Active. Remove permission set and permission set group assignments and group memberships that no longer serve a purpose, check any extra licences they held, and confirm the user licence shows as available again. Leave the user record in place: Salesforce users are deactivated, not deleted, so the history stays.
Check, then close the record. Confirm the user record shows as inactive (or frozen), that Session Management shows no sessions for them, and that Login History shows nothing successful after the cutoff. In your rehearsal, you can go one step further and attempt a login with the test user’s own credentials to see it refused. Confirm the new owner can do the transferred work. Write down the cutoff time, what you did, what you saw, and anything still open with the name of who owns it. If deactivation is still blocked, leave the account frozen, keep the checklist open, and name who follows it up.

To rehearse this, freeze and then deactivate only your spare test account, confirm its login fails, and reactivate it when a later exercise needs it. When you bring it back, restore only the assignments the next test needs, and note that you did. One test account is enough to work through the personas one at a time: remove the previous persona’s grants before you set up the next. Keep the matrix, both completed checklists, and any app checks still marked Not run together with your access-change record. That is the evidence this chapter adds to either journey.

🎯 Final Thoughts

The security model is less about ticking configuration boxes and more about understanding how each layer interacts because when something goes wrong, the symptom is almost never obvious. A user reports they can’t see a record. An automation fails silently. A report shows different numbers for different people. All of these can trace back to the access layer, and finding the cause quickly depends on knowing how profiles, permission sets, roles, and sharing work together rather than in isolation.

In project delivery, I have found the user security model is one of the few areas where early investment pays off disproportionately. Getting it right before automation and integrations go live means far fewer incidents later. Getting it wrong, even slightly, tends to surface in ways that erode user trust in the platform and take significant time to unwind.

🚀 Next steps

With users and access in place, the next layer to understand is the data itself. In Data Model, you’ll explore objects, fields, relationships, record IDs, and namespaces — the structural foundations that everything from automation to Apex builds on. A clear security model also makes the data model chapter more concrete: you’ll start to see how field-level security and sharing decisions connect directly to object and relationship design.

📚 Resources