Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

In one sentence: you can give a permission set or permission set group assignment an expiry date, after which the platform removes the access without anyone remembering to, which turns temporary access from a promise into a mechanism. You have to switch the feature on in User Management Settings first, and it is worth understanding what the audit trail does and does not capture before you rely on it.

Turning it on

The setting lives in Setup under User Management Settings, covering assignments with expiration dates for both permission sets and permission set groups. Until it is enabled, the expiry field is not available in the assignment UI.

Treat enabling it as a deliberate decision rather than a tidy-up. Once teams start relying on expiring assignments, unwinding that is disruptive, so plan on it being permanent.

How an assignment expires

The expiry is stored on the assignment record itself, in the ExpirationDate field of PermissionSetAssignment. When the date passes, the assignment stops granting access. The UI shows the assignment’s status, so administrators can see which assignments are active and which have lapsed.

SELECT Assignee.Name, Assignee.IsActive,
       PermissionSet.Name, ExpirationDate, IsActive
FROM PermissionSetAssignment
WHERE ExpirationDate != null
ORDER BY ExpirationDate

That query is the report you actually want on a dashboard: everything currently time-limited, sorted by when it lapses. Add a second one filtering to expiry in the next seven days and send it to whoever approves access.

Expiry applies to the assignment. It does not expire the permission set itself, and it does not apply to profiles, which have no equivalent mechanism.

The use cases that justify it

  • Contractors and fixed-term staff. Set the expiry to the end of the engagement on day one. The access removal then happens whether or not anybody remembers the leaver process.
  • Break-glass access. A permission set that grants unusual access, assigned for forty-eight hours during an incident, with the clock running from the moment it is granted.
  • Seasonal load. Temporary support agents who need case access for a quarter.
  • Migration and cutover work. The classic case where broad access is granted “just for the go-live” and is still there two years later.
  • Pilots. A feature permission set given to a test group with a defined end date, so the pilot actually ends.

The common thread is that all of these already had an intended end date. The feature does not create discipline, it removes the dependency on someone’s memory.

Auditing what was granted temporarily

This is the part to think through before you depend on it. The Setup Audit Trail records assignment changes made by administrators, and the assignment record itself carries the expiry date while it exists. What you should verify in your own org is exactly what remains visible after an assignment lapses, and for how long, because “who held extra permissions last March” is the question an auditor will ask.

The safe approach is not to rely solely on platform retention. Capture the state periodically: a scheduled job that writes active assignments with expiry dates to a custom object or an external log, run weekly. It costs very little and gives you a history that does not depend on how the platform ages out its own records.

Pair that with a naming convention. A permission set called Temp_Extra_Case_Access is self-documenting in a way that PS_Support_2 is not, and the description field should say who approves it and what the maximum duration is.

Where it does not help

Expiring assignments do nothing about access granted through profiles, through the role hierarchy, through ownership, or through a permission set assigned without an expiry date. It is one control in a set, not an access governance programme.

It also does not stop someone reassigning the same permission set the day after it lapses. If that keeps happening, the honest conclusion is that the access is not temporary and the design needs revisiting rather than the expiry date being extended each quarter.

Frequently asked

Can I set an expiry on a permission set group assignment? Yes, once the feature is enabled, and that is usually the better unit of assignment anyway.

What happens to the user at the moment of expiry? The access stops. A user mid-session may see errors rather than a graceful message, so schedule expiries outside working hours where the access is doing something visible.

Does it work with permission sets that carry a licence? Behaviour varies by licence type. Test the specific combination in a sandbox rather than assuming.

Can it be automated? Yes, by setting ExpirationDate through the API, which is how you would wire it into a joiner-mover-leaver process or an approval flow.