Profiles to Permission Sets – My Two Pronged Approach

Share with

Description

Catch up on this session from DevOps Dreamin’ where Andrew Cook (Salesforce Technical Instructor at SF Ben) talks about the transition from profiles to permission sets.

In this talk Andrew discusses:

  • His experience in this area
  • What profile and permission sets are
  • The planning that you’ll need to do for the transition
  • The two pronged approach of using the User Access and Permission Assistant alongside User Access Policies for the transition

Learn more:

Relevant videos:

Transcript

yeah, thanks for thanks for coming to my session on this.

There's me.

For anyone that doesn't know, Salesforce bench just had a rebrand.

There's some quite good new photos of me in this, which I'm quite proud of.

But you can a new logo there. We've got the purple in there now, which is which is nice.

So before I start, I'm gonna just talk a little bit about me So I started with the platform as an end user, actually. I worked in o two that I'm sure most people in the room will know, was an in store technical person, back in the day where you had blackberries, where you had mobile broadband where you needed someone like that. So they brought it in for us to literally for customers to be able to book an appointment with come and see us and fix their problem.

It was looking back, it was probably like a really customized I think it was a visual force to be is it was really customized.

Yeah, so that was how I got started with Salesforce.

I then moved to SAME Me industry, so still mobile, but it was b to b, and that was where we used it more traditionally, I guess you'd say. So things like accounts, contacts, leads, opportunities, all of those things.

Yeah, so that was the point that I probably would say fell in love with the platform, because I literally was in two different companies, similar industry three, using it completely different ways. So that was the point where I thought, okay, this can be used for anything.

Twelve years ago. So here I am now working for Salesforce Ben as a Salesforce technical instructor. So I work mainly on the Courses platform and do a lot of writing and a lot of the videos as well lately, which is quite cool.

I'm also now fourteen times certified, which I'm quite proud of. And this year, I've done a lot of speaking as well. Check dreaming.

London's calling GPT dreaming. I was on the panel and done some user groups as well.

Also a a month's mentor now. I was previously a travel laser one. They've obviously disbanded that.

And lastly, I'm also part of Salsals credentialing team, which is really cool, especially the last thing that I worked on for them was the AI associate.

So if you've got any on that afterwards, come and come and grab me, and I'll answer what I can.

If you wanna connect, me, you can scan that.

And here's one of the photos that I'm proud of.

Did you get did you get it, Todd? Yeah. Cool.

Cool. So here is the agenda for this session. So I'm gonna start by talking about my experience in this area, because there's probably a lot of people thinking how can you talk about this? Is fair.

Next, I'm gonna talk through profiles, permission sets, permission set groups, and the sort of planning you'll need to do for a project like this, before going on to the actual two pronged approach from the title of the user access and permissions assistant and user access policies.

Before I start, actually, I just want to put a caveat out there Cheryl Feldman, who leads up both of these, has literally just appeared on the admins podcast. So She might everything I might be about to say could be wrong and Sheryl might've changed everything.

I hope not, but I to put it out there just in case.

Anyway, let's get started. So my experience in this area, you're probably wondering It's quite a lot actually. So start with, I'm a certified sharing and visibility architect, which anyone that's it will know, you need to know the whole ins and outs of profiles permissions, anything like that to pass it.

In my previous role, sorry, there's a typo on here for the record.

That should be socks not sock.

Anyway, so in my previous role, I worked for a mobile com, a mobile security company based London, we was then bought out by a big US firm who are publicly traded. And any US firm like that, they need to, do certain things to be socks compliant.

So part of that whole process I needed to literally go through every user, every profile, every role, and say why each person needs access to everything.

Absolutely everything.

It took it took about two months. It was a long long process.

So after doing that, this this topic, Sained relevance.

As I said before as well, I've been in this, the ecosystem for twelve years, mostly as an admin. So I've managed thousands of users doing a lot of things around permissions.

So first things first, what is profile.

An easy way to think of it is as an office part to your work building. So your profile is like your basic office pass. It gets you an it gets you up to the floor that you work it gets you into certain areas.

So that's I want you to keep that in mind because this theme kind of throughout the the process of this talk.

And as well, obviously, with So you'll have a profile. Someone else will have a different profile that gives them different access to different parts of the building.

