Granting permissions to users is and will remain a big part of a Salesforce Admin’s overall responsibilities, especially as the CRM is bound to hold sensitive information in various shapes and forms. For the longest time, Salesforce customers have been creating custom solutions or manually making repetitive changes in assigning permissions and permission set groups, as an out-of-the-box option didn’t exist – that is until the introduction of User Access Policies!
In this post, we will cover what is still a relatively new feature, how to get started, and how this functionality can make life so much easier for the Salesforce professionals administering the CRM.
The Before and After
Since Salesforce announced the eventual sunsetting of permissions on Profiles and recommended the migration to a Permission Set and Permission Set Group centered approach, many organizations using Salesforce have started considering the steps involved in the change – this includes potentially automating part of the transition.
Even from a business-as-usual standpoint, aside from an eventual migration, there are too many scenarios to go through in which only some of the users assigned to a Profile need certain permissions. This means that Permission Sets have been and will continue to be a huge part of all implementations.
If you have already encountered the requirement to automate a Permission Set or – more recently – a Permission Set Group assignment, you know that this has entailed building an automation to create or delete PermissionSetAssignment records, either through Salesforce Flow or Apex. Without automation, Salesforce professionals had to resort to either using Data Loader or similar tools to do an import, or the more time-consuming manual option. Either way, there was a gap for an out-of-the-box functionality for Salesforce to introduce – and they did!
User Access Policies became generally available as part of the Summer ’24 release – a readily available functionality allowing Salesforce Admins or users who have the Manage User Access Policies permission to streamline the process of assigning or unassigning either Permission Sets, Permission Set Groups, Permission Set Licenses, and Package Licenses to users, or adding or removing them to/from Public Groups and Queues.
While there may still be situations in which custom implementations will be needed, this is a huge step forward for the admin experience. As you’ll see below, User Access Policies can be fully automated based on criteria, or manually run as needed. Let’s dive in!
What Are User Access Policies?
Simply put, User Access Policies are the out-of-the-box way to automate actions which Salesforce Admins must take to ensure that users have the access they need based on predefined criteria – such as assigning or removing Permission Sets or Package Licenses. These not only make the process less time-consuming for admins, but also ensure there’s less chance of users not having the correct access to perform their tasks in Salesforce as they join the company or change roles.
Once enabled in User Management Settings, a new User Access Policies page will become available in Setup. As you will notice once you have a few of them in your org, User Access Policies support creating List Views for easy management – as these will be targeting different user groups and teams within your organization, this option will come in handy when there will eventually be dozens of them!

When creating a User Access Policy, on top of the well-known Name, API Name, and Description, be sure to consider the desired order. This field represents the order in which the User Access Policies will be applied if a User meets the criteria for more than one of them. It’s also in case any of the criteria that you will set later on overlaps – this is the way to account for that. And even if you don’t know the order from the get-go, you can come back and change it afterward.

“Edit Details” is the button you can use to edit the Order or Description, but now that the User Access Policy is saved, the option to Edit Criteria is also available on the page. Since this policy does not have any criteria just yet, both the option to apply the policy or to automate it are not available. So let’s add criteria!

Zooming in on the criteria you can add for a given policy, there are two sections to consider:
- User Filters: You can select up to three filters to narrow down the users by Profile, Role, Permission Set / Group, Package License and Public Group / Queue. The available operators are “equals” and “in”, allowing you to either select one or multiple items in each of the filters.
- Additional User Fields: You can select up to ten additional fields to further filter the users the User Access Policy will be applied to. Both standard and custom Text, Picklist, Number, and Checkbox fields from the User object can be used as criteria.
Note that, as of now, filter logic between these conditions is not available, so all that’s added will have to be met. If you’d also like to see these happen in the future, make sure you vote for this idea so that Salesforce will hopefully prioritize the request in upcoming releases.

After the criteria is determined and added, you will be prompted to define at least one action – be it granting or revoking access. Each policy can have multiple actions assigned, allowing you to combine the assignments as needed.

Automating or Running the User Access Policy
Now that the criteria and actions are in place, you need to decide if the User Access Policy should run automatically. You will notice that the Status of the policy is currently “Design”, and it will remain so unless the automation is set.

By clicking on the Automate Policy button, you are presented with a few choices for when the policy should be triggered. Similar to the options available when creating a record-triggered Flow (minus the “delete” one, of course), the policy can automatically run when a user is created or updated, or only created or only updated. Once one of the options is selected, you can click Activate.

You will notice that once the automation trigger is determined, the Status of the policy also changes to “Active” and the options to edit or delete it are greyed out.
If you wish to do so, you will have to deactivate the policy, make the changes, and then activate it again by clicking the Automate Policy button.

As mentioned above, you can choose to not automate the policy at all. This option is useful when migrating access for multiple users as a one-time exercise, for example, and it is up to you when the assignment will be triggered. By clicking the Apply Policy button you will be prompted to choose if the policy is to be applied only to certain users or to all who meet the criteria of the policy, and that’s it!
Much faster than a data export, file preparation, and import, isn’t it?

Whether it’s automated or manually applied, access changes made by the User Access Policy will appear under the Recent User Access Changes Tab for each of them. For each run, you will see if it was manual or automatic, and the user who ran the policy (if it’s automated, the running user will be Automated Process). You will also have the option to drill down and see exactly which type of access was granted or revoked.

Get Hands-On
To get you started with a simple example of a User Access Policy, let’s create one for new colleagues joining the marketing organization and automate it accordingly. You can follow along in the interactive tutorial below!
Key Considerations
As with all other Salesforce features, there are a few considerations to keep in mind when getting started. For User Access Policies, keep in mind the following points:
- You can have up to 200 active User Access Policies at a time.
- As with any other automation, be sure to build and test the User Access Policies you create in a sandbox prior to deploying to the production environment.
- User Access Policies cannot be chained at this time, meaning that an action completed by a User Access Policy cannot trigger another User Access Policy.
- The Recent User Access Changes section displays only changes made by the User Access Policies that are still in effect. If, for example, someone removes a Permission Set assigned by a User Access Policy, this change will no longer appear. This also applies to another User Access Policy making the change.
- As always, make sure you always review Salesforce’s list of considerations for this feature before getting started.
Final Thoughts
All in all, there’s no denying that the introduction of User Access Policies (alongside other newer and exciting Setup functionality such as View Summary on Permission Sets and Permission Set Groups) has the potential to supercharge the administrative experience and streamline the time spent on common tasks, like assigning Permission Sets when users are created.
By leveraging the out-of-the-box capabilities that User Access Policies offer, Salesforce professionals can forget about having to build custom automations from scratch. Instead, they can make use of the out-of-the-box functionality first and resort to custom implementations only when needed.
Are you already using User Access Policies in your organization? Let us know about your experience in the comments below!
Comments: