What do you do when you receive a request for access to your SharePoint site? Accept it immediately (because you want to be done with it, or you feel a bit ashamed that you have excluded someone) or find out exactly what they want because there may be more to the request than meets the eye?
Yes, I thought so. 🙂
Let’s dig a bit deeper into Access Requests. There’s quite a lot you can do with them, including creating unique permissions. You know that I hate that!
Microsoft explains this in detail but of course they they let you figure out all the implications by yourself. Or by me :-).
If your email address is in the Access Request Settings, you will receive access requests via email, and the requests will be replicated in the Site settings > Access Requests and Invitations page.
How does it work?
When you get the access request in your mail, you will see the link to the desired content. You can immediately click the “Accept” button from the email and give them Contribute permissions by default.
Yes, Contribute. That means they can edit the content.
Hmmm, perhaps clicking Accept immediately is not such a good idea after all. Perhaps Read-permissions are good enough. Or, if you have sent this link assuming they had access, it may be a good idea to give them access to the complete site.
Alternative: the Access Requests and Invitations page!
So, here comes the Access Requests and Invitations page to look at (and manage) the request.
You will see three categories: Pending requests, External user invitations and History.
Here again, you can click Approve or Decline, or check first what will happen if you click Approve. So, click the … next to the name of the requester. This pop up opens:
Here you see some more info:
What Office365 has decided about their permissions. In this case Office365 would add them as an individual to this document with Contribute permissions – most unpleasant!
You can click the drop down to select the Contributors or Visitors group for the site.
Who has asked access and what exactly for. Hover over the link to see the URL.
Date and time of the request
Email conversation with the person who requests access. You see I was busy writing this post, so the impatient Mystery Guest asked for permissions again 🙂
What would have happened…
If I had clicked Accept from the email or Approve from the Access Request page, this is what would have happened:
Exception: Site welcome page
There is one exception to this rule and that is when you send the link to the welcome page of the site. In that case the requester is added by default to the Members group. This also may be more than you want, though.
After approval, the request ends up under “Show History”. This gives a nice overview of everything that has happened in your site.
If you see a name very often, it may be an idea to give them access to the whole site.
When you receive an Access Request it may be better to spend some time figuring out the details, than to click Accept immediately. This will cost you some time now, but will save you time fixing unique permissions later (and dealing with even more access requests because too many inheritances are broken!).
Have you found any other “interesting” behavior of the Access Request?
As I am writing help materials for our new intranet I do not only have to think about “HOW do you do this” but also “WHY would you do this” and “How can you do this BEST, without spending too much time, adding maintenance or messing things up?”
With the migration of content to the new platform, many Site Owners need to rework their publishing pages. Generally these pages contain (clickable) header images, Promoted Links, Summary Links and links in the text.
On the old platform, when you want to grab the link to a document or image, you go to the library, right click on the name and select “Copy Shortcut” from the pop up. This is no longer available in SharePoint Online.
So, how does one get a link in SharePoint Online?
I have found 3 ways to link to a document, page or image:
In Summary Links as well as the Rich Text Editor on a page (Wiki page style), you can browse for the link to a document or image that lives in your site or site collection.
You can open the item and grab the URL from the address bar.
There is the new Get a Link option, which you will see when you select a document or image from a library, in the Action Bar (is that what it’s called?) and the pop up menu.
The users in my company are all accustomed to grabbing a link when they want to share a document via email or on Yammer, so I think this “Get a Link” will appeal to them.
However, at first glance I see 5 different options. What to select?
Let’s find out how this works!
Microsoft has already written about this but it is not very detailed.
So, I have created a brand new site in my own tenant. In this site I have uploaded 5 documents, each named after the action I will take.
I assume the file type is irrelevant so I have used a mix of Excel, Word and PowerPoint.
Please note I am the tenant admin, so I am not a normal Site Owner. Some things may work differently for a regular Site Owner with Full Control.
My tenant is almost out-of-the-box and external and anonymous sharing has been enabled on all site collections.
How to use Get a Link:
Select the document and click “Get a Link”
Select one of the 5 options
Click “Create” (if the link has already been created earlier you will immediately see “copy”
Click “Copy” and the link will be added to your clipboard
Paste wherever you need it.
You can remove a link if you longer want to share. This means the link will be disabled if someone clicks on it.
For links with “no sign-in required” you can set an expiration date. This means the link will no longer work if someone clicks on it after the expiration date.
2. Using the “View” and “Edit” links will break permission inheritance for the document as soon as you hit “Create”.
Yes, you may want to read this again:
Using the “View” and “Edit” links will break permission inheritance for the document as soon as you hit “Create”.
I was a bit worried about the word “guest_access” that I saw appearing in 4 of the 5 links, so I decided to check the permissions of my site.
Microsoft mentions this in the small letters of their post, but it is easily overlooked.
4 of the 5 docs have broken permissions inheritance! The permissions have not changed yet, but the inheritance has broken. This may not appear to be a big deal now, but if you ever happen to add a new group or individual to your site, which is not unlikely, you will have to remember to give them access to these documents.
Do you seriously think any Site Owner will remember this? Or have the time for that?
More scary and inconvenient findings
As soon as someone clicks on a link they are added to the permissions of the document, regardless of their existing role in the site.
People in the Members group get all the options for “Get a Link” as well!
I have tested this in my work environment and it turns out Members can see and use the “view” and “edit” options so they can break the permission inheritance of documents without the Site Owner being aware!
You can only find out which links have been created by checking the options for each document. Click “remove” if you see that an unwanted link has already been created. Now go find out which of your links (In a text, in Summary Links etc.) used this link 😦
You can remove the link, but the permission inheritance is still broken.
You can only “delete unique permissions” per document, so you have to go to Site settings > Site permissions > Show items with different permissions > View Exceptions > Manage permissions > Delete unique permissions.
This is a tedious process.
I think this can turn into a serious issue. I have found that many Site Owners do not fully understand the consequences of broken permission inheritance, and do not understand the extra maintenance and support issues involved. I have tried to tell them NOT to break permission inheritance unless it is really needed, and to never do this on a document or item level.
And even if they know, it is a time-consuming job to reset the permissions.
Also, why all this complexity for just getting a link? I think only the “Restricted link” would be sufficient. Who would ever want to use the “edit” options when linking to an image? Why would you use the “Get a Link” option to share via email if there is also a “Share” option which sends an email? (and which, in some cases, asks permissions to the Site Owner first?)
What would I recommend if you need a link?
Use the “Insert > Link > From SharePoint” option to link to a document or image when working in the text editor of a page
Use the “Browse” option when creating Summary Links
Use “Get a Link > Restricted View” when you want to get a link otherwise. This respects the permissions of your library.
Instruct your site Members about the dangers of Get a Link and ask them to use the Restricted Link.
What are your experiences with the Get a Link functionality? Have you been able to reduce the scope and if yes, how? I would appreciate to hear and learn from you!
Kitten image courtesy of Top Photo Engineer at FreeDigitalPhotos.net. Text added by myself.
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?