So what is the future of profiles. So Salesforce announced in spring that that in spring twenty six, permissions on profiles are gonna gonna retire. They're not gonna be on there anymore.

However, certain things will remain on a profile. So there's things like one to one relationship. So you're logging hours, your IP ranges, your default like your record types and apps, they will stay on the profile, and also your page layout assignments that they're all still gonna remain on the profile. So you're still gonna need profiles.

It's just things that they manage will be changed in drastically.

Right. So now what is a permission set? So if we go back to the office parts analogy, say you are or does say your marketing team needs specific access to the fifth law and an executive suite. So they will have their actual pass to get in the door, but then they'll be grant they'll they can be given an additional pass that allows them access to areas as well. So that is a similar way to how a pin permission set is in in Salesforce.

So what is moving to permission sets?

It's quite a lot. This is gonna be a long list. So strap in So you've got your user permissions, your object permissions, your field permissions, tabs, record types that are not defaults, your apps that are not defaults, your connected app access, Apex classes, visual pages and custom permissions. These are all things that are moving from profiles to permission sets as of spring twenty six.

Right. Now lastly, what is a permission set group? So again, going back to the office analogy, say we've two groups of users. You've got your marketing team. You've got your IT team who both need specific access to certain areas of the office.

For those, the office management, I guess, who would be your admin, can give a bundle of passes that they have act that they can used to access all of these areas, and they're all bundled together.

So everyone with that bundle knows that they can where they need to.

So planning so what do you need to do with your planning? So first, you need to know your profiles So if you've got a sales user and a sales manager profile, you need to understand the differences between the two.

Likewise, if you've got a super user profile, what permissions that they got compared to a a standard user.

Next, you need and how you're gonna group your permissions together. So if you've got a sales manager and a service manager, can these group be grouped together into just a man management kind of profile that gives things like reports and dashboards access.

And most importantly, you need to communicate with your users. You need to member that this is your users are who will be impacted most. This is what the change is all about. They need come along on the journey with you, they you need to make sure that they're part of every step of the way. They need to be testing. They need to be involved because if they're not involved and they don't feel like they're involved, they're not gonna appreciate the work that you're doing.

So first step one is the user access and permission assistant.

Before I do this, this will to be an actual demo.

I said to Jack a little while ago, how can I do the demo? There's no laptop on the stage.

Jack pretty much said to me, you don't have the facilities for that big man. Go do some screenshots.

So there's a lot of screenshots about to to come up, but hopefully because they're screenshots, I won't get sidetracked where in a demo I might have wandered off.

So demo is not a demo at showtime because I'm not actually doing anything.

So here is the user and permissions analyzer.

So you can see We've got the permissions analyzer tab.

And if I move on slightly, you can select to analyze by your user, your permission, your permission set groups.

So an example of that would be here's my example of me.

A user on the account object, you can see all of the all of the access that I've got.

Granted on a user by user basis, this tool probably not the best way to do it. However, how many admins have gone into somewhere needed to see who's got modify and has been scared by how many people has actually got modify all. These are the sort of permissions that this is this tool is really useful for. So you can go in go into a new wall straight away. You can okay, who's got who's got these main permissions that people shouldn't have?

Next, we've got the converter.

So the converter literally a list of all of your profiles.

And as you can see from the tab, you've got the option to convert the whole to a permission set if you want to. So for example, here, I've got the sales profile in my demo I would have done, I would have converted the sales profile to a sales user permission set, and that's that's all handled through here.

So next you've got the report tab. So if I back to my experience with my sox compliance project, this would have been a lifesaver for me just being able to report on everyone's permissions in one place, run a report, export it, and manipulate the data that I need to from there.

And lastly, you've got the the manage tab. So from here, you can assign your permission sets to users or unass sign as well. And you can see that you can manage it by assignments and permission set groups.

And for anyone that wants to make use of this, it's completely free, download from the AppExchange.

I think there was some about the ratings on this because it was previously a different app. So the ratings on it do not they don't they're not accurately representative of how good the tool is because it was a different app that wasn't as good.

So moving on, the user access policies, So this is currently in beta.

After the demo that I've got, I show how to in with a beta. It's really simple now. It's it's all done through setup.

It's so this tool is really easy in that if you So if you think back to the days of workflow rules, it's a kind of similar interface, really, in that you create a rule based around your users and their profiles and how you want to move them to permission sets.

