Back when we were building SharePoint 2007, a member of our Program Management team left Microsoft, and I inherited the permissions-related features for the then Content Management Server team, which was responsible for all of the web publishing features in SharePoint. Essentially, this meant that I has to figure out what the correct set of permission levels were for our features, and what lists/libraries should have unique (non-inherited) permissions.

Now, if you’ve used SharePoint for any length of time, you’ve no doubt been frustrated with permissions management. It’s definitely a sore point. Unfortunately, I don’t have any magic bullets or golden hammers. When I started trying to figure everything out so that I could make educated decisions for our designs, I realized that I needed to write stuff down. People always asked questions like, “What rights do Designers have by default?” Sure, you can find out by going to the site itself and checking, but the UI isn’t the easiest to navigate, and oftentimes what you really want to do is compare multiple permissions levels. “What rights do Designers have that Contributors don’t?”, for example. To help keep it all straight in my mind (and so I could point people to the info rather than answer 100 emails a day with the same question!), the SharePoint Permissions “Cheat Sheet” was born.

It’s nothing fancy, and it’s certainly not anything that no one else could have created. But still, it has proven useful over the past few years. I still keep a copy of it pinned to my office wall. It’s pretty self-explanatory. The first sheet has a table of the default publishing permission levels and what fine-grain permissions each of them has. The second sheet is just the descriptions of each of the fine-grain permissions so I didn’t have to go hunting through the UI to find them whenever I was wondering what the differences were. Finally, the third sheet is a list of “securable objects” (which what I decided to call a list/library that had broken away permissions inheritance and was independently secured) and what default groups had what rights to those locations by default. This was particularly important since in general, you want to avoid breaking permissions inheritance if you can, and we wanted to be very deliberate about where we did, and also track them to ensure they made sense over time.

So how exactly do you use this? Well, it can be a handy reference as-is, but chances are that you have your own permissions level or have modified the existing ones to suit your needs, so you can modify this sheet to reflect your own custom permissions and keep track of everything. It really is helpful to have a centralized reference of all of the various permissions levels. If you go through and put in your own levels, you might realize that there’s a lot of needless duplication in the custom permission level you might have created. When it comes to SharePoint permissions, less is better, so this can be a helpful auditing tool as well as a reference.

A couple of disclaimers… This was created based on the RTM version. As far as I know, nothing has been changed in SP1 or SP2 that would impact it, but I haven’t been checking to keep it up to date. If you do notice errors you can let me know and I’ll try to correct it. Also, this obviously won’t take into account any customizations that you may do that would alter the default permission levels. If you use this for any of the purposes listed or for additional things, leave a comment! I’d love to hear how it’s working for you and if it’s been helpful.