Get Agentforce Ready: Move From Profiles to Permission Sets | How I Solved It

Key business problem

Managing permissions in Salesforce can be complicated, particularly in larger environments with lots of teams that have different levels of access. Security also must be considered, as the Principle of Least Privilege (PoLP) should be paramount**. As we look at using modern tools, like Autonomous Agents, it’s extremely important that we don’t over-expose any data to any users that don’t need access to it. Everyone should see everything they need, and as little else as possible. Permissions should also be easy to manage and predictable.

Business needs, like the ability to auto-provision users with the correct level of access, require that we simplify the number of permission sets or permission set groups needed to implement and scale any permissions model. Managing permissions is further complicated because most companies don’t have a plan for how they manage permissions. Over time they collect more and more profiles with more and more permission sets. Years down the road, there could be hundreds of permission sets with no plan behind them. What most of us have is so unorganized that we often find that the fastest way to deploy something new is with its own permission set, adding to the problem.

We have three distinct challenges we can solve.

1. User access inconsistency: Folks move around within a company and access is frequently cobbled together. We adjust the profile or add some permission sets. We rarely remove all access and start over. It’s common to see a user with permission sets that came from a role they had in the past, giving them access to things that aren’t needed for their current role.
2. Permission set names are uninformative: We frequently use internal jargon or role names for our permission sets. Jargon and team names can change over time, leaving permission sets with seemingly random names that don’t inform us of what’s in them. A new admin or consultant working in the org could waste hours looking through permission sets trying to find the right one.
3. There is no plan: Having no actual plan/strategy/standard for how we manage permissions is the main cause for the user management challenges we face on a daily basis. We need to develop a plan that allows user management to be easily implemented and understood.

How I solved it

I used a persona-based approach for user security, granting user permissions by assigning each user to one or more personas. Each persona gets its own permission set group. Each persona permission set group is made of three permission sets, some of which can be reused. A persona is just a way of bucketing what our users are actually doing. It’s not their job, but rather, it’s a way to group what apps they use and what objects they need to see and edit.

Pro tip: Naming conventions are your friend

I use a simple convention for persona permission set groups; for example, “Persona - Tier 1 Support” or “Persona - Marketing”. These names are very clear in two ways. First, we can clearly see who this permission set group is for. Secondly, I know the point of the permission set group is for personas. I won’t get this permission set group confused with one that isn’t migrated into the new structure. Also, the prefix of persona can be used in a list view filter. This will make it really easy to find persona permission set groups. We can approach permission sets in the same way, only we will prefix by their type. “Read - Service Apps”, “Base - All Internal Users”, and “Persona - Marketing” are all good names for permission sets.

It’s worth noting that we’re not ditching the profile. The profile is still really important because it’s the only place we can hold any type of default permission; for example, your user’s default app. There are a few other things that you might need which can only be granted in the user’s profile. A good rule of thumb is if you can grant the permission in a permission set, that’s where access belongs. If you’re building from scratch, I’d recommend starting with the out-of-the-box Salesforce Minimum Access Profile.

The permission sets:

1. Base — This is a permission set that has a wide scope. For most companies, it covers every persona. The Base permission set is for system permissions that you’d give every user in your org, such as permissions like “Run Flow” and “Lightning user” that aren’t debatable and apply to everyone. Note that there is ZERO access to an object or field here. We also would not give any permissions here that are risky, such as “Author APEX”, which gives the user significant access.
2. Read — The Read level permission set can be thought of like a UI permission set. This should be all the permissions that are needed to get access to and use an app. So here, we’ve got the App, Tabs, Objects (read only), and fields (read only) that are needed to have an app and to navigate without any error messages. If you have developers who have created amazing Lightning web components, they should use custom permissions that allow for a Read level of access and another elevated custom permission for “use” of the Lightning web component. These Read level custom permissions could also be included in the Read level permission set. Read level permission sets are also going to be reused. Consider an app like the Sales Console. Both the Marketing and Sales Personas could easily use the ‘Read Sales’ permission sets within their persona permission set groups. Two important things to remember:
   • Never add Payment Card Information (PCI), Protected Health Information (PHI), Personally Identifiable Information (PII), or anything risky/encrypted or otherwise sensitive in the Read permission set.
   • Never give update data access in the Read permission set.
3. Persona — The Persona permission set is for everything that the persona needs, but we couldn’t add in the Base or Read permission sets. This permission set will generally not be used outside of its persona permission set group. Because of this, it’s safe to add anything here that is needed by the specific user persona.

The three permission sets are then added into a persona permission set group. Here’s an example of one setup (illustrated in the image above): We have a permission set for each persona — Sales, Service, and Marketing. Note that they share the same Company Base Permission Set. The Sales and Marketing share the same Sales Read permission set, while Service Read was used only by Service. Lastly, each persona has a bespoke persona permission set with the details that it needs.

Business results

When using auto-provisioning, we can simply provision users with the persona permission set group(s) they need. User maintenance is also made easier because we can leverage tools like User Access Policies to bulk adjust users from one persona to another.

