Session Activation in Permission Sets and Permission Set Groups
Welcome to another installment in our security series. Today, we'll delve deep into the intricacies of session activation for permission sets and permission set groups. By the end of this article, you'll have a good grasp of what "session activation required" means and how to effectively use it.
Why Session Activation?
Permission sets and permission set groups are crucial constructs in granting user capabilities. One intriguing feature these have is the "session activation required" checkbox. This option lets us assign a permission set or group to a user, but it only gets activated when a specific action occurs.
Imagine a scenario: You want to grant permissions to a resource but only under certain conditions.
Maybe when a user is near a particular asset, say in a building or a room. You can detect this proximity, activate the permission set, and grant the additional access. This access lasts only for the duration of the session. Once the user logs out, the permission set is deactivated, though it remains assigned.
Let's Dive into a Demo
Consider Paul, our pilot, as an example. We're giving Paul a permission set that allows "view-only" access to airport details and navigation. From a previous video, we showed how using a muting group can mute a specific field. Now, we'll introduce a new permission set granting access to the "Runway" object. This access will only become visible when we activate this permission set. Thus, if Paul isn't in an airplane, he won't have access to the runway details.
When session activation isn't in effect, Paul sees two tabs: "OA Airports" and "OA Nav". The "OA Runways" tab isn't accessible.
To enable session activation, I've written a piece of code. This code identifies the current user, locates the necessary permission set, and activates it for the session.
Here's a brief breakdown of the process:
The permission set "STA Runway Sessions Allowed" is created with the "session activation required" checkbox enabled.
This permission grants access to the Runway object and all its fields.
This permission set is assigned to Paul but remains inactive until our special code is executed.
Upon execution, Paul's session now includes the "OA runways" tab, granting him access to a list of available runways.
This dynamic capability demonstrates how session activation can elevate someone's permissions temporarily.
The next time Paul logs in, he reverts to his original access levels, devoid of the additional runway permissions.
Wrapping Up
Session activation required is a powerful tool, especially when you want to grant temporary elevated access based on specific conditions. The key is to determine when and how you'll trigger the activation.
The possibilities are vast, from location-based activations (like being in an airplane) to event-driven ones.
Stay Tuned
Thank you for tuning in. Remember, security is paramount, and understanding field-level security ensures your Salesforce data remains confidential and in the right hands.
Stay tuned here on www.SteveTechArc.com and to the @SteveTechArc YouTube channel.
Helping change the world by sharing ideas with fellow Architects and those on their Architect Journey!
Wishing you a secure and efficient user management experience!
STA 4.4
