SharePoint Permissions – Permissions Inheritance

SharePoint Permissions – Permissions Inheritance

We have spent the last several blogs focused on topic of permissions. With any luck you’re starting to see that permissions management is not some mystical voodoo, but rather a grouping of distinct components that work symbiotically. Let’s wrap up this series by diving into, what is perceived as, the most complex element of permissions management, Permission Inheritance. We’ve already reviewed security groups, which tell us who will have access, and permission levels, that tell us what we can do with our access. Permissions inheritance tells us where those groups and levels are applicable.  

The word inheritance is almost misleading at this point, we really should call it permissions placement. When a site is first created and the standard groups are built they have “site level permissions”, meaning the place where those security groups have access is, is to the site. In the image below we see a drawing of permissions for a new site. On one side of the image we have the libraries and lists that make up the content of the site, represented by folders. On the other side we have security groups with their permission levels. What connects these two sides together is the site. When we make new security groups SharePoint will automatically try to place the permission level you give that group to the site.

So why is it called permissions inheritance?

By default, when a new list, library, or sub-site is created it will have whatever permissions the site it was created in has. That is permissions inheritance. Let’s refer back to our image for the example. In our site the libraries on the left have the same permissions as the site because they were created in that site. In turn the security group, Site Visitors, has read access to the site and also to the libraries within it.

Now, even though a list or library starts off with the same permissions it is possible to change those permissions. Changing the permissions for a list or library from the permissions that are in the site is called Breaking Inheritance.

There are positives and negatives to breaking inheritance. Each break in inheritance means there is something additional for the site owner to maintain. That said; a break in inheritance might be the best way to ensure proper security for your site content. If you have a good security plan in place and you’ve thought through where content should go based on who is using it and for what purpose, the breaking or retaining of inheritance will provide harmony and ease of use, neglecting to plan your site out before altering permissions could mean a lot of administrative overhead and confused or frustrated users.

How do I know if I should break inheritance for a list, library or sub-site?

The conversation of breaking inheritance is always security related. Is the information in the list, library or sub-site sensitive or should it only be seen/edited by certain people? These are situations when you consider breaking inheritance. Again, establishing a plan for where documents go, and who has access to them will go a long way to making these decisions.

How do I plan for what I don’t know yet?

I’m reminded of a recent conversation with friends. My friends and I are planning a vacation. During a recent dinner we started talking about vacation, we immediately began to ask each other the “who, what, where” type questions.

“Who should we invite?”

“What do we want to do for our vacation?”

“Where do we want to go?”

These questions are really important to making sure our vacation is enjoyable. If we don’t figure out the “what”, we might make it somewhere but then what? If we don’t decide on “who” we should invite, someone might be going on vacation by themselves. If we don’t answer the “where do we want to go” question, well, we’ll never get there, will we?

If we apply that same thinking to permissions management we find that. Permission levels provide the “what” of permissions management. Security groups provide the “who” and permissions inheritance will give the “where”. The combination of those three areas provides us a complete permissions picture.

• Who – Security Groups
• What – Permission levels
• Where – Permission Inheritance

Take any one of these three away from the others and the others would simply have no value. When you create your security plan start with the Who, What and Where, that will give a great place to start. Don’t forgot your ITS SharePoint COE team is always happy to help you in your planning efforts so feel free to contact the team with any questions, comments or concerns.

 Summing it up

As you can see, permissions management while not simple is also only as complicated as you make it. Remember to ask your user community about their needs, ask the who, what and where questions and use that information to create a workable security plan (otherwise known as a governance plan). Remember that permissions management is really three distinct components that depend on each other for success.

Security groups – defines who has access

Permission levels – defines what those groups can do

Permissions Inheritance – defines where in the site those groups have access

SharePoint Permissions – Permission Levels

This is the third in a series we’ve been doing on SharePoint Permissions. Here are the links for the previous blogs:
SharePoint Permissions – Friend or Foe?
SharePoint Permissions – Security Groups


In our last blog we talked about Security Groups and why they are important. Security groups are only one piece of permissions management. Let’s focus this week’s attention to subject permission levels.
Permission levels are shockingly easy to understand once you remove the other elements of permissions management. A permission level determines what a person or group can do in a site, list or library. By default each site comes with some standard permission levels:

• Read - Can view only
• Contribute - Can view, add, update, and delete
• Design - Can view, add, update, delete, approve, and customize
• Full Control - Can view, add, update, delete, approve, customize, and manage permissions

Notice how each level grows from the last one. The advantage is if you need to provide a group with ability to read documents, edit documents, and delete documents, you only need to give them Contribute access and they are off and running. It really is that simple. There are other permission levels out there and custom permission levels can be created, but that is another blog.

Join us next week, when we’ll wrap up permission with Permissions Inheritance.

