Get Started with Session-Based Permission Sets
Learning Objectives
After completing this unit, you'll be able to:
- Describe what a session-based permission set is.
- Explain why you’d want to use a session-based permission set.
- Create a session-based permission set.
The What and Why of Session-Based Permission Sets
If you work with permission sets, you know how useful they are. Permission sets allow you to create a set of permissions for assignment to users. For example, you can assign the Edit Case Comments, Manage Cases, and Edit Activated Orders permissions to all Support managers in your org by enabling all three permissions in one permission set for easy assignment.
Session-based permission sets operate under the same principle, but with an added session-activation option. A computer session begins when a user logs in and begins to interact with another user or with a device. For example, when you authenticate into your computer network at work, you begin, or activate, a session that lasts until you log off or until the session ends for another reason. A session can end, for example, if a company’s security policy requires that sessions inactive for a specified number of minutes time out. During the session, you can perform certain tasks, such as submit expenses or post and reply to coworkers on Chatter. When you log off, your session becomes deactivated and you can’t perform these tasks until you authenticate into the computer network again, beginning another session.
With session-based permission sets, you can limit functional access for select permissions in a permission set to an activated session. When a session ends for any reason, a session-based permission set must be activated again before the user can access restricted resources.
Let’s say your org created a custom object called Conference Room that’s used for a mobile app named Conference Room Sync. The app has read and update access to this object, which allows employees to manage room equipment. Employees who can access this object should only have object access if they’re in a specific conference room. And, for security reasons, they can access only some of the equipment in the room. Once the person is out of the IP range of the conference room or if the session is inactive, the user must reactivate the session-based permission set to gain equipment access in the room.
Why would you want to do this? Perhaps there’s a shortage of conference rooms. The interview team and its support staff are the only ones who should access the room since it must remain available for interviews your company has been conducting. Hence, you don’t want anyone outside of the team to have access to the conference room app, so you limit access to the IP range of the router for the physical space. The conference room also contains some expensive equipment that only trained staff should use. The permission set limits access to the projector and audio equipment only.
Or, perhaps you have a web application that accesses confidential information. For security reasons, you want to limit user access to a predetermined length of time. You can create a session-based permission set that activates only when users authenticate into your environment using a token. When the token expires, the user must reauthenticate to access the application again.
In the following units, we walk through setting up a session-based permission set, assigning it, and making it easily accessible to hiring managers to access employment contracts that contain sensitive employee data.
Follow Along with Trail Together
Want to follow along with an expert as you work through this step? Take a look at this video, part of the Trail Together series.
Create a Session-Based Permission Set
If you’re working your way through this unit, you probably already know how to create permission sets. In case you don’t, though, go back and visit the Control Access to Objects unit in the Data Security module before continuing. Alrighty, now that we have that detail squared away, let’s continue...
Creating a session-based permission set is easy. Really easy. In fact, the steps are close to identical to creating any other permission set. The difference? You must select Session Activation Required when you create your permission set:
Selecting Session Activation Required indicates to Salesforce that a permission set becomes enabled only with an activated session.
So, let’s say that hiring managers need access to employment contracts. You want managers to have access to the contracts when they need it, but at the same time the information can be sensitive. Once a manager finishes reviewing a contract, one of the recruiters has the option of ending the session, which deactivates the permission set and ends access. To access the contracts again after the session was ended, the hiring manager reactivates the permission set.
Go ahead and create a session-based permission set now.
- Use the Quick Find box to find Permission Sets in Setup.
- Click New.
- Label:
Employment Contracts Access - API Name:
Employment_Contracts_Access - Session Activation Required: selected
- License: --None--
- Label:
- Click Save.
- In the Find Settings box, search for and select the Contracts object.
- In Object Permissions, enable the Create, Read, Edit, and Delete permissions.
- In Field Permissions, enable Edit Access for Contract Name, Contract Start Date, and Contract Terms (months).
- Click Save.
It’s useful to note that at this stage, this new session-based permission set isn’t of much use. Why? It’s because there is no active session attached to it yet. When you select Session Activation Required, the permission set does nothing until a session is activated for it. Oh, and of course, we must assign the permission set to someone. We do that next.
Resources