Permission Set Group Assignments with Expiration Dates

Tweet

Introduction

Permission set group assignments with expiration dates are in beta in Summer 21, and do pretty much what it says on the tin - when a permission set group is assigned to a user, an expiration date can be specified after which the assignment will be removed. This might seem like a small change, but it's a powerful one. The release notes mention the obvious use case - someone needing additional permissions for the duration of a project, but there are a fair few more that spring to my mind. 

Use Cases

Pilot Program 

If you are trialling some new functionality and you want everyone to try it out and give feedback by a certain date, provide access to the app/tab/custom objects through a permission set group and set the expiration date to the pilot end date. The artificial scarcity introduced by a hard deadline usually focuses effort.

Scheduled Elevated Permissions

Does your accounts team need access to a bunch of Salesforce data to carry out invoicing, but only on the last day of the month? You can create permission set assignments programatically, so just set up a scheduled apex job that supplies the expiration date, along the lines of :

PermissionSetAssignment psa=new PermissionSetAssignment(
                                  AssigneeId='00580000001ju2CAAQ',
                                  PermissionSetGroupId='0PG1E000000PAv7WAG',
                                  ExpirationDate=Date.newInstance(2021, 06, 20));
    
insert psa;

and there's no need to clean up the access later.

Elevated Permissions for an Event

When attending a trade show, you often want those attending to be able to capture leads even though that isn't their usual role. Assign them the permission and expire it at the end of the day of the event and it's one less thing to worry about afterwards.

Additional Help for New Joiners

When new staff are being onboarded to Salesforce, it can be useful to give them additional information or a way to get help on the pages that they regularly use, but once they have found their feet you can remove the stabilisers (training wheels for our friends across the pond). Create a group with a permission set containing a New Joiners custom permission and assign that to new joiners with an expiration date of two weeks time, and you can conditionally display information based on that. 

 Like an explanation of what a Lead is and how it is worked

Maybe Another

This one I haven't really thought through, but it relates to the sudo command, which in Unix like systems allows you to take on the security privileges of another user, typically the super user.  Using the programmatic assignment from above, users with the appropriate permissions could elect to give themselves additional permissions for the day, thus allowing them to carry out some destructive changes when they need to, but stopping them from accidentally deleting records on other occasions.

The One that Got Away

My favourite use case that I came up with turned out not to be possible. It was going to be punishing bad actors and the example was removing the ability for a user to change the amount or probability on opportunities if they were doing this too often. A muting permission set seemed like it would offer this capability, but sadly these can only mute other permissions granted from the same permission set group rather than remove a permission from a user regardless of where it came from. Shame.

Follow @bob_buzzard