Expiring and Session-Activated

Module 4 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 someone access that ends on its own, either on a date or when a session ends, and where does that go wrong?

Let me ask you something about your org. How many people have access today that they needed once, a year ago, for one week?

Most of us don’t know. Access is easy to give and easy to forget. Least privilege, from chapter 1, isn’t only about giving the smallest access. It’s also about taking it back. This module is about two ways to make Salesforce take it back for you.

Access with an end date

Here’s the story I tell in class. The office admin is out sick for two weeks, and someone has to cover. You give the person covering the office admin’s permission set group. That’s easy. The hard part is two weeks later: I don’t want to have to remember to take it away.

So you don’t. When you assign a permission set or a permission set group, you can give the assignment an expiration date. First, turn it on: in User Management Settings, enable Permission Set & Permission Set Group Assignments with Expiration Dates. Then, when you add an assignment, choose Specify the expiration date, pick a time frame such as 30 days or a custom date, and pick a time zone. “Assignments expire at 11:59 PM on the date and in the time zone that you specify” (Set Assignment Expiration Details for Users in Permission Sets and Permission Set Groups (opens in a new tab), Salesforce Help, checked 2026-11-01).

Watch the time zone. If you choose My Local Time Zone, it’s your time zone, not the user’s. Salesforce’s own example: you’re on Pacific Daylight Time, the user is on Japan Standard Time, and the assignment expires at 11:59 PM Pacific (same page). For someone covering a shift on the other side of the world, that can be most of a day early or late.

The same works for a project. Salesforce’s example is consultants who review contract language for one project: assign them a group that expires in 30 days (same page).

What happens on the date

A student once asked me what happens to the assignment when it expires. Is it still on the user? I didn’t know then. Now Salesforce says it plainly: “When an assignment expires, the user remains assigned to the permission set or permission set group. However, the user can’t access the permissions associated with the permission set or permission set group” (Permission Assignment Expiration Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).

Three more things from the same page are worth knowing:

• Other grants still count. “When a permission assign expires, permissions assigned to users via non-expiring permission sets, permission set groups, or through a profile still apply.” If the person covering also has Create on Contracts from another permission set, they keep it. The expiry ends one assignment, not the access.
• Queries hide expired assignments. Expired assignments “are treated as soft-deletes.” A SOQL query doesn’t return them unless you use the ALL ROWS clause. If you report on who has what, know that.
• Licenses can expire assignments too. If Salesforce removes permissions from a license, assignments that need it are no longer valid. With the expiration setting on, Salesforce marks them expired so you can see them; without it, it removes them.

Click to enlarge

The most powerful access can’t expire

Here’s the part that surprises people. “If a permission set or permission set group contains any of the following permissions, it can’t have an expiration date associated with it”: Assign Permission Set, Manage Profiles, Manage Users and Permission Sets (Set Assignment Expiration Details (opens in a new tab)).

Think about what those are. They’re the permissions that let someone give access to others, including to themselves. So the access you’d most like to be temporary, someone covering for an admin, is exactly the access this feature won’t time out. For that, you need a process: who approves it, who removes it, and who checks that it was removed. This is where least privilege, from chapter 1, needs a person, not a feature.

Access that sleeps: session-based permission sets

The second way is different. The access doesn’t end on a date. It’s off most of the time, and something switches it on for one session.

I think of it as a dormant permission set. You assign it to the user, but it isn’t active until some action happens. Then you wake it up, and it stays active for the duration of the session. The next time they log in, they’re back to normal. It’s still assigned, just not active.

In Salesforce’s words, a session-based permission set “applies to a specific user session,” and session-based permission sets “are valid only for the session on which they’re enabled.” You turn it on with Session Activation Required when you create the permission set. On the user’s record, these assignments appear in their own related list, Permission Set Assignments: Activation Required (Session-Based Permission Sets (opens in a new tab), Salesforce Help, checked 2026-11-01).

Salesforce gives three examples (same page):

• Only through one app. A custom object, Conference Room, can be updated only when the user’s session comes from the Conference Room Sync mobile app.
• Only for a while. A web app with confidential information turns access on only when users authenticate with a token; when the token expires, they authenticate again.
• Only when needed. A junior buyer occasionally needs the Contracts object. A flow uses the Activate Session-Based Permission Set action, and when the flow finishes, the buyer has access to Contracts for the current session.

There are two ways to switch one on: the Flow Builder action, or the SessionPermSetActivation object through the REST or SOAP API, which needs the Manage Session Permission Set Activation permission. And one limit: session-based permission sets “don’t support asynchronous processes” (same page).

Paul and the runway

Back to Paul. Paul is a pilot, and there’s a Runway object that a pilot should see only when they’re actually in the airplane, about to use it. So you build a permission set for the runway, make it session-based, and assign it to Paul. Most of the time, Paul can’t see runways at all. When Paul is in the airplane, something wakes the permission set up for that session. When the session ends, it goes back to sleep.

In my demo, I woke it up with a few lines of Apex that inserted a SessionPermSetActivation record. That’s not how you’d do it in a real solution. Use a flow with the Activate Session-Based Permission Set action, and make the condition that runs the flow the real control: the user being where they should be, or proving who they are again. Chapter 2’s step-up, asking for stronger proof for more sensitive work, is the same idea at the front door.

Click to enlarge

The trap: a sleeping set in an awake group

Here’s the mistake I want you to avoid, because it’s easy to make. You’ve built a session-based permission set, and you’ve learned in module 3 to put permission sets into groups. So you add it to the Pilot group.

Now it’s awake all the time. “If you include session-based permission sets in a permission set group, the permissions in them do not require session-based activation for users assigned to the group” (Permission Set Group Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01). Every pilot can see every runway, all the time.

If you want a whole bundle to sleep, make the group itself session-based. Select Session Activation Required when you create the group. Then it works the other way round: “If you include a regular permission set in your session-based permission set group, the permission set group makes the permission set session-based,” and the group “isn’t in effect until a session is activated for it,” by a flow or by the PermissionSetGroupId field on SessionPermSetActivation (Create Session-Based Permission Set Groups (opens in a new tab), Salesforce Help, checked 2026-11-01).

So the rule is simple. The group decides. An ordinary group keeps everything awake. A session-based group keeps everything asleep until it’s woken.

Click to enlarge

Which one when?

• A known end date: covering for someone, a project, a contractor. Use an expiring assignment, and set the time zone on purpose.
• Only in a certain moment: a certain app, a certain place, after proving who you are again. Use a session-based permission set or a session-based group, and activate it with a flow.
• Admin-level access for a while: neither feature will time it out. Use a process, with an approver and a check that it was removed.

What an architect decides here

• Whether expiration dates are turned on in User Management Settings, and which kinds of temporary access must use them.
• The time zone rule for expiring assignments.
• How temporary admin access is granted and removed, since it can’t expire.
• Which access should be session-based, and what condition the activating flow checks.
• That session-based permission sets are never put into ordinary groups, and when a whole group should be session-based instead.
• How reports and audits of who has what include expired and session-based assignments.

Beyond the exam: what AI changes. Access that ends fits agents well. An agent often needs extra access for one task, not forever. The same two tools apply: an assignment that expires, or access that’s switched on only for the session doing the work. And the same trap: put that access in an ordinary group, and it’s on all the time. Part 3 of this course covers agents.

Explore

• Set Assignment Expiration Details for Users in Permission Sets and Permission Set Groups (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Permission Assignment Expiration Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Session-Based Permission Sets (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Create Session-Based Permission Set Groups (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Permission Set Group Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)