Convert profile to permission sets in Salesforce.

Join us for a Profiles to Permission Sets Journey. Join our Guide to Convert profile to permission sets in Salesforce. We will cover the different ways to migrate Salesforce Profiles to Permission Sets.

Why Convert Profile to Permission Sets in Salesforce?

Let’s understand Why this is important! To Converting Profiles to Permission Sets.

• Reduces time on Maintenance
• Aligned with Salesforce strategy
• Profiles are not scalable and flexible for future user growth.

What is happening to Permission Sets and Profiles?

Permission Sets and Permission set groups are the Future. Profiles are not going away, but permission on profiles will be GA after spring ’26. Profiles were phased out to permission sets, and now we need limited features on Profiles.

What should We put on Profile	What should We put on the Profile
User Permission ( System & App )	Use the minimum access on profile
Object and Field Level Permission	Page Layout Assignment
Record Types	Default Record Type, Apps
Connected App Access	Login Hours/ IP Ranges
Apex Classes
Tab Setting
Custom Permissions

Learn more here.

How Do We Review Permissions With Existing

Review all profiles and user permissions with User access and permissions assistant.

• Leverage the security zen tool to export permissions to a spreadsheet for analysis.
• Identify standard permissions based on persona, users, and departments.
• Identify unique permissions
• Create Minimal permissions for profiles

Redesign your Security with 6 layered Approach

Redesign your Security with a layered Approach

• Foundation model
• Considerations
• User Provisioning
• Testing
• Implementation
• Compliance

Model- Strategy on Permission Sets and Permission Set Groups

• For an existing Org that has profiles
• Redefine your personas based on departments or logical group
• Each persona will be a permission-set group
• Redefine permission sets based on job functions

Model- Key Principles for Security Redesign

• Create Personas based on job functions instead of departments
• For each department
  • Create permission sets for leadership
  • Permission sets for bare minimal user
  • Muting permission sets for excess permission
• Considerations
  • Enhanced privileges
  • Temporary users

Model- Strategy on Permission Sets – Object Based

This is for smaller orgs or Bu with less than ten objects

• Create Permission sets for each object with create, edit, and delete
  • E.g. Read Account
  • Edit Account
  • Delete Account
• Create permission-set groups for privileged access.
  • System admins
  • Developers
  • Interim consultants.
  • Advanced Business Users or sme
• Pros
  • Provides a granular permission
  • Highly flexible
• Cons
  • It can be cumbersome for objects of more than 10
  • Will involve more test cases for testing

Model- Permission Set Strategy With 3-Set Approach

Model- Permission Set Strategy for Larger Orgs – 3 Set Approach

Global Enterprise Security Model

Converting Profiles to Permission Sets Considerations

Here are Converting Profiles to Permission Sets Considerations.

1. Current State Record Type and Page Layout

Page layout assignment exist only at profile level based on record type. On a profile object setting for the object opportunity, the default record type stays at the profile.

2. Current State Record Type Assignment

The permission set allows you to assign the record type.

3. Muting Permission Sets Considerations

• Permission set group – The permission set group includes all of the permissions in its included permission sets.
• The ability to include permission sets in more than one permission set group offers a lot of flexibility.
• What if the Requirement is – Don’t assign all the permissions in a permission set to users in a permission set group?
• Muting lets you customize a Permission set group by muting (disabling) selected permissions in it
• Other considerations:
  • The phased rollout for a smooth transition and minimizes disruptions
  • Keep record types minimum to simplify the data model

4. Considerations- Login hours and IP Ranges

• Currently, Login hours and IP range permissions are set at the Profile Level.
• Leverage connected apps to restrict external applications with IP and log in hours
• Leverage IDP to restrict permissions for location-based access control.

5. Privileged Access Principles

• Maintain permission set groups for system admins with enhanced permissions
• Create permission-set groups for privileged access
  • Developers
  • Interim consultants
  • Advanced Business Users or sme
• Mute modify all and delete all permissions for temporary access

6. Strategy On Profiles for Phase Out

• Consolidate the permissions across profiles and maintain a minimal Profiles –
  not to exceed 5
• Keep 1 profile for all users with minimal permissions
• Keep a profile for API-only users
• Keep a profile for system admins

7. Strategy on Permission sets – Community Users

• Setup baseline security with OWD using external access
• Leverage permission sets for authenticated users
• Keep a separate permission set for guest user
• Use the delegated admin feature for advanced guest users to manage their own
  accounts and contacts
• Watch out for guest users owning records and set default owner if needed

8. External Management for Users

• Admins can set/permit external users to manage permission sets for other users, reset passwords, activate/deactivate, or add members to other accounts
  • Account Switcher component: Allows external users the ability to access other accounts
• Ability to configure an external managed account to allow an external user to
  manage another account
• An external managed account designates a managing user, the target account that they can manage, and the type of access they’re authorized to on the target account
• Partner users with the Delegated External User Administrator permission can
  activate, deactivate, create, and edit members
  • That is in addition to administrators and internal users

9. Implementation Strategy

• Define Phases based on persona or department
• Have a backup strategy for rollback if needed
• Do the Owd to private before you do permission sets
• Ensure all public read-only and read-write are deployed in the initial roll-out
• Get SME for each persona to test our permissions
• Have mechanisms to track profiles, permission sets, and permission set group
  changes

10. Testing- Testing Strategy

• Identify test cases for each persona to be migrated
• Identify test cases for privileged access, like system admins
• Identify test cases for exclusive permissions or unique permissions
• Identify test cases for sensitive data access like PII, PCI or Payment information
• Test Automation Strategy
  • Apps on App Exchange
  • Test classes to run common test cases

11. Security Audit

• Work with your CISO or Infosec on IT controls for logging permission requests.
• Identify default permissions for each persona and have an audit trail for requests, changes
• Monitor privileged access permissions
• Have a process for recertifications
• Leverage Identity governance tools for logging default permissions across each application.

Compliance – Monitor Permissions Proactively

Monitor Permissions with Security center. Track Permission changes on permission
sets and permission set groups Monitor Malicious Apps.

Summary

Thanks, Abhinandana Gotam, Jason Norat, & Buyan Thyagarajan, for such a great session in Apexhours.