User Access Policies

Module 5 of 7 in the chapter Profiles, Permission Sets and Permission Set Groups, chapter 3 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: How do you give the right access to every new user, and every user who changes jobs, without doing it by hand each time?

Here’s a question for your org. When a new pilot joins the airline tomorrow, who decides what they can do in Salesforce, and how?

In most orgs, the answer is a person, a ticket and a checklist. Someone copies the access of “a user like them.” That works until it doesn’t. Mike Reynolds, on the Salesforce Admins blog, describes the first persona he cleaned up: it “had 11 users and across them there were seven different mixes of permission sets/profiles.” And people who move jobs keep what they had: “It’s common to see a user with permission sets that came from a role they had in the past” (Get Agentforce Ready: Move From Profiles to Permission Sets (opens in a new tab), Salesforce Admins blog, 2025-01-15, checked 2026-11-01).

Modules 2 to 4 built the right blocks and bundles. This module is about giving them out by rule.

When permission sets really took off, and access was built person by person, the work moved to the moment someone joined or left. Every time a user was provisioned, someone had to add dozens of permission sets, sometimes more, to that one user. Every time a user was deprovisioned, or changed jobs, someone had to work out which of them to take away. It was tedious, and tedious work is where mistakes come from. Permission set groups were the first relief: one group instead of dozens of sets. User access policies are the second: nobody has to add them by hand at all. But get the order right. A policy doesn’t fix a design that’s too small; it just hands out the Lego nightmare faster. Right-size the permission sets, bundle them into groups, then let a policy give them out.

A rule instead of a checklist

A user access policy is a rule: users who match these criteria get, or lose, these kinds of access. Salesforce’s example is Sales Reps. A policy finds users with the Sales Rep role, and its actions “grant these users the permission set licenses, permission sets, and permission set groups that they require to do their everyday tasks” (User Access Policies (opens in a new tab), Salesforce Help, checked 2026-11-01).

What a policy can do, from Automatically Grant or Revoke Access with a User Access Policy (opens in a new tab) (Salesforce Help, checked 2026-11-01):

• Who it applies to. Users who meet all of its criteria filters: up to 3 filters for applicable users, and up to 10 filters on standard and custom user fields of type Checkbox, Number, Picklist or Text. One filter can list several roles or profiles with the In operator.
• What it does. Grant or Revoke, for permission sets, permission set groups, permission set licenses, package licenses, public groups and queues. Up to 20 actions per policy.
• Where it works. Enterprise and Unlimited editions. Turn on User Access Policies and Enhanced Interface for User Access Policies in User Management Settings, and you need the Manage User Access Policies permission.

Notice the list of actions. A policy gives out more than permissions: it can also add someone to the public groups and queues that later chapters use for sharing records. One rule can set up a new pilot’s whole day one.

Click to enlarge

Two kinds: manual and active

A policy runs in one of two ways.

Manual policies run when you say so. They’re for one-time changes: Salesforce’s own examples include moving users to permission sets and permission set groups instead of profiles, restructuring group and queue membership, and removing access for features you no longer use. You click Apply Policy, see a list of all the users who meet the criteria, and apply it to some of them or to all (Migrate Users with User Access Policies (opens in a new tab), Trailhead, checked 2026-11-01).

Active policies run by themselves. You click Automate Policy and choose when: when a matching user is created, when a user is updated to match, or both. Then you activate it (Automatically Grant or Revoke Access (opens in a new tab)).

Either way, the policy’s detail page has a Recent User Access Changes tab that shows when it was applied and to whom. That’s your audit trail. Know that it shows only changes that are “still in effect”: if another policy or a person later overrides a change, it’s no longer listed (User Access Policy Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).

Click to enlarge

The one-time move off a profile

Module 1 ended with a big job: moving the access off your profiles. This is the tool for it.

Trailhead’s walk-through shows the shape. A manual policy finds users on the old support profile who are active, and grants them the new Support User permission set group. You apply it to all of them at once. One thing it can’t do: revoke the profile, “because users must still have one profile.” After the policy is applied, you go back and remove the profile’s permissions, so it keeps only its default settings (Migrate Users with User Access Policies (opens in a new tab)).

That’s exactly the order module 1 asked for. Give everyone the group first. Test. Then strip the profile down to the door and the defaults. And if you later merge profiles, do that as its own project.

The catch: active policies wait for a change

Here’s the part that catches people. You build an active policy for pilots, you activate it, and nothing happens to the pilots you already have.

That’s by design. “An active policy is applied to existing users only when their records are updated to match the policy’s criteria.” With a filter on department, a user whose department changes to match gets the policy; a user whose department already matches doesn’t (User Access Policy Considerations (opens in a new tab)).

So I’d do it in two steps. Run the policy once by hand for the people who already match, then turn it on for everyone who comes after. The manual run catches up today’s users; the active policy keeps tomorrow’s right.

Click to enlarge

The rules worth knowing

All from User Access Policy Considerations (opens in a new tab), checked 2026-11-01:

• Up to 200 active policies. And Salesforce recommends you “create only the user access policies necessary.” Complex or numerous filters take longer to apply.
• One policy wins. “If a user record creation or update triggers more than one user access policy, the policy with the lowest Order value is applied.” They don’t add up. So don’t design one policy per permission set and expect a user to collect five; design one policy per persona, and give it all the actions that persona needs.
• No chains. “An action performed by a user access policy can’t trigger another user access policy.”
• Groups and queues as criteria count only direct members. If the criteria target a public group or queue, the policy applies only to users added directly, not to users who are in it through roles, territories or nested groups.
• Group changes can be heavy. Public group membership updates that affect many users “can lead to long sharing recalculations, timeouts, or group membership locks.” For a big change, Salesforce recommends deferring sharing calculations first, then resuming and running a full sharing rule recalculation. Chapter 7 covers public groups, and chapter 22 covers sharing at scale.
• Licenses can run out. If a policy assigns licenses you don’t have enough of, the failure is noted in Recent User Access Changes. Check it.

Don’t forget the way out

Most teams build the policy that gives access and forget the one that takes it away. But Reynolds’ point stands: people who change jobs keep what they had unless something removes it. A policy can Revoke as well as Grant. When you design a persona’s policy, ask the second question too: when someone stops being a pilot, what takes the Pilot group away? Then test that path as carefully as the first.

What an architect decides here

• Which personas get a policy, and which user fields mark them, such as role, department or a custom field.
• The Order of active policies, knowing only one applies when several match.
• How existing users are caught up before a policy is activated.
• How access is removed when someone leaves a persona, and how that’s tested.
• How the move off profiles is run: manual policies, tested in a sandbox, profiles stripped afterwards.
• Who reviews Recent User Access Changes, and when large group changes defer sharing calculations.

Beyond the exam: what AI changes. As more users arrive faster, including agent users, access given by hand stops scaling. Rules do. A user access policy is a written rule you can review: who gets what, and why. That’s easier to audit than a hundred one-off assignments, whoever, or whatever, made them. Part 3 of this course covers agents.

Explore

• User Access Policies (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Automatically Grant or Revoke Access with a User Access Policy (opens in a new tab), Salesforce Help (checked 2026-11-01)
• User Access Policy Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Migrate Users with User Access Policies (opens in a new tab), Trailhead (checked 2026-11-01)
• Get Agentforce Ready: Move From Profiles to Permission Sets (opens in a new tab), Salesforce Admins blog (checked 2026-11-01)