So this is really useful in the fact that you can set up a rule and then just leave it and it will run. So we know this change is coming, but you might not be for the change or your organization might not be ready for the change yet. You can set these rules up now so that your users any users are being assigned the correct permission sets, and then when the time is right in spring twenty six or later if they push it back, they're all they're all ready, and you can just switch to profiles.

And again, an example of earlier from the my sales user permission set.

So show time number two.

So this is how it looks, so it's completely accessed through setup. It's built directly into the platform rather than, the other tool, which is a an installed package.

So this is how this is the romper of how you you would set up a rule. So you give it a label, as usual, it will automatically TV API name, you can set a trigger type, which is really important in that it can be when you create a user, when you update a user or either.

So you can have one rule for new users could have another rule for existing users if you wanted to. You've also got different statuses so you can retire rules as well based on the status so you can kind of keep track of things that way as well.

And this is how it looks in the end. So you can see you've got the label where in at the top. I've got my if my profile is the custom sales profile.

I've added in another rule of they're active, because what's the point if they're inactive?

And then for that, it will assign them to the sales user permission set that that there went through a little while ago. So how's enable it. So it's really simple. All you need to do in setup, go to user management settings, and then just enable user access policies. It's really simple. Unless Cheryl's changed it in in the podcast, and that's how it looks.

So in summary, you need to understand your current profiles.

That's kind of one of the main points of this is you need to know what's going on in your org. You need to know the ins and outs of your profiles, or this isn't gonna work.

You need to plan how you group them together.

Planning is really important with this whole process.

Then you've got your user access and permissions assistant app, again, completely free.

You should definitely make use of it if if it fits in what you need to do and then enable the user access policies, which is in beta, but it's been in beta for a little while, so it's gonna come out of beta pretty soon.

And as with everything, do it in a sandbox, test it with your users, make sure everything works you push because this is one of the very, very real areas where if you get it wrong, you learn about it very quickly.

And that is pretty much it.

There's there's the last yeah. I know. I know. This is the one proud of.

Yeah, Jack, I don't know what we are for time. Do you have time for questions? Yeah. We're good for time. And we do actually have a question from Oh, that's not good. Is it?

We do have a question from the online audience. Would you recommend using the user access and permissions assistant to convert pro files to permission sets, or should profiles be broken down?

I think it depends on the exity of what you what you need to do.

I think the main is you need to plan it first because there'll be instances where you have a profile, like like a sales profile, for example, that may just be able to be directly to a permission set, or you might have a lot more complex profiles that you need to think about more and how you can break them down.

CA. It really depends on on your current setup, I guess.

Do you have recommendations for, segmenting permission sets around roles versus access to functionality across the platform. Does it make sense for a master? Yeah. Yeah. It makes sense.

Again, I think that I can't remember the question.

The question that you were just about to it.

Yeah.

You're funny.

I was asking if there is, Hang on. Hang on. Do you have any recommendations?

There we go.

So I'll repeat. Do you have any recommendation around segmentation of the permission sets? If it's around object or areas within the platform or more in terms of roles?

I think the beauty of this whole process is that you can make the decision yourself. I think we can all we we can all within our organization we we know we know our organizations better than anyone.

So I think we have the power to make that choice. I don't think we're gonna be pushed in one way or another in how we do it. So really, yeah, I really think it depends on, again, on on the org set up that you've got and kind of the permissions going around because there'll obviously be some people that have got very, very limited access, which is a lot easier to manage than places that have got five different levels of super user to manage certain different things.

Yeah. I think that I don't know if that answers the question not.

We can chat after this one.

That's a good question.

I don't know, actually.

I will check that. I would I would imagine yes.

Because Cheryl built it and just I can't imagine Cheryl knew doing that, actually. But, yeah, I'll I will check. I'll find out. Yeah.

We regards to the user access policies, can you remove permission sets as part of that? So you've got service user, they've got the service user permission set. You can both add and remove permission sets and permission set groups from users.

Yeah, so it's actually a good way of doing doing both. So you could actually use it just for permission set scheme general in that, like, if someone needs access for a limited time, you could have a broad that after whatever time, you can remove it. Yeah.

I'm all. Good. Andrew, thank you so much. Profiles of permission says everybody.