SharePoint Permissions – How does access really work

SharePoint Permissions – How does access really work?

In my last blog SharePointPermissions – Friend or Foe, I introduced some thoughts on permissions in general terms.

Let’s spend this week and focus our attention to how permissions work in SharePoint. I think it is important to start with defining what “permissions” are. When we talk about permissions in SharePoint we are talking about access privileges to a site, list, or library. It is as simple as imagining a locked door, only someone that has the right key can unlock the door, open it, and walk through. In fact we use permissions every day in other areas of our lives and never think twice about it. The key to your car, for example, means that only the holder of that key can operate the car. Your credit card that you used to buy groceries last week; it too is an example of a key. It tells the grocery store that the holder of that card has the ability to purchase up to a certain dollar amount. The badge you used to get into the building you work in… yep it’s a key too. All of these keys provide the holder permission to perform certain actions or provide certain types of access. 

SharePoint permissions are no different.

Just like the examples we used above permissions are not just waiting out there for anyone to come and grab. One must request and be approved. For the car, someone had to hand you the keys under the agreement that you would pay for the car. You work badge, yeah that sucker isn’t free either. You get your badge only because you have an agreement with your wonderful employer to work once you enter the building.

Okay I think we beat that horse long enough don’t you? You get it, right? Permissions mean having the key to get where you want to go.

When we talk about SharePoint we step up the permissions talk in introduce the term, “permissions management”. For those of you that had that suddenly had this feeling of impending doom wash over you… take a deep breath, we’ll get through this together.

Permissions Management at its most basic is nothing more than granting or restricting user access. Per Microsoft permission management is comprised of three components:

• Security Groups
• Permission Levels
• Permissions Inheritance

It is the combination of these components that gives SharePoint its security and flexibility. This is also where a lot of people get lost. Why? In my experience it is because they try to make all three mean and do the same things, thus confusing themselves and their permissions. Let’s start with Security Groups.

Security Groups

Most new users and administrators of SharePoint underutilize the SharePoint security group. It probably seems a little too, all or nothing. In fact the proper use of security groups gives the administrator the best possible method of managing masses of people and what they have access to.

A security group is a collection of users, ideally that share common tasks on a SharePoint site. A single user can belong to several groups and many users can be in a single security group. A security group on its own is just a group, a collection of users.

An important note, security groups live at the site level in SharePoint. All of the people (users) that interact with any element of a SharePoint site will need to be accounted for in the site. Lists, Libraries, pages, documents and anything that you can set permission levels for will be looking to the site for its collections of groups and will, by design, want the administrator to choose one of those groups when assigning permissions. Can you assign people permissions without adding them to a group? Yes, but that my dear readers is another blog.

Now, getting back to security groups. We now know that security groups are collections of users that share common tasks or a common purpose. For example, let’s say I was an administrative assistant in a company. Chances are there are other administrative assistants in the company as well and chances are that we, the administrative assistants, perform some of the same types of work and need to access some of the same stuff. If I had a SharePoint site that needed administrative assistants to access a report for my boss then I could create a security group called (yep you guessed it) Administrative Assistants and place myself and my fellow co-workers in that group. So when I provide the group the needed permissions, they all get it at once.

You’ll notice that when we talk about security groups the word permissions seems to follow. There is good reason for that. A security group only has purpose once that group is assigned a permission level.

You know what, I just looked at the time and realized I’ve been typing for a while here. I think I’m going to leave us where we are until next week when we take a walk through the tulips of permission levels.

SharePoint Permissions – Friend or Foe?

If there is one thing and seems to scare many users in SharePoint land I would have to say it is permissions. For some reason this topic is cloaked behind a thick fog of confusion and mystery. We are going to dedicate the next few blogs to demystifying SharePoint permissions and shining the light on its pros and cons.

Let’s get started by talking about how SharePoint is structured. To help illustrate this concept let’s use the metaphor of a university campus. Universities are big places with many buildings and lots of things to do. Each building on university campus serves a specific purpose, there are buildings dedicated to science, math, law, music, etc…  buildings can be large or small, old or new. In each of these buildings contain classrooms, offices, libraries, and labs, all focused around gathering and dispersing knowledge.

In the land of SharePoint we have sites, usually dedicated to a single purpose, such as departmental information or program information. In a site we have lists, libraries and pages. All of these are designed to gather and share information. Using the university as our parallel we can think of a site is a building and lists, libraries and such are the rooms in the building. Everyone still with me?

So when we think about SharePoint permissions we can continue the metaphor to include the students and professors. If you were a student attending our happy university, you don’t simply arrive on campus one day and randomly pick a building. No, you go through a registration process. You request the type of classes you want or have to take, what you plan to major in and so forth. Your requests are processed and you are later presented with a series of classes you are registered for and provided information about the time and location of the classes you are “approved” to attend. You are not permitted to attend classes you are not registered for regardless of your desire to take them.

