Permission Set Assignment
A Permission Set Assignment is a standard Salesforce object (PermissionSetAssignment in the API) that records one grant of a permission set or permission set group to a single user.
Definition
A Permission Set Assignment is a standard Salesforce object (PermissionSetAssignment in the API) that records one grant of a permission set or permission set group to a single user. Each record links a user to the access bundle they receive, so the assignment is the actual connection that turns a permission set into live access for someone.
A Permission Set Assignment holds an AssigneeId for the user, a PermissionSetId or a PermissionSetGroupId for the access being granted, and an optional ExpirationDate that removes the grant automatically when it is reached. Assignments are how Salesforce delivers its recommended additive model: every user keeps one baseline profile, and extra access stacks on top through assignments that an admin can add or remove without touching the profile.
How assignments turn permission sets into real access
The record that connects a user to a permission set
A permission set on its own grants nothing. It is just a container of permissions that sits unused until someone is assigned to it. The Permission Set Assignment is the record that does the connecting. When you click Manage Assignments on a permission set and add a user, Salesforce writes one PermissionSetAssignment row that points the user (AssigneeId) at that permission set (PermissionSetId). From that moment the user has every permission the set contains, layered on top of whatever their profile already allows. Remove the assignment and the access disappears just as cleanly, with the permission set itself left intact for the next person. Because assignments are real database records, you can query them with SOQL, create them in Apex, and load them in bulk with Data Loader. This is why permission-set-based access scales so well. You are not editing a profile and risking side effects for everyone who shares it. You are adding or deleting a single small row that affects exactly one user. The same object also records permission set group grants, which is what makes role-style bundles practical to manage at any size.
AssigneeId, PermissionSetId, and the group field
Every assignment names a user through AssigneeId, which is a lookup to the User record receiving the grant. The access being granted is named in one of two ways. PermissionSetId points at a single permission set. When you assign a permission set group instead, Salesforce stores the group in PermissionSetGroupId and creates the underlying member-set assignments behind the scenes. AssigneeId and the permission set reference are set when the row is created and are not meant to be edited afterward. To move access you delete the old assignment and create a new one rather than repointing an existing record. The object also carries standard system fields such as SystemModstamp, and it is exposed in both the regular API and the Tooling API. One practical detail matters for integrations: a permission set can require a permission set license, and the user must hold that license before the assignment will succeed. If the license is missing, the insert fails with a clear error. Checking license availability first saves a lot of confusing failures during bulk assignment jobs.
ExpirationDate and time-boxed access
ExpirationDate is the field that makes temporary access safe. You set it when you add the assignment, and Salesforce removes the grant on its own when the date arrives. To use it you first enable Permission Set and Permission Set Group Assignments with Expiration Dates in User Management Settings. After that, the Add Assignment flow offers a choice between No expiration date and a specific date, with quick options like 30 days or a custom date and time zone. The official wording is precise here: assignments expire at 11:59 PM on the date and in the time zone that you specify. If you pick your local time zone, expiry follows your clock, not the assigned user's. This single field replaces a recurring chore. Cover-during-leave grants, project team access, and audit-period elevation used to linger for months because nobody filed the cleanup ticket. With an expiration date the cleanup happens by itself, and access that was meant to last two weeks does not quietly become permanent. It is one of the highest-value, lowest-effort habits an admin can adopt.
What happens when an assignment expires
Expiration does not always delete the assignment outright, and the exact behavior is worth understanding. Per Salesforce, when a timed grant lapses the user can no longer access the permissions tied to that permission set or permission set group, even though the assignment record may remain in an expired state. Access through other sources is untouched. Permissions the user holds via a profile, a non-expiring permission set, or a non-expiring group still apply, so expiry trims only the access it was responsible for. There is a reporting wrinkle to plan around. Salesforce notes that SOQL queries do not return user assignment information for assignments that have expired, so a plain query of PermissionSetAssignment will look like the grant is simply gone. Admins who need the history can use the ALL ROWS clause to see expired and soft-deleted rows. Salesforce can also mark an assignment as expired automatically when it removes a permission that a required license used to include, which gives admins a signal to review and adjust their permission design rather than silently losing access.
Why the additive model leans on assignments
Salesforce now recommends keeping profiles thin and granting most access through permission sets, and assignments are the mechanism that makes the model work day to day. The idea is to separate who someone is from what they can do. The profile sets a small baseline such as login hours and a default record type, assigned once and rarely changed. Capability is layered on through Permission Set Assignments that can be added, removed, or expired independently. The payoff is fewer moving parts. Instead of maintaining dozens of near-identical profiles that differ by one or two checkboxes, you keep a few base profiles plus a library of focused permission sets, then mix and match them per user through assignments. Auditing gets easier too, because you can see exactly which assignments a user has and revoke any one of them with a single delete. Migrating a profile-heavy org to this pattern is a real project and usually runs across several releases, since you have to recreate profile permissions as permission sets and reassign carefully. The long-term operational simplicity is what makes the effort worthwhile.
Assigning at scale and the system-user gap
For everyday work the Setup UI is enough. You can assign a permission set to one user from their detail page, or assign many users at once from the permission set with Manage Assignments and Add Assignment. Beyond a handful of users, the PermissionSetAssignment object becomes the better tool. Data Loader can insert thousands of assignment rows from a CSV that maps AssigneeId to PermissionSetId, and Apex or the API can do the same inside automation. There is one gap the UI cannot cross. Certain user types, including guest, Self-Service, integration, and system users, do not appear on the Manage Assignments page at all. To grant or review permissions for those users you must work directly with the PermissionSetAssignment API object. This is a common surprise when configuring integration users or guest-site access, so it is worth remembering before you go hunting for a user who is not in the picklist. Bulk deletes work the same way, which makes large cleanups, like removing a retired permission set from every assignee, a single query-and-delete operation rather than fifty manual clicks.
How to assign a permission set to a user
Assigning a permission set to a user creates one PermissionSetAssignment record. The quickest path for one or a few users is the Setup UI; for large batches use Data Loader or the API against the PermissionSetAssignment object.
- Open the permission set
From Setup, enter Permission Sets in the Quick Find box and select it, then click the permission set (or permission set group) you want to grant.
- Start a new assignment
Click Manage Assignments, then Add Assignment. Select the checkbox next to each user who should receive the access and click Next.
- Choose an expiration option
Select No expiration date for a permanent grant, or Specify the expiration date and pick a timeframe such as 30 days or a custom date and time zone. This requires the expiration feature enabled in User Management Settings.
- Save the assignment
Click Assign. Salesforce writes the PermissionSetAssignment record and the user immediately gains the permissions in the set.
Lookup to the User who receives the grant. Set at creation and not editable afterward.
The permission set, or permission set group, being granted. One assignment references one of these.
Optional. The date the grant is removed automatically, at 11:59 PM in the time zone you choose.
- The user must already hold any permission set license the set requires, or the assignment fails on insert.
- Guest, Self-Service, integration, and system users do not appear in Manage Assignments. Assign them through the PermissionSetAssignment API object instead.
- AssigneeId and the permission set reference are not updatable. To move access, delete the assignment and create a new one.
- Expired assignments are not returned by plain SOQL. Use the ALL ROWS clause to retrieve expired or soft-deleted rows.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Permission Set Assignment.
- Manage Permission Set AssignmentsSalesforce
- Permission Assignment Expiration ConsiderationsSalesforce
Hands-on resources to go deeper on Permission Set Assignment.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Discussion
Loading discussion…