Permission Sets in a Lightning World
How have they changed since they first rolled out?
The biggest change is actually not to Permission Sets themselves but actually to the platform that they reside on. Salesforce has changed so much since Permission Sets launched about five years ago. There was no concept of Lightning. There was no Einstein. There wasn’t even Salesforce1 Mobile. It was good old Salesforce Classic with “Apps” that were essentially a series of tabs that users could get to through other means anyway. Since Permission Sets were always built API-first, they easily kept up with the fact that Salesforce has increased all of the features and functions that come along with the platform. Virtually any feature can be turned on and off via a Permission Set, including really big changes for end users like the ability to be a Lightning Experience user or not.
Are they any different now in Lightning Experience?
Simple answer, no. Permission Sets have largely stayed the same in terms of their utility. Their main use is to apply a permission, or set of permissions, to individual users to provide them more access to features on the platform. Of course there are some new features in the Summer 17 release that make life a little easier, like Standard Permission Sets. Just how Salesforce encouraged all ISVs to ship their products with Permission Sets, Salesforce is following suit. An example would be the standard Permission Set for Sales Console. If you purchase five Sales Console Licenses, you can simply assign the predefined Permission Set to five users, and they automatically get the license and ability to use the console. Nifty…
The biggest difference is really how an administrator can go about launching Lightning Experience to the organization. This was a large breakthrough back when Chatter rolled out, and it was all or nothing. Salesforce learned from that “mistake” and allowed, via Permission Sets, to roll Lightning Experience out at a pace that is comfortable and manageable.
A Sign of Maturity Early On
Did you need to change any of your legacy Permission Sets because you flipped to Lightning Experience? Another simple answer: no, you didn’t. This is a testament again to the API-first approach of building out Permission Sets. There are a lot of features on the Salesforce platform that are being “Lightningized,” but Permission Sets are not one of them; they just work the way they have always worked. Nothing new to learn, just create and assign ad-hoc permissions as your heart desires (using The Permissioner of course).
What Next (IMHO)?
Moving forward I would love to see some improvements to Permission Sets to keep up with some of the Lightning features, such as component-level permissions, as opposed to page-level permissions. This has always been a bit of a gripe, but you cannot control page layouts via a Permission Set (which I understand from a technical perspective but hey, I’m just a user here, and I want my page and component level permissions in a Permission Set). Imagine a Lightning App Page with six custom components on it. Now imagine being able to control which users see which components on the page based on a Permission Set - that is a pretty custom, tailored experience. The example before could also have major implications for Community rollouts, as Community Templates get more and more popular.
All in all, Permission Sets remain tried and true. Through all the turbulence of migration to Lightning Experience, which is still happening and will continue to happen for at least a few years to come, Permission Sets remain one of the more reliable tools in the shed.
Please feel free to comment below, on the Salesforce Success Community, on our Facebook page, or directly at me on Twitter @JustEdelstein.