Permissions work very much the same way. You request (or someone requests on your behalf) access to something in a site and an administrator of that site approves or rejects your request. If approved you are given permissions, and you can only enter areas in a site that you have permissions for.

I’m sure at least one of you just though, “yeah, but I can see lots of sites but can’t get to parts of it, what gives?” You can think about that like… a lab. In many cases you can walk into a building at a university but when you try and open a door to a lab or library you might find the door locked and only if you are given the key can you get in. Permissions in SharePoint parallel this by being able to restrict access parts of a site depending on the SharePoint Group you belong to.

Let’s take this idea a little deeper. Let’s further stretch the metaphor and say you are law student. As a law student you can check out books in the law library, or attend law focused study groups. Only students that have declared “law” as their major can use the law library or attend the study group. In the graphic below we can see that thought in images. The student belongs to the group that is called Law Students and Law Students has access to the Law Library.

This mirrors the function of a SharePoint Group. By placing people that perform similar tasks into a group, permissions can be given to the group. While you can add a person directly to a site, list or library, adding them to a group will automatically provide them benefits of being in that group.

Well, that was a whole lot of info to take in, so let’s make this our stopping point for this week’s blog. Check back next week and we’ll dive a little deeper into SharePoint permissions.

Data, data everywhere

Do you sometimes think of SharePoint as a great dumping ground? You upload a document and keep your fingers crossed that you can remember where you put it? Or maybe you go to a site to find something only to be bombarded by pages of folders hiding mountains of documents and no idea how to find the one thing you’re looking for.

It seems to me that when we moved from filing cabinets to computers we forgot how to organize, or, maybe more that we never updated our thinking about organizing information beyond files and folders.
The amount of information we consume is ever increasing and for many of us we cannot just stop reading and writing to reduce the electronic clutter in our lives. We need to find more efficient ways to manage the information we receive and produce. Can SharePoint solve these problems? Well… solve might be a little too strong of a word but it sure can help!

First things, first, we must PLAN for organization.

Plan, PLAN, PLAN

Yes, I know planning has become a dirty word in the work place. I do agree that many times we are stuck in planning ruts, but, a little planning now will help a whole bunch later. Before you create another folder in a file share or site or list in SharePoint ask yourself these questions:

• Who will need to modify or add to this information other than me?
• What will I do this information once I’m done using it? (Will it be deleted and never needed again, does it need to stick around in case someone else might need it, or will it go to another person who will make changes to it)
• Where can I locate other related information?
• When do I need to make decisions related to this information?
• Why would other need to know or care about this information?
• How can I use this information most effectively?

If the information you have or are working on will need to have multiple peoples input SharePoint is and should be your go-to option. After all, it is what SharePoint started out with and it is still what is does best. COLLABORATION. How many times have you created a document and sent it in email to a group of people asking for input just to get back 4 or 5 copies of your same document that you now have to manually merge with your original, yuck! SharePoint let’s you collaborate online and using the same document, keeping track of changes in one place.

If the information you are working with will need to be referenced in the future, again SharePoint is an excellent option. With full search capabilities and the ability to sort, filter and view information in several ways SharePoint can make referencing information easy. I recently worked with an operations team to get a list, an invoice list, into SharePoint. They were having a tough time keeping track of what invoices where sent out, when they were sent and which ones were still outstanding. We turned that one tiny idea, moving a list from paper to SharePoint into a really clean and efficient tracker for that group that ended up saving their company millions. In addition to the money they were now able to enable an approval process they had been trying to get off the ground. With easy to search lists that could be filtered and sorted depending on who was looking at the invoices sales people and managers could easily find information they were looking for or needed to approve of.

Okay, okay, I’m getting a bit off topic. I think the point I really want to get across here is, we all have TONS of information we’re trying to keep track of and we’re not going to be able to ignore it, but we can make it a little easier to manage by using organizational tools, like SharePoint to filter, sort, search and group information. I’ve used a couple examples to explain how organization can happen in the land of SharePoint. To learn more check out these resources:

Manage the information you share through your My Site

Introduction to Libraries

Configure a site library to require check-out of files

Manage lists and libraries with many items

Getting organized using lists

One of my very favorite things about SharePoint is lists. I don't know about you, but, I am a list person. I have them everywhere, little post-it's on my monitor to a quick to-do in the margin of my notebook. I love lists so much I was even an avid user of Excel for helping me track information that was too complicated to keep on paper.

