Moving Your Org's Security Structure from Profiles to Permission Sets

One of the most powerful things about Salesforce is its flexible, dynamic security and permissions structure. But as more departments get excited about using Salesforce, your security structure inevitably becomes more important—and more complex. With Salesforce eventually moving user permissions out of profiles, many organizations may need to start addressing this sooner rather than later. Moving your user permissions from profiles to permission sets can give you more control and flexibility over who can see what within your org. For some organizations, the thought of making this shift is overwhelming at best and brain-meltingly chaotic at worst. But fear not—this guide can help make the process more manageable.

Before You Start
Before diving in, planning out some essentials with your team is helpful.

1. Who Really Needs to Be a System Administrator?
You should regularly revisit this question. Far fewer users often need full Sys Admin access than they currently have. With permission sets, you can give users nearly all the access they need without giving them full Sys Admin rights.

2. List Out Your Different Departments, Teams, and Groups
Make a list of every department and team that uses Salesforce and those that might use it in the future. Then, list the users within each of these departments. This will help you identify groups needing slightly different permissions and any sub-departments requiring distinct access. Planning with future teams in mind will also make their onboarding easier.

3. Identify Commonly Used Objects Across Teams
Think through which objects (both standard and custom) are shared across departments, like Contacts, Accounts, or custom objects tied to general workflows. Identifying these now will help when we need to consider page layout impact.

Let’s Dive In: A Step-by-Step Guide

1. Create a “Blank Slate” Profile
Start by creating a profile with no permissions assigned—a blank slate. This will act as a common profile that you can assign to all users, with permissions controlled by permission sets and permission set groups. You will need a different profile per license type (if you have Platform users, they will still need a separate profile).

2. Create Permission Set Groups by Team
Create a permission set group for each group you identified. To keep things organized, use clear, descriptive names that align with each team's function. Ideally, your naming convention would align across these areas (Perm Set Group, App, Public Group, Record Pages, etc.).

3. Define Permission Sets for Functional Access
This is the heart of the process. Create permission sets that cover the access each team needs. If multiple teams need access to the same function, like “Event Management,” create a single permission set and assign it to each relevant group. This way, permissions stay streamlined, and cross-departmental access remains consistent. Assign all the permission sets a group
may need to the appropriate permission set group. This is a great time to reevaluate the team’s permissions. Consider questions like “Does Mark really need Modify All access to that object?” or “Do all our Admissions Counselors need to create ?”

4. Assign a Unique App per Group or Department
Each group should have its app within Salesforce to streamline their workflow. Ideally, team members should be able to do their entire job within a single app. This approach improves user adoption, as they’ll only see what’s relevant to their role.

5. Customize Lightning Record Pages for Shared Objects
This step is key before consolidating everyone to the same profile. Since page layouts are still tied to profiles, leveraging Lightning record pages with dynamic forms allows you to show customized content based on apps and record types. The simplest way is to assign one Lightning record page per app, but you can get more granular by using custom permissions to control what each team sees. Try not to overcomplicate this piece. If everyone can be on the same page layout (with just field-level security impacting user’s views), stick with that.

6. Create a Public Group for Each Team
If you haven't already, set up a public group for each team. Public groups are essential for sharing records, reports, and dashboards, and you’ll likely have more groups here than just those with different permissions. This also helps organize visibility across shared resources.

7. Enable Field-Level Security for Permission Sets during Field Creation
Finally, switch your org settings so that field permissions can be assigned through permission sets rather than profiles (Setup>User Management Settings). This will make it easier to maintain the structure you’ve developed, as new fields can be added directly to the relevant permission sets. Remember to create a permission set with View and Modify All Data and assign it to all Sys Admins, then grant this permission set access to any new fields to ensure
admins maintain metadata access. By the end, each user on the same license type should be on the same profile and have at
least one permission set group assigned to them. While there will certainly be nuances within each org, the hope is that understanding what permissions a user has and why becomes much clearer with this structure in place.

Wrapping Up
Moving from profiles to permission sets is a significant shift, but with the proper planning and setup, you’ll have a far more flexible and scalable security model. This setup not only empowers your users by giving them access to what they need but also makes it easier for you to manage permissions as your org grows. Take it one step at a time and watch your organization’s security model transform into a streamlined, manageable machine.

Still feeling your brain melt? We’re here to help!