Additional maintenance is a breeze. Consider situations like when you add a new build/enhancement to your org. When you are ready to build, it’s easy to see where permissions should go because the user stories many of us are working off of start out with the persona. Consider this example: “As a Service User (or service persona), I need the ability to chat with an internal agent (Agentforce) to ask complex policy questions. I will know that I am done when the agent is available in the Service Console.” In this case, we can simply add the needed access to the service persona permission set and we’re confident that only those who need the access will get it. Any new fields that should be visible can be added to the service Read, while everything else can be added to the persona specific permission set. The Einstein for Service can also be added to the persona permission set.***

Moving profiles

We should talk about the elephant in the room. Should you reduce the number of profiles while we’re updating permissions? No. Absolutely not. Some companies do have too many profiles. If you have 25 users and 30 custom profiles, you have too many profiles. Should you deal with that issue? Sure! Resolving technical debt is good for the health of your environment. That being said, it does NOT need to happen while you’re migrating your permissions.

Profiles are harder to replace than the permissions that live inside them. Your profiles are referenced by other parts of Salesforce. For example, Lightning record pages can be activated for certain profiles. The code about which profile was activated lives in the Lightning record page. There are similar references in that aren’t easy to see for things like Page Layouts, Apps, and Experiences (Experience Cloud membership). I recommend treating Permissions Migration as an independent task. If you need to adjust which profiles you’re using, do that separately.

**The PoLP is a foundational idea in the security space. Essentially, this means that if someone doesn’t need access to a field or record, we shouldn’t show them. The minimum amount of access needed is the ideal level of access. In the event of a breach where a user’s access is compromised, we want the smallest amount of data exposed.

***I don’t recommend migrating permission sets that are part of managed packages into your new permission sets. Instead, just include the managed package’s permission sets in your Persona Permission Set Groups. This will mean that when changes are made to those permissions, your users will inherit the correct access without additional maintenance.

Do try this at home

Getting started is the hardest part! Follow these steps to make this happen in your org.

1. Identify your personas: You’ll want to sort out what personas you actually have. Spend some quality time here thinking about what apps folks are actually using and what objects are actually needed for each persona.
2. Look for any non-persona needs: There are some things that require a “Jobs-to-be-Done” approach. Tasks like “knowledge publisher” probably require that those permissions live in a permission set that is not intended to be part of a persona’s permission set group. This doesn’t mean that you shouldn’t use a persona-led model, just that you might also need a few other permission sets for true one-off permissions or functions.
3. Identify one user for each persona with the “Right” permissions: Simple as this sounds, this can be a challenge. The first persona I did this with had 11 users and across them there were seven different mixes of permission sets/profiles. Work with the business to decide what the proper access should be.
4. Create your permission sets and persona permission set group: Remember to follow (or start using) your new naming convention. I recommend creating the following (don’t bother adding anything to them, just create them):
   • Company Base — Internal: This is going to be your company-wide permission set.
   • Read — [some app name]: This is going to hold all the permissions we need for navigating around the app(s) our persona needs.
   • Persona — [your persona name]: This will be the top-level permission set that you’ll add all the permissions your persona will need.
5. Migrate your profile: In your sandbox, open your profile and, moving section by section, sort your permissions into the three permission sets that you created in the step above using this decision tree:
   • Is this a system permission that would safely apply to all of my users?
     • If yes, add to base.
     • If no, is the permission Read access (and not sensitive data)?
       • If yes, add to the Read.
       • If no, add to the Persona level.
6. Migrate permission sets: We’re going to repeat the process for each additional permission set that our “correctly provisioned user” has, as well as all the permissions sets that are in any permission set groups the user has. Do NOT do this for any permission sets that are part of managed packages.
   • Pro-tip: Moving permissions manually as I’ve described above works well, but it takes a lot of time and effort and is prone to errors. Check out Code Builder. When you look at a permission set or profile in code (XML), you can read what permissions are there and simply copy/paste them into your new permission sets. This makes auditing them and migrating into them a breeze.
7. Update your persona permission set group: Add your Base, Read, and Persona permission sets into your new persona permission set group. Be sure to add any managed package permissions in as well.
8. Testing: Once you’ve migrated all the permissions, you’re ready to do some testing! For your test user, be sure they have the new persona permission set group assigned to them and no other permission sets. To properly test, you’ll need to remove all the permissions from your profile. Once this is complete, you can test.
   • Why remove permissions from the profile instead of cloning it? Great question. There are some things that aren’t stored on the profile that reference it. Things like page layout assignments and Lightning record page activation. To ensure that we’re not creating a bug, we need to test with the actual profile and not a copy.
9. Production: Before you implement in production, you’ll need to do one more check. Look at the profile that is used by the persona that you’ve been working on. Check to see if there are any users of this profile that are a different persona. If there are, you’ll need to have that persona completed before you can implement in production. Your other users would probably be upset if you deployed a profile with no permissions and they didn’t have a new persona permission set group to help them continue to work!

Resources

• Trailhead: User Access Policies
• External site: Spotify: The JAM: Episode 1 — Squire Kershner
• Trailhead: Code Builder Basics
• Trailhead: User Story Creation
• External site: YouTube: Moving Permissions Away From Profiles: A Scalable Approach with Mike Reynolds at LC23

Want to see more good stuff? Subscribe to our channel!