See if this is a familiar scenario for you. I used to have an Excel workbook (that's a spreadsheet with multiple tabs) that I would keep track of team issues with. Each week I would print one of the spreadsheet pages with the open issues and meet with my team, where I handed out the paper and we went through all of the items on the list. Each team member would provide an update and I would take notes, usually on the paper or in my notebook. At the end of the meeting I would go back to my workbook and retype all that goodness from my notes and move rows from one spreadsheet to another as issues were resolved or the urgency of the issue changed. I would spend hours a week in some cases making sure my workbook was up to date. Frequently during the week a team member would drop by and in chatting they would provide an update of one of the issues discussed in the meeting. If I was really disciplined I would open my workbook and go update it, but most of the time… I didn't and things would start to fall behind. Before I knew it my beautiful workbook was out of date and we would stop using it. What a waste!

Sound familiar? 

Of course it does, why? Because we've all been there, we start the Excel workbook with the very best of intentions but over time the data becomes old or cumbersome to manage, we have to rely on one maybe two people to keep all the updates in order, and it turns into more of a hassle than a help. So now what?

Now let's talk about making your information work you instead of you working for your information.

SharePoint lists are very similar to Excel in the fact that they use columns and rows and they have the ability to sort and filter just like Excel. In addition they also have VIEWS, a feature that I think many people neglect. Another significant advantage of a list is… it's online! No more passing around a spreadsheet or having one/two people try and keep up with all the changes that need to happen. In a SharePoint list multiple people can update information at the same time without worrying about errors or corruption. SharePoint lists can also do things that excel just pain can't. Let's say you need some information updated and you have to wait that that update before you can do your piece of work, in Excel it would still need someone to tell you an update has happened SharePoint can do it automatically. The Alert Me function in all SharePoint list and libraries let's you control how you want to be updated.

In another situation similar to the first scenario I use SharePoint instead of a spreadsheet and things went something like this.

The afternoon before our weekly team meeting the team got an email from SharePoint reminding them to update progress on their issues and provided a link the team issues list on SharePoint. The next day I'm getting ready for my teams weekly meeting and I quickly run through the issues that been updated. When the team assembled in the meeting room we didn't talk about the issues list, we talked about how to resolve the issues. No going around the table for updates, instead it became a working session where the team talked about where they were having problems and shared their latest breakthroughs. As we left the room I, being the control freak I am, reminded the team to remember to update the issues list as things change. Later that day I report our issues status by going to a custom view of our issues list tailored to meet the needs of our management team.

That's it… no running around getting updates, no boring meetings, just work… and getting work done.

Don't get me wrong SharePoint can't solve every problem; I haven't found a "world peace" function in there yet. It certainly can, when used properly, streamline processes and reduce the drama of working in a team. It might even make workday a little easier.

Want to learn more about lists? Check out these great resources:

SharePoint Server 2010 Help and How-to 

SharePoint lists I: An introduction

SharePoint lists II: Create and work with different lists

SharePoint lists III: Create a list based on a spreadsheet

SharePoint lists IV: Create a custom list 

Why I started using SharePoint

Every story has a beginning; let me start by saying I am in no way a Microsoft SharePoint "expert". I do not work for Microsoft and I am not being compensated by any organization for this blog. I am however, passionate about making data work for you instead of you working for your data. I have also worked with SharePoint for ten years now and find it is a fantastic tool for leveraging data organization.

I, like many others out there, happened upon SharePoint quite by accident. I was a project manager you see, organizing time lines and tasks, managing risks and issues. I happened to be in the midst of a large scale project when one of my system admins asked if I would help evaluate a new product from Microsoft. It was late 2001 and I was eager to find ways to make my hectic job less stressful and more efficient. I fell in love with SharePoint right from the beginning. Imagine a website that I didn't need to have a developer write or maintain for me. I could post documents, make announcements, and even keep my list of issues posted. I immediately saw the big picture possibilities.

As my project progressed I started to incorporate my SharePoint site into my project. I started telling people, "Let me send you a link to my SharePoint site, I have all the documents posted there". Slowly, people started asking me how to make their own SharePoint site. One of the advantages of being an early adopter is you also get to be an early educator. Me and a few other early adopters of SharePoint, in my company, got together and started hosting brown bag sessions for our fellow co-workers. Talking about what we learned in this situation or how to do this or that. As time went by SharePoint shifted from being this cool little app someone told me about to a grass-roots movement in my company. Everyone wanted to use SharePoint; it was the new shiny toy in the room. I felt like I knew my friend SharePoint really well but I wanted to know more, do more. I developed the belief that if I could imagine it, SharePoint could do it. It was this belief that, in my opinion, changed me from a "user" of SharePoint to a solutions designer.

I started using SharePoint, just to give me a better way to organize, but I now look at SharePoint as a tool to help information I need work for me, rather than me working for information I need. I hope that I can spread that message to others and have them see the possibilities in using the platform we call SharePoint.