A Practical Guide to SharePoint Site Permissions

SharePoint permissions can be complicated. Whether you’re brand new to site ownership or a seasoned vet, keeping permissions as simple as possible is always a best practice. It will keep you from losing your mind.

This post will give you some guidance on how to set up permissions when you get or inherit a new SharePoint site. Follow these proven practices and things will remain simple and easiest to manage.

Benefits of SharePoint permissions

SharePoint permissions — also known as SharePoint security by IT geeks — has a bunch of benefits to you, your team, your extended colleagues, and others who have access to your network.

In the IT field, we talk about the impact of “security trimming”, basically that there might be a ton of content out there on your SharePoint system, but you typically only have access to a certain amount. That other content is “trimmed” from your view. Few people have access to everything; usually that God-like access is limited just to the IT admins.

It’s actually kind of like Facebook. There’s a lot of Facebook content out there, but most of it is out of sight from you; it’s protected. Same here.

Here are a few reasons why SharePoint permissions can be pretty awesome:

1. Permissions give you the option to hide draft information so those who shouldn’t see it, can’t.
2. Team site access can be limited to that team. It can be grown or shrunk as the team changes, too.
3. Centralized information can be hosted for basically everyone as necessary. Need quick access to the cafeteria menu? Drop it in a relevant document library that’s available to anyone.
4. SharePoint permissions can use already-created user groups from Active Directory (more on this later), so you don’t have to keep giving access out to individuals.
5. You can also make ad hoc SharePoint groups that can be used across different sites. Keep them updated and your sites will know who to allow automatically thanks to one central group roster.
6. If someone’s given a link to a file or site that they don’t have access to, they won’t see the content, which means your stuff stays protected. They can request access, but nothing says you have to give it to them.

By having access only to some content (not the whole system’s worth of files, folders, and sites), your search results will contain less extraneous information. That info can’t show up in your results, which is a win for you when you’re looking for stuff.

Owners, Members, Visitors, oh my!

SharePoint gives you three permissions groups in every new SharePoint site: Owners, Members, and Visitors. It’s a good idea to stick with these. You are free to create new SharePoint groups any time you want, but it adds complexity, many times unnecessarily.

In some cases, it might feel good to create a new SharePoint group, but you should always fight the urge and truly convince yourself you require a new group. Every new group makes a site more complex, which makes a transfer of ownership more difficult in the future.

By default, Owners have “Full Control”, Members have “Edit” access, and Visitors have “Read” access. You can of course change these; in fact, I recommend making a change for the Members group in every site. But otherwise, I would stick with these the way they come because 1) it’s simpler and 2) when someone takes over for you, you want the transition to be as easy as possible. Super complicated permissions setups do not make for a fun experience for a new Owner.

Below is the page you see when you create a new site. You get the option to create the new groups. You can rename them and you can choose to utilize already existing groups to take the place of the Visitors, Members, and Owners. I don’t recommend it. Use the defaults. And take advantage of adding people to your groups now if you’d like.

How are you using your site?

The intended use of a SharePoint site should dictate how you give out permissions. If you’re in charge of a site that houses final, published information — your HR department’s intranet site, for example — you should give read access to a lot of people, edit access to very few, and ownership to even fewer. If you own a team site, you should give out mostly edit access; people have work to do, so let them do it. Don’t give out read access if you can avoid it; and limit the owners as well. For other types of ad hoc sites, it’s really your call.

Owners group

This group gets full control of the site. Owners can create, edit, and delete pretty much anything in a site, including deleting the site itself. As an Owner, you may not be the business owner, but you’re the business process owner for hosting content, arranging the architecture, building and updating lists, and overall helping make your colleagues and team more streamlined.

This is a pretty important role in your organization and should be considered part of your job description. A good site owner has obvious value in a team because work gets done with fewer barriers and delays. Things… just work, and you’re a highly valuable addition to your team. Make sure your boss knows this.

Rule of Three

A good SharePoint site needs no more than three Owners. That’s right, three: the primary Owner, a backup, and one secondary backup on the off-chance the primary backup isn’t available.

I know what you’re thinking: “But so many people need access to update the site to do this, that, or the other thing.” Okay, but they don’t need to be Owners. So don’t give them ownership. Make them Members. And only give them Member access to the lists they need it on.

You may not like this recommendation, but it’s not arbitrary. This is a proven practice that comes from many lessons learned and practical success that I’ve experienced overseeing my own sites and an entire network of sites in my professional life. Trust me: this rule makes for the easiest setup available. Here’s why:

1. You need more than one Owner. When you’re out, somebody has to play your backup. The second backup is meant to further minimize the risk of there not being an available backup when needed.
2. Not all Owners are of the same caliber. The fewer Owners, the less risk of something getting broken by a less-experienced Owner.
3. Fewer Owners means more control when changes to the site are being made. When someone wants to change something in their site, they come to you and your two colleagues; you can then make the recommendation on the smartest solution. If there are a bunch of Owners, one may just go off, make the change because “it’s not a big deal”, and you all may regret it in the future because of unintended consequences.
4. Keeping the Owners group small ensures true ownership of the site. If there are ten Owners and a problem arises, there will be a lot of finger pointing and “I thought it was his/her responsibility” making an appearance. Trust me. Been there.
5. If you’re the primary Owner, you’ll need to train any other Owners. Training two people is way easier than training seven.

I have yet to experience a situation where the rule of three hasn’t been the best solution. And I’ve been around a lot of SharePoint sites in my day.

One last tip on being an Owner: always list the names of the Owners on the home page. I usually provide a SharePoint contact list with the names, phone numbers, email addresses, and working schedule of the Owners so users immediately know who to contact if there’s a question or issue with that site. One of the biggest design flaws on Microsoft’s part is not providing an automatic listing of Owners on every site. People need to know who’s in charge!

Members group

Members are people who can make changes within a site. They can post documents, update lists, respond to surveys, and basically take part in content development, curation, and use of the site. My recommendation for using the Members group is pretty simple:

• Change the default access level from “Edit” to “Contribute”: For some reason, Microsoft decided to up the default access level for Members in SharePoint 2013 (and later versions). “Edit” gives people the ability to create, edit, and delete lists in addition to everything you can do with “Contribute”. It’s pretty likely that you don’t want people to screw around with lists that you took a lot of time to create, customize, and build. So restrict their permissions to the “old” normal from the start. This is my recommendation regardless of the type of site you’re dealing with.
• Team sites: If you own a team site, where you and your colleagues are collaborating on in-process documents, forms, files, lists, and whatnot, make as many of your teammates Members as possible. They should all have the access available to make changes to content because, well, they’re doing work! Let them!
• Publishing sites: If you own a publishing site, where most of the content is finished files, policies, etc., you should have few-to-no Members. I know, a lot of Owners don’t like this recommendation. But frankly, the content is prime time and as few people as possible should have the ability to change things. You don’t want an inadvertent or unauthorized change to take place under your watch. So limit the permissions in the publishing area if you can. As an example, in an HR publishing site, have separate document libraries for each function: one for benefits, one for labor documents, one for policies, one for recruiting, etc. The members of each of those teams should have Member access to each of those libraries so they can update information as necessary; but nobody else should have edit access to those libraries.

Visitors group

Visitors are people who have read access to a site. They can open files (and even download them), but they can’t make changes to content. They are meant to consume content, but not create, update, edit, or delete it.

Basically, it’s the same as when you go to Amazon.com. You don’t edit the list of things to buy. You read it. You choose the ones you want, but you don’t change the inventory for others to read. As a typical internet user, you are a Visitor to almost every site out there.

My recommendation for using the Visitors group is even simpler than Members:

• Team sites: Frankly, I believe if you are a member of a team, you should always be a Member in that site. But I realize there are times when outsiders to the group (upper management, reviewers, people who just need to remain “in the know”) need read access but not edit access. So generally speaking, in a collaborative space, I suggest having as few Visitors as possible. Read access potentially hinders work getting done.
• Publishing sites: Publishing sites are meant to share finalized information with a lot of people. Your corporate or organization’s home page is a publishing site. Lots of people need access. Those people should be in the Visitors group. Your HR benefits page is another good example. If you’re not on the benefits team in HR, you should have read access to files related to insurance, retirement, etc., but you shouldn’t be able to change the files (even if you want to so you’ve got better benefits!).

Other SharePoint groups

You can create as many SharePoint groups as you’d like. This is useful if you have an ad hoc collection of people you want to be able to provide access in other sites elsewhere in your SharePoint environment.

One thing to consider: make sure to update the owner of each of the groups in your site as the Owners group. Unfortunately, by default, SharePoint makes the group owners the individual who created the site (or the group), not the Owners group. Logically, the Owners should have full control of the site and the groups used in the site. If you don’t change this, and the selected individual leaves your organization, you can’t change or update the settings of the SharePoint group without getting your IT department involved. If you update the group owner to the Owners group, whoever is an Owner in the future will have the ability to make changes to those groups.

Active Directory groups

Active Directory is the tool Microsoft provides to keep track of people in a network. When you email someone from Outlook, it’s pulling information from Active Directory (or AD for short). AD offers the option to create groups too. And they aren’t SharePoint groups, so don’t mix them up.

AD groups offer a huge benefit: if your organization updates AD groups for your departments, teams, and whatnot, you can make use of them in SharePoint. Many HR departments include updating an AD group as part of the onboarding and termination process, which means the AD groups are likely current and trustable when you use them in SharePoint.

The most useful example is using an “All Staff” type of AD group, which gives you a very quick and automated way to give access to all users in your network. (It might be known as “All Staff”, “Staff”, “Domain Users” or something similar. Each IT/HR department comes up with its own terminology.) I depend on these types of groups when I create and share publishing sites that might have company-wide information. A communication portal site, the HR benefits site, accounting forms library and the like generally would have “All Staff” as part of the Visitors group. That way I don’t have to individually add and remove users as they join and leave the organization. Someone else does the work for me, using a centralized, dependable process.

If your organization doesn’t use AD groups, it’s a hindrance to productivity and your IT and/or HR departments should really consider doing so for the benefit of anyone that uses SharePoint… or Outlook! It’s one of the easier way to email a group of people without having to look for individual user accounts or email addresses.

Note that the benefits of AD groups only comes from internal users. You can’t really get that benefit when discussing clients, vendors, and other outsiders unless they’re part of your AD group or there has been some federation setup with those organizations, which is a complicated topic to get into and not something I plan to cover here.

Breaking permissions inheritance

One of the most powerful aspects of SharePoint is “object-level permissions”. This is a fancy term for “you can give access to individual items in SharePoint without giving access to a whole site or system”. And it’s a huge benefit in SharePoint.

By default, all of your content in your site inherits permissions from the site itself. So access is the same on file A as file B as library X as list Y as the entire site. The option to break inheritance means you can make access unique for a file, library, list, or anything in that site.

This is super tempting and can be extremely useful. But it can be very dangerous because as you break inheritance, you’re significantly increasing the the complexity of your permissions setup. That’s not a bad thing, but you have to be ready to keep things under control once you do. Thankfully in SharePoint 2013, 2016, and Online, there’s the ability to see who a file, list, library, or other item is “Shared With”. This option is available in the ribbon of any library, list, item, or document; see below. In earlier versions of SharePoint, that wasn’t the case, so permissions became a total nightmare. Now they’re just a partial nightmare!

That said, you still have to tread lightly when it comes to breaking inheritance and providing unique permissions based on individual items. Here are my recommendations:

1. Stick to libraries and sites: If you need to break inheritance, don’t do so at the individual file. Drop those files into a folder, library, or even a separate site and manage your permissions from there. It’s way easier.
2. Use SharePoint groups: Don’t break permissions by giving individuals access. Create a SharePoint group for the occasion and use that instead. It’s easier to update a SharePoint group in one place — then enjoy every item that pulls that group in its permissions automatically — than having to make a change all over the place when someone joins or leaves your organization.
3. Use Caution: I’m by no means saying not to take advantage of object-level permissions. I use it regularly. But I know the risk. Things get complicated, and intentions are easy to forget. Best to document reasoning behind your permission architecture (see below).

Document your setup

Once you’ve set up your permissions structure, you should document it. I like to have a library in all of my sites called “Owner docs” or something like that. In this library, I keep a file that covers the permissions structure, any images used in the site itself, a document that covers the description of the site, intended use, and whatnot.

I know documentation sucks; nobody likes to do it. But you won’t own your site forever. This documentation can help your backup owners and anyone else who comes in to take over as an Owner in the future. In fact, it’s a great time-saver when you have a new backup owner come on board. It means less time needed to train them and they have a resource to hit up when you’re out and they have to make a decision that may impact the vision and purpose of your site.

Documenting your permissions is basically governance on a small scale. And while it’s not fun, I find it to be critical.

External sharing

SharePoint Online now offers the option to share with users outside of your organization’s network. And that’s a really powerful upgrade to the service. But it’s out of the scope of this post. I’ll cover that concept in a separate post because it deserves its own description, analysis, and recommendations. Everything mentioned in this post assumes you’re only providing access to users within your network or organization, not outside people or groups.

Conclusion

Keep it simple. Stick to the out-of-the-box groups. Minimize object-level permissions. Make use of AD groups when you can. Document your setup. Three owners max. For publishing sites, very few Members, many Visitors. For team sites, many Members, few-to-no Visitors. Always do a sanity check when you’re moving away from these principles to make sure you absolutely need to. And stick to your guns when people protest. You’re the expert.