It is a really good list of why you should avoid folders on SharePoint.
My own planned post on this topic is now completely redundant 🙂 . But I would like to illustrate his point 4: why maintaining permissions on folders can be a nightmare.
What are the issues with folder permissions?
If you break permissions and add “Different permissions!” to the folder name, as I always suggest to do, the URL of the folder and all its documents changes. People who have this link in their Favorites and use it after the change, will get an error. That is another reason why folders are a bad idea: Links to folder, sub-folders and all documents in the hierarchy change when you change the name of the folder. Libraries and lists have a description field for that type of info, folders have not.
Broken permissions are not easily visible, so unless you add something to the folder name (causing issue 1), you will not know what permissions your folders have. The only way to find out is by going to each folder and finding out. If you have a deep nest, you will have to start at the bottom of the hierarchy. Not a fun job 🙂
People often are in a hurry to give someone access, without thinking about a sustainable setup, or writing down what the permissions are exactly.
Having many folders with broken permissions, especially with individual permissions, may cause performance issues.
Now let us zoom in to one document library (the yellow block) in a site. What if it has 4 folders, 2 with inherited permissions (yellow) and 2 with broken permissions, each differently?
OK, this is getting complicated, right? Now what if one of the folders has 4 sub-folders with different broken permissions? And sub-sub-folders? Or if the folder and sub-folder inherit permissions from the site or the library, but the sub-sub-folder has broken permissions? The potential issues multiply with each sub-folder.
You can imagine that managing and supporting that kind of setup becomes a difficult task – if a new person enters the team, where do you have to add him or her? And where do you need to remove their predecessor?
In one of my next posts, I will share some examples where breaking permissions in folders has led to misunderstandings, problems, urgent phone calls and me having to spend lots of time on cleaning the mess that someone else had made 🙂 .
Image courtesy of Suat Eman / FreeDigitalPhotos.net
Some time ago, a Team Site Owner asked me if I could help her move some content from one site to another. Since she had Full Control in both sites, she had the right to ask and I helped her transfer some large libraries and lists.
I then asked her what to do with the rest of the content. There was another library with a large number of documents in there, and the usual array of semi-empty Calendars, Task Lists etc.
She said she did not need anything else and that the site could be removed after some time. So we agreed that I would add a message to the site’s homepage, informing people of the new location for the content, and the date when the site would be removed.
At the agreed date I removed the site.
Several months later…
…another person from that department asked me about a certain library that he could not find anymore. He sent me the link and I saw it was the large library in the site I had deleted…
It was too late for a restore so the content was lost. Of course we all felt devastated, and I made a short analysis of what had gone wrong. As with most major accidents, it was a combination of several mistakes.
What had happened?
One content owner had removed all other people with Full Control from the library, and made it accessible for himself and a few other people only. So, the other people with Full Control did not see the library anymore, including the person I had worked with.
They used only the direct link to the library to check the documents. They never went via the homepage, so they never saw the message that the site was about to be deleted.
There was no message in the description of the library, so I had no reason to assume that there were any different permissions in that library.
What have we learned?
Never remove the Owners/Full Control group from a library. The Owners should be able to manage their site properly. If they do not see all their content, they may make incorrect assumptions.
Add information about different permissions to the description field of the list or library .
Ask the SharePoint administrator for a screenshot of the “View site content” page before you decide to delete a site. The administrator sees all content, and you can compare that with what you see.
This was the situation:
As always, your comments, suggestions and shared experiences are welcome!
In my earlier post, I showed default site permissions and what happens when you break permissions in one library.
This time I will show another common scenario with non-standard permissions, that may give issues if you do not set it up properly.
Scenario: Your list or library has a larger audience than the rest of the site. This is quite common when you conduct a survey or have a request list in your site. You give your target audience contribute access to the survey or request form. They will generally not need to do anything else in your site.
In the picture below, the yellow circle is an additional members group with access to the one list, only.
This is an adequate setup if you are conducting a one-time survey, or have a request form where you invite people to participate via a link distributed by email. But in the following cases your users will still experience issues:
If you use a “Thank you page” after submitting feedback. The “Thank You” page lives in another part of the site. Users will get an access denied as soon as they hit “Save”. Their feedback will be saved, but it is an unpleasant experience which will lead to many questions.
If you send them the link to the site, and ask them to navigate to the survey or request form, or click the survey/request form link or button. They will get an access denied when they try to enter the site.
If there are drop-down fields in the request form that use lookup lists. If they do not have access to the lookup lists, they will get a blank drop-down box.
Suggestion for a different setup.
Determine if the rest of the site content is very confidential. If yes, store your survey in a less confidential environment. If not, proceed with 2.
Add everyone in your audience to the a new group with Read access
Create the survey, request form, library or other “app” 🙂 (I think it is really funny that lists are called Apps now)
Now break permissions in the list or library
Edit permissions for the new group from “Read” to “Contribute” in that list
Break permissions in any confidential lists/libraries from your visitors and remove the new group. (Optional)
Your site’s permissions will now look like this. Much better and less issues!
Giving people access to one library or list only, is like asking the painter to come in through the window, not through the front door. It is better to let him in through the front door, and close or lock some rooms, than the other way around.
Next time, another example of how breaking permissions can go really bad!
Do you know what the following questions all have in common?
“I see a completely different homepage menu/libraries/folders than my other team members”
“I can no longer check out or edit a document”
“I know he has access to the list, but he can not access the link I send him”
“I have given her full control, but she still can not see that library”
“I can no longer access the site or library that I am supposed to manage”
Yes, you guessed it – these questions are all permissions-related.
It sounds really neat and useful to be able to limit access to sites, libraries and folders in SharePoint. It is easy to add groups and individuals and set it up just the way you think is best.
Many people, however, do not realize the full consequences of breaking permissions (= giving subsites, lists, libraries and folders different permissions than the site). As a result, I provide a lot of support on permissions-related issues.
I have found it hard to help users understand how it works in words, so I have created a series of pictures for clarification. You know I am not a designer, so if you have better visuals, please share!
Default site permissions.
First, let us show what the permissions in a “normal” site look like.
The fat dark blue line is a site. The blue blocks are libraries and lists. Or apps, as SharePoint 2013 calls them. 🙂
The purple circles are user groups. There is an Owners group (O) with Full Control, there is a Members group (M) that can read, add, edit and delete, and a Visitors group (V) that can read.
All lists and libraries have the same permissions throughout the site.
When we add an individual or another group to the site, (the circle with the person icon), this person/group will also have access throughout the site.
2. Site containing a library with different permissions.
Let us assume there is one library that contains confidential information, and we do not want Visitors to see that. You go to “Library Settings” and “Permissions for the library”, you edit permissions and remove the Visitors group. You add a note to the description of the library that this has different permissions. Visitors will not see the library anymore.
The permissions have now been broken, hence a dotted line around the library.
Next, you want to add new people to the site. The best way is to add them to one of the groups – they will have the correct access. But if you add a new group or an individual to the site, they will not see the library. That is because the permissions have been broken, meaning that the site and this library no longer align and you need to maintain both entities. So, you have to give this person/group access twice…that is double the work!
But…Owners often forget that they have broken permissions. So they give someone access to the site, but that someone can not see the library. They then give that someone Full Control to the site, but they still can not see the library.
I hope the picture below shows you why.
Now you know why I recommend to add a message in the description field of the library – that helps the Site Owner remember! And of course you see the benefits of adding new people to an existing group instead of as individuals.
So yes, breaking permissions is easy to do. Maintaining and supporting, however, is a lot of work!
First let me stress that I recognize that some content is sensitive and really needs to be secured. But there is also a lot of content which is not confidential, but which you still may want to hide, to avoid information overload in general. Specific reasons may be:
The content is only relevant to a certain audience
You do not want people to influence each other
You want to allow people to focus on their own content, e.g. in projects or tasks lists
Next to giving permissions there are two other ways to hide content that I know of, but I will be happy to learn new ways!
In SharePoint it is relatively easy to target web parts to an audience. In any web part menu, click open “Advanced” and add the audience, SharePoint group or person(s) to the Target Audience box on the bottom. Only they will see the web part.
We have used this especially to target links on the Homepage – in the main navigation, every employee had a link to the Employee Information of his/her country.
I have also used targeted web parts in Monthly Reporting in a Team Site.
a. Item-level permissions.
For surveys and lists, you can let people read only the items that have been created by themselves. (Advanced settings). This is nice if you do not want people to influence each other, but not very useful when you want to show the collected information to your audience. I usually apply it only in survey-type occasions.
b. Created by = [Me].
When not using the item-level permissions, I like to use this filter for the default public view. That way people see their own items first and are not influenced by others, and they can not easily edit other people’s content. You can have additional public views showing all contributor’s items, or the process owner can create personal views and use web parts to display content from all contributors.
c. Impossible filters that show an empty default view.
We have used “Created < 01-01-2000” as the only public view to create an empty looking document library, accessible to all employees. The documents were distributed to other (secured) sites via Content Query web parts. Of course, the owners of the documents created personal views to see all documents. The advantage for the content owners was that the owners of the secured sites could manage access for their site.
d. Hidden columns. In older versions (e.g. SP2007) you can create views without the Edit button, and without the “Name” column instead of “Name (linked to item/linked to document with edit menu)”. This way, your readers will be unable to click on any items to see the complete item. Of course this is useless for Document Libraries, unless you only want to show that the documents are there.
Perhaps this can also be done in Office 365, but since I am the only one in my environment, I have too many permissions to test this.
e. Closing/hiding the web parts in the list or library. You can close or hide the system web part of the list or library to avoid anyone seeing the content, including the site owner. I would recommend this only for very specific occasions, since it is very annoying to have to make the webpart visible every time you want to do something. Besides, every visitor will immediately see there is something wrong with this page.
f. Sending people to a non-default page after submitting data. I often send people to a Thank You page after completing a survey or other data collection, by customizing the link. It is a nice gesture, it confirms that submission has been succesful and it allows you to give more information about next steps. It also hides other people’s responses from view.
I have also sent people from a topsite to a request form in a subsite, and after completion sent them back to the original page in the topsite. They did not have to see other people’s requests, and this way they could continue to do what they were doing in the topsite. Well, you will get the idea; you can use this with all pages within your environment.
g. Removing the link from the title of a web part. The title of a list/library web part on a page is clickable and leads you to the complete list or library. If you do not want that, go to the web part menu, open the “Advanced” section and replace the link under ” Title URL” by “#”. Jasper Oosterveld also shares the screenshots.
People will still be able to go to the list/library via Site Contents, though.
Targeted or hidden content will normally still turn up in Search. People can also see it when they have the link to the information, or know how SharePoint works. This is not confidential information, so it is not a problem, but it helps to be aware of it. Do not be afraid that people will go and look for this info – they do not know it is there and they probably do not care if they knew.
Many people do not understand the difference between targeting (visible yes/no) and setting permissions (access yes/no), especially that you target a web part, but set permissions on a library or list. Be prepared for questions.
If you are the site owner, but you are not in the targeted audience, you will not see the content, so it will be difficult to maintain the web part. This is especially the case with Content Editor and Summary Links web parts, because they are not represented in the “back-end” of your site, i.e. the page showing all site content. This may occur when you are managing global content distributed over various “country” web parts.
If you target something and you are in the audience, you may forget that the content is not visible for everyone. Mention it in the web part title as a reminder.
Remember to discuss any targeting and personal views when handing over responsibilities for a site!
What other ways have you used to hide content without changing permissions?
“Oh yes, our employee benefits information should definitely be secured”, the country HR manager said. “We do not want everybody to see that information”.
It took me some time to convince him that this was really not a good idea. I had to come up with various arguments:
Why would employee benefits be confidential content at all? Of course, people from other countries could see it and perhaps be jealous. But everyone knows there can be local differences in benefits, due to local laws and customs.
The information was published in a not very visible place and only employees in that country would have a link to it on their Homepage. Everyone else could find it in Search, or navigate to it if they knew where it was, but that would take a conscious effort which not everyone has the patience for.
The information was meant for about 700 people, how confidential is that?
Maintaining security for 700 people would mean a lot of work. (Generally a good argument against securing content, by the way :-))
In the end I won him over by telling him that he already had a perfect natural security system: he was the HR manager from Sweden and the majority of his content was in Swedish…;-)
This is just one example of people thinking their content needs to be secured. I have worked with many who were under the delusion that without restricting access, their site would bend under the weight of visitors and servers would crash by the flood of people eager to get a glimpse of that fabulous intranet content or application.
Wake up to the harsh truth, content owners! We still have to drive people TO your content, rather than chase them away FROM it. More organizations are struggling with a too low usage (“I can not find it”, “I did not know it was there”) than with too high usage. What is “too high” anyway? And what actually happens when “too many people” see your content? Perhaps the site becomes slow or you get an error message when too many people try to access at the same time, but it is not that your site will break.
We are not satisfied with most intranet search tools because they can not find what we are looking for. Why do we then think that everyone will be able to immediately find our content, and will jump on it when they have found it? I still have to hear of one example of “too popular” content. (And please let me know when you have an example)
Because this is how things go with content:
If people do not know it’s there, they will not visit
If they know it is there but they cannot find it, they will not visit
If they know it is there, they can find it but are not interested, they will not visit
Of course I know that some information needs to be secured, but everything that is not business-critical should be open as far as I am concerned. It will be difficult enough to attract the right visitors to your content, so it is better to spend your time improving your content, usability and findability than on maintaining security groups.
Because frankly my dear, most employees don’t give a damn about your content…