Description
In this 30-minute session, get expert advice on safely and seamlessly transitioning from Profiles to Permission Sets in Salesforce. Join Salesforce development expert Eric Kintzer (SFDC System Architect, Helix), as he dives into best practices for deploying Profiles and Permission Sets — as well as tackling some of the common issues you may face during the process.
Transcript
Great. Thank you very much, Amy, and welcome everybody.
Let me introduce myself.
I have been working in the Salesforce ecosystem since two thousand and eight.
I'm currently the Salesforce architect at Helix, a genomics company, and I've been working with gear sets since twenty sixteen.
And have been one of their DevOps leaders for a few years now helping influence the product and its direction. So some features that or and or bug fixes that you work with if you use gear set may have come from me.
Okay. So why are we having this webinar?
Well, Salesforce dropped an announcement, a few releases ago, saying that permissions on profiles are gonna be retired in spring of twenty six.
And when that announcement came out, A lot of admins and developers went, oh, this is gonna be work.
And in fact, it will be work.
So we're gonna dive into some of the tasks and steps you're gonna need to do in order to move from permission based profiles to permission sets.
So let's what are we gonna talk about today? A little bit of introduction, just to level set how this all fits into the DevOps process.
Some strategies about migrating and some tips to follow, issues that you're are likely to encounter and how to deal with them. And then we've got a whole bunch of, helpful links, with QR codes to follow that will certainly help me and will help you as well.
Okay. So profile, collection of permissions and other stuff generally sort of user based focused.
Permission set. These are only permissions, and they tend to be task based. Like, can you run can you run reports or manage folders or things like that or crud on objects. And then permission set groups are collections of permission sets.
And they should be thought of more as a persona. So hopefully, if you work with Salesforce, you know all this stuff, and let's just move on.
Okay. So how does this all work in the DevOps process?
Well, for profiles, as you know, it's one each profile is one file to one XML file.
And it has the likelihood of possibly being updated by two or more admins or devs at the same time.
You can't really package these.
And and also let me go back to the update with two more admins This means you get merge conflicts if you're using version control. Or if you're not using version control, you possibly get stuff wiped out if you're, deploying from org to org directly. It's one developer smashing the other developer's permissions.
Profiles, because they've been around for a long time, we've all gotten used to them, and there's sort of an easy way to sign field level security to them.
It's the path of least resistance, and at least in my experience, you can get sloppy with security. You basically grant too many field permissions or object permissions to users who really don't need them or shouldn't have them.
Now, with permission sets, you get a you have a smaller file, so it's way less likely at merge conflicts.
They're definitely patchable. So if you're moving in the second generation packaging model, you can include them. As you if you do install managed packages, most of them, deploy permission sets along with the package components. So it's already the sort of the right strategy for packaging.
And permission sets and permission set groups forces you to architect in a cleaner way. You have to think about the building blocks of what a user in a given persona or role at your company really what permissions they should have versus giving them too many permissions.
So how do we sort of go about dealing with this migration? So let me just call attention on the lower left of the slide here.
To a YouTube video via Salesforce MVP called Luis Laki, who who has a really good video on how to organize your permission set groups.
Sorry. I'll organize your permissions into permission sets and then the permission sets into permission set groups. I'll just sort of touch a little bit about what she says, but she's got a, very detailed discussion of this, which I encourage you to follow.
Okay. So building blocks. So you wanna start with driving towards the minimum number of profiles, possibly zero.
Into many custom profiles.
The principle of least privilege. That means you sort of start off with a user having no permissions and then you add permissions and through permission sets and correspondingly permission set groups to that user.
So start with nothing and then add.
Now, you wanna name your permission sets differently than profiles, permission sets or features or tasks that you can do.
Not you shouldn't have a permission set called the customer service agent permission to because that's a user role, not a set of tasks.
A really good idea is to add custom permissions into relevant permission sets. Now, why do you wanna do this? It's because in lightning record pages and in formulas and validation rules and things like that, you can test for custom permissions. You can't test for whether a user possesses a permission set.
So if you wanna know if a user is capable of doing something and you wanna restrict some function, some action, some page component, visibility, etcetera, put the custom permission into the relevant permission set and then you can test that in your, lightning record pages, formulas, entry conditions to flows, even Apex code.
Group your permission sets into personas, those are the permission set groups.
And, this is definitely gonna cause work for people. You gotta look at your entry conditions, forming those validation roles, mock test users that might be testing the profile name against a value to decide whether something can be done or you're mocking users in Apex tests and you're mocking them with specific profiles. Well, if you're gonna get rid of profiles and move towards a minimum number of profiles, all those entry conditions, etcetera, formulas, what have you, they aren't gonna work anymore.
So you gotta start thinking and dealing with that.
Okay. What's the migration strategy?
Well, a a simple margin migration strategy is to use the, app exchange product called the user access and permissions assistant basically converts a profile to a permission set.
It's a blunt instrument.
He I can imagine being used if you don't have time or you don't care that much or you're in a panic, but it's definitely not a sort of architect approach to going forward and just sorta get you out of one hole and put you in another set of tech debt.
Another approach, and this is what we sort of recommend here, is to do it stepwise.
Let's look at this picture here. On the left hand side, let's imagine you have a bunch of legacy profiles.
Two of them are customer service related the agent and the manager.
Three of them are sales related, lead development, salesperson, sales director, So the first consolidation sort of do sort of to avoid messing stuff up and doing the least amount of potential harm to your running org is to consolidate the legacy profiles into a fewer number of profiles.
So you would then take the two customer sir the customer service agent, a customer service manager profile, create a new profile customer service, you don't wanna rename profiles because it's complicated to deploy. In fact, virtually impossible to deploy.
You wanna create a new customer profile, sorry, a customer service profile, and then us create the permission set groups that are for the customer service manager and for the customer service agent, and then assign those to the users who then would be migrated to that new consolidated profile. And then similarly do it for the three legacy sales related profiles to a new sales profile. So that's what a step one. That's reducing the scope of the problem from, in this case, five profiles to two profiles.
Then the next step is to consolidate down to a single baseline sort of my company profile.
Or if you wanna be sort of really print least, access principles, go straight to the minimum access Salesforce profile.
Now, since you've already got your permission set groups that you've tested and worked with, in the first consolidation, you simply need to reassign the users to the My Company baseline profile or the minimum access Salesforce profile.
And everything should be fine.
And now you have migrated from five profiles to one custom profile or possibly zero custom profiles.
So that's what what Salesforce wants you to do. Getting there, it's gonna take iterations.
I should also point out there will be some profiles that you just will have for sure. They're all out of the box profiles.
System administrator will exist.
Every experience cloud gets a profile.
There's guest user profiles you're using platform licenses as a profile, the Salesforce API only system integrations, the mouthful profile will also be present and the chat or free one. And I'm sure I'm forgetting some, but there will be, legacy out of the box profiles that you still will have.
I wouldn't recommend sticking with the standard user profile or the contract manager file or the marketing user profile and also out of the box, I would avoid those, entirely.
Okay. Now we've also got integration users.
So here's an example. Let's say you've got four integrations into your org, one from Congo, one from Postbot. You got a custom one for your own intra company applications, maybe using a CTI one from Talkdesk.
More likely than not, those integration users are using either the system administrator profile, yuck, bad idea, or some custom integration user profile, which probably has way too many permissions granted to those integrations.
So the right strategy for these guys, and these are more you can pick these off one by one is to migrate those integration users to the minimum access Salesforce profile or the Salesforce API only system integrations profile.
Create a permission set that, either is taken directly from the vendor which is the ideal solution or taken from the vendor and enhanced for what you need, and then assign those permission sets to the various integration users that you have. Now this assumes, and this is something I recommend all the time that every integration has its own dedicated user.
It helps in traceability.
Salesforce made this financially more feasible by adding five free integration user licenses to every enterprise edition and, above or, and then the other ones can be, additional ones can be purchased at a nominal, well, reasonably nominal cost.
Anyway, so this gets you out of, custom integration user profiles and really reduces those third party integrations into your system to the bare minimum of permissions that they need to function, which is, of course, best for security.
Okay. Now, somebody might be thinking, hold on to their partner.
Profiles aren't going away. Just permissions on profiles. Why can't I keep all my profiles? Why do I have to consolidate them down to one or zero custom profiles?
And, you know, it's technically you're right. You don't, but think about it from an administrator's point of view, which is you.
Why do you wanna have to manage two sets of complexity about provisioning users?
What profile they get and what permission set groups do they get? It's far easier to make the entire migration and just think about security through permission sets and permission set groups, and just forget about profiles. Every user gets either minimum access Salesforce or your custom baseline profile, and that's it. That's all you need to know. Very easy provisioning.
Now there are gonna be issues that you will face, and these have to do with Salesforce limitations and or design decisions.
So one is assigning field level security.
The current user interface makes it super easy to assign new custom field security to profiles but doing it in permission sets requires you to sort of jump the workflow out into a different, user interface.
But Salesforce has solved this in setup. There's user management settings. You can turn a toggle on that will change your custom field levels security for new custom fields to a permission set nice user experience rather than the profile waste one. So I'm when you're ready to start to move, make this toggle switch.
Default page layouts.
Permission sets don't let you set up default page layouts. The reason for that is it's sort of a you could have one permission set giving you pay default page to that a and another permission set assigned to the same user give you default page layout B, and the system has no way of knowing which is the right one to use.
So you can't do this. So you need to think about redesigning or enhancing your lightning pages to use more dynamic actions dynamic forms, and the general app builder, which lets you create multiple apps with multiple components on the page.
So the users don't have to, be assigned to full page layouts. They get the right page layout based upon the permission sets that they've been assigned and the custom permissions that are in those permission sets that allow you to make these decisions.
Default record type. If you select new on an object, you get prompted with a set of possible record types that you're enabled to use. You can't set this in permission set, same reason as the previous example.
How do you get around this? A lot of people may not know this, but the user can define their default record type in my settings so they can avoid the dialogue all the time.
And admins can replace the new button with custom new functionality that based on other information about the user and the permission sets that they possess, tailors the experience to the right default record type.
API users, once creating new records from third party systems, you can use before safe flows or triggers to coerce the record type particularly if the running user is identifiable to that API. IE possesses a permission set. Sorry, a custom permission, in a permission set.
Another problem is if you have record based app, lightning page assignments.
When you do a lightning page, you can assign it to a pro sorry, a word default, to an app default, or to a profile plus record type, plus app. Well, if you're moving all your custom profiles down into one or zero, you need to think about how to do this in a different way.
Now one approach is, of course, assign all the record types to the class profile that might work perfectly fine.
Or You can sort of think laterally and create more apps, perhaps one per record type, and then use the permission sets to grant access to the app. So instead of having lots of app or sorry, one app with many record types, you have many apps one per record type.
Finally, issues is login IP and hours restrictions.
So there's this is a profile based l item. It's not in permission sets at all.
And Salesforce is saying you right now, if you have an org with different login policies, you'll still need profiles for each use case.
This would be a great time to revisit if you've created multiple profiles for different login policies to see whether you really need that anymore.
And maybe Salesforce will come up with a solution before spring twenty six that'll make this more tractable.
Okay. Final tips user access policies mentioned here on the left hand side. So when you create a user, you need to assign that user to a profile, a role, permission set groups, and public groups.
And right now, that's been either done you can either create your own custom automation for that, you do it manually, your your onboarding systems might have scripts to set this automatically.
But now Salesforce has reduced in public beta user access policies that essentially defined rules, so based on characteristics of the user record, can set the public groups, role, profile, and permission set groups, and it's all point and click configurable.
So this is super useful, and I'd recommend taking advantage of that.
The other QR links here, which, you'll be able to look at either now or, in the published version of this presentation.
The product manager for user management, Cheryl Feldman, has a blog post that is basically the Salesforce's strategy here. Definitely need to read that. There's a trailblazer group, that you can join to sort of ask questions and follow what's going on.
And then, at the Shell Feldman again, the product manager, she's got a LinkedIn, profile that's public.
Where she posts all sorts of interesting information and direction is what's gonna happen here.
There's the YouTube video I already mentioned from the Salesforce MVP.
There's a tool called perm comparator, which is a free tool that lets you see what permissions up to four different users have and what's they share and what's different that will help you sort of understand, how to configure your permission sets and permission set groups.
And there's an idea worth voting up to make it easier to manage object crud in the object manager rather than in, the permission set, UX in the Salesforce setup.
Okay. So we're done. If you're not using gear set, try it for free. I've been using it since twenty sixteen.
For free, paid for, of course.
It's a great product.
They provide as a vendor, lots of features to make it easy to deploy permission sets, notably a problem analyzer to detect when permissions are missing. So you would deploy stuff to the target environment correctly, more likely the first time rather than discovering that you missed something when you deploy it into the target environment, you have to go do another deployment to fix it.
They have semantic merge conflict resolution. So whereas GitHub or other version control systems might think that there's a merge conflict because those version control systems think about things as files don't know anything about what's in the file.
Gearet knows a lot about what's in each Salesforce XML file. And if two changes have no inherent conflict because they represent different parts of the application, but all contained in the same file will gear set avoids defining a merge conflict and to handle it automatically for you.
And then, of course, there's version control integration So you don't have to do your dev ops process from org to org directly. You can do it from org to version control and then version control to org and create a modern based pipeline for your DevOps process.
So anyway, thank you very much for listening. We blather on about this. Unfortunately, work, load that Salesforce is putting on us, but the end result's the right thing because we're gonna get more secure environments.
We'll take questions now. Thank you very much.
Thank you so much, Eric. That was fantastic, super insightful and there's some really practical advice there for people to take away. And just to reiterate we if we don't get around to answering your question today, we've had loads of engagement and loads of questions.
So please feel free if we don't answer yours today to reach out to us via our live chat on our website, gearset dot com, and we can definitely answer all of your questions over there as well. But we have a couple minutes for, a few questions which have popped up in our Q and A. So, I've got one for you here, Eric, from Andrew, and he says regarding the page layout assignments by profile and the Lightning Record page assignments by profile, do you have any thoughts or recommendations on how dynamic forms, actions, or related lists can be used to help with this limitation.
Well, the dynamic form essentially gives you control over every component and field and section on the record page.
So whereas before, you would create multiple page layouts, for different use cases, you can re represent that same functionality with dynamic forms and dynamic and done in in dynamic components on a record page. So it's just a different way of thinking about the problem. My understanding is that page layouts per se, they're sort of end of life. Nothing else is gonna be developed in them. Everything is gonna be focused in terms of functionality on the lightning record page. So, anyway, now's the time to address that. And custom permissions are the most testable way or sorry, the most inspectable way, and hence, a controllable way to make those dynamic actions, fields, components, etcetera, workable.
Excellent. Yeah. Thank you, Eric.
We have one time for one more question, I think. And this one's from Christie, and they ask, what if three integrations all need the same basic access?
Why not name the permissions after functions and put those functional permission sets onto the integration user?
So We're talking about the slide that had the different integrations, the Congo HubSpot, etcetera.
Yeah. So each the recommendation is each integration has its own user.
Each integration user has its own permission set.
That permission set is likely to be defined by the app if it's a managed package, it's likely to be defined by that managed package.
You could clone that permission set and add additional permissions to it, or you could have the managed package permission set plus your own custom permission set, and then put those into a permission set group and call it the HubSpot integration permissions.
Set group and use it that way.
I'm not sure this answers the question. The premise is that every integration has its own user in every integration as its own custom permission set group or permission set, that is just about that integration.
Yeah. Yeah. Perfect. And Christy says, yeah, I guess it depends on the true uniqueness of the permissions as well.
So Thank you so much, Eric, for answering all those questions and for letting me put you on the spot there. So it's been a fantastic session today, that is all we've got time for. Thank you to all our lovely attendees for joining us. And remember, if you want to recap anything we've discussed today, or get any of those QR codes and those links, we will be sending you a recording of today's webinar along with some bonus resources as well.
And that email will be going out roughly about the same time, tomorrow. So do look out for that in your inboxes as well.
Big thanks to Eric for running today's session and also to Andy for answering all your questions in the chat and some of them in the Q and A as well. So we hope you found today's webinar helpful, and we hope to see you again. Thanks so much everyone, and take care.
Bye.
