The Guts & Glory of Global Permission Sets

Globals are Permission Sets that are not associated with any specific license type. Prior to Winter 13 when creating a Permission Set you were required to select a license type to associate it with in order to then assign it to users with that same license type (using The Permissioner of course). This caused some potential issues as you could, and often times would, duplicate the same exact Permission Set just because one of them needed to be assigned to a Salesforce.com licensed user while another to a Force.com licensed user. This was not the most efficient way of doing things but it’s completely understandable why this paradigm existed - specifically because certain license types simply cannot do certain things. Take, for example, the simple object permission ‘Edit Cases’. If you tried to create a Permission Set with a Force.com license selected you wouldn’t have the option to grant Edit Cases within that Permission Set because a Force.com licensed users can’t perform that action. This makes perfect sense and is the reason that the Permission Set assigned to a license type rule existed in the first place.

Do Globals Solve this Problem?

In actuality Globals do not solve for this specific problem. The main thing that Globals allow you to do is create a Permission Set and decide that you don’t want to assign it to a specific license but instead you select to assign it to “none” meaning it can be assigned to any user in the entire system. Wait, hold on, that makes no sense though, if a Force.com user can’t edit Cases then how am I going to assign them a Permission Set that says they can edit Cases? Did we just find a loophole in the Salesforce licensing scheme? No, we didn’t. As a matter of fact, while this new Permission Set we created isn’t assigned to a license type we can still only assign it to users who can perform the actions that are within the Permission Set itself. This will mostly likely, and unintentionally, create a sort of proliferation of Permission Sets in it’s own right. I like to include as many permissions as possible within a Permission Set so that I don’t have to create multiples and with this issue outlined above I still would need to create multiple Permission Sets, one for the users who can edit Cases and one for the users who can’t - even if there are seven other permissions within the set that everyone can use.

What Problems do Globals Solve?

I do think this Globals is a step in the right direction even though I’ve spent a few paragraphs knocking it down a peg or two. Where Globals excel is for simple Permission Sets like Delete Accounts. The only thing I want to grant is the ability to Delete Accounts in this set with no other permissions weighing me down. In the past I’d need to create multiple Permission Sets, one for each license type. Moving forward since deleting Accounts is a permission accessible by more than one license type I can simply create a Global for deleting Accounts and assign it across the board. This usage of Globals does meet the goal of eliminating unnecessary duplicative Permission Sets.

In addition to solving for all common objects and fields across all license types they also can be utilized to grant access to Visualforce pages and common system level permissions. The access to Visualforce pages is specifically useful when building out admin type screens to manage processes as well as pages being exposed to both Salesforce users and Portal users.

All in all Globals are a good addition to the Permission Set lexicon. They allow more flexibility across multiple license types and can in certain circumstances remove duplicative Permission Sets.

Want to talk more about Permission Sets? Comment below using Disqus, on our Facebook page, or chat with me directly on Twitter @JustEdelstein.