After Salesforce announced the eventual retirement of permissions on profiles (although the hard date of Spring ’26 has since been removed), admins and architects are starting the process of migrating to permission-set-driven models of user management.
There’s a lot in favor of the shift. The product management team at Salesforce has put a huge amount of effort and thought into planning for the change, and there are some useful tools to help with the migration.
But even with careful planning, some settings are easy to miss. From Outlook integrations to dynamic forms, there are some features that are linked to profiles and are more complicated to identify and migrate. These can have a major impact on your users.
Setting the Scene
The ultimate aim of the migration is to move all your system, application, and database permissions away from profiles and onto the right combination of permission sets. The recommended approach will see you have very few, or even a single profile that is completely devoid of permissions. No object of field permissions, no Apex Class access, nothing.
This gives you a much more granular and modular way of assigning permissions. It allows you to assign permissions temporarily, with an expiration date, and generally makes it much easier to apply the ‘principle of least privilege’ in how you run your org. I’ve also found that permission sets are significantly easier to use in development work and when moving between environments.
Planning for the change can be complex, involving mapping out the different personas you have for your uses and the right combination of permissions they need.
For each persona, you’ll need to find a small, willing group of test users who can help you evaluate the change and report any issues they run into after moving to the new model.
No matter how careful you are about transferring permissions, there are likely to be gaps. In particular, those newly created ‘empty’ profiles will be missing from some org settings, and that’s where the pitfalls can occur…
1. Lightning Record Page Assignment
You assign Lightning pages through a combination of the app, record type, and the profile of the user viewing the record. However, these assignments aren’t recorded anywhere on the profile itself. They belong to the “CustomApplication” metadata files (and are set from the record pages themselves).
If you’ve created an empty profile as recommended, it’s going to be missing from any existing Lightning page assignments. Users with that profile will see the default record page (either at org or app level) and won’t have any record-type specific pages assigned to them. They may well report (as some of my test users did) that ‘things look weird’ or that the actions and fields they need to access are no longer visible.
To avoid this, make sure that you have added the new profile to each specific record page you want to use:
- Go to the Object Manager in Setup.
- Select the object you want to make the changes to.
- Click on “Lightning Record Pages” and choose the record page you want to assign.
- Click “Edit” then the “Activation” button on the top right. Then, jump to the “App, Record Type, and Profile” tab.
- From here, if you click “Add Assignments”, you can make sure the new profile is added to each app and record type where you want it to show.
Given that enhancements like dynamic forms, action, and related lists largely make record types redundant, it’s well worth considering streamlining your record types and the need for separate lighting pages as part of this process. Fewer record types make Lightning page assignments much easier to manage and update.
While we’re talking Lightning pages – you should check whether any of your dynamic components are filtered by profile. For example, do you have additional sections appear on a page for users with the Sales Manager profile? If so, now is the time to change those filters to reflect your new setup (you can reference permission sets or roles as an alternative).
2. Org-Wide Email Access
This is another setting that’s easy to miss. Organization-wide email addresses can be made available to all users or restricted to certain profiles. But, as with Lightning record pages, the information isn’t visible from the profile itself.
If you have organization-wide email addresses that are restricted to certain profiles, you’ll need to make sure you give access to your users after you make the changes. Keep in mind that this includes email addresses that are used to send emails from flows as well as those sent manually.
Once you’ve moved all your users to a new, empty profile, limiting access to email addresses by profile isn’t going to be viable. Fortunately, since the Summer ‘23 release, access to org-wide email addresses can be controlled by permission set. So, as part of the changeover, you’ll need to identify and allocate access to the relevant permission sets.
To add access, go to the Permission Set Overview page, click on “Organization-Wide Email Address Access”, then “Edit” and select the addresses you want to grant access to.
3. Outlook and Gmail Integrations
I’ll be honest: I had barely reviewed these settings since they were first set up. Once you have your core integration working well, it’s the sort of setting that doesn’t get a lot of attention. It was a little puzzling when the test users flagged that they were having problems, as they seemed to have all the necessary permissions and licenses to use the integrations.
There are two main areas you’ll want to check as part of the migration…
Access to the integration itself is not controlled by the profile. However, profiles do control which email pane and publisher layout a user has access to. A completely new ‘empty’ profile may not have any layouts assigned, in which case users will not be able to log emails to Salesforce from within Outlook or Gmail.
To check these assignments, access either “Outlook Integration and Sync” or “Gmail Integration and Sync” from the Setup menu. You can access all of the email panes and publisher layouts and see which profiles they are assigned to.
The second thing to check is similar but focused on Lightning Sync (or Einstein Activity Capture if you are using that). For these features, you’ll need to make sure users have a Lightning configuration assigned to them. This defines the rules around which contacts and events are synced to Salesforce and how they are treated (for example, whether syncs run one way or in both directions).
As with publisher layouts, the risk is that the new profile isn’t assigned to a configuration. You can access the settings on the same page under the “Lightning Sync” section.
4. Login Hours, Password Policies, and Session Settings
This is a relatively straightforward one. None of these are likely to be available on permission sets any time soon. That’s because each user should only have a single setting for each of these areas.
Take login hours, for example. If these were available on permission sets, a user could have multiple, conflicting settings for when they are able to access the org. Sure, you could develop some sort of way of defining priority order, but it’s not clear how viable such an approach would be, and it would be easy for conflicts to lead to security issues.
For purposes of the migration to permission sets, this means that you’ll simply need to map out the different profiles you’ll need first, built around the login hours, locations (for IP ranges), and password policies required.
Salesforce has been pretty clear that these settings will likely remain on profiles long-term (along with other one-to-one mappings such as default app or record page assignments). And you can see how, in the future, this sort of lightweight login-focused profile could sit well alongside permission sets.
5. Experience Cloud
Experience Cloud is the trickiest aspect of managing the change to permission sets. If you have multiple Experience Cloud sites for different groups of partners and customers, it is going to complicate your approach significantly. This is because profiles control a much broader range of features for external users.
Sharing sets used to control record access in Experience Cloud are defined by a profile. This means that where you require different criteria for sharing records with external users, you’re going to need distinct profiles. You can’t completely replace these with more typical sharing rules because not all Experience Cloud licenses allow access to that sharing model. Sharing sets also allow you to determine access based on the contact or account record linked to the user, which is a key use case.
Most of the dynamic features of Lightning pages are not yet available within Experience Cloud sites. Although there is some flexibility through page variations, you will still need to rely on page layouts to control the fields, actions, and related lists that are visible (unless you have the option of building custom Lightning Web Components).
There’s nothing I can see on the roadmap to address this, and it’s a major challenge in completing the migration. In the short term, Extreme Dynamic Forms, an AppExchange package from Salesforce Labs, may give you a workaround.
Summary
The migration process is a complex process that needs careful management – there’s a long lead time until it has to be completed, but, as with other big changes, the sooner you start scoping and planning for the change, the better.
The issues highlighted here are all manageable but important to be aware of when planning your project and not necessarily easy to identify in advance.
The work is worth it. The move to permissions sets overall is a great development and brings some huge improvements to user management in Salesforce. It makes for a more granular and secure approach to user permissions. Once completed, it should also help simplify some other aspects of org admin and have you well-placed to take advantage of further developments and new product features.
Comments: