The other day I came across an interesting tweet:
Classic mistake. Removed users from a #sharepoint group. Only to realise a few days later that the group was used by 2 other sites. Oopsie 🤓
— Philip Worrell (@Worrelpa) July 18, 2017
Yes, been there, done that! And this made me think of all those other times that I, or my users, have made a mistake with permissions, either by forgetting to think and doing this on routine, or by ignorance.
Here they are, for your learning and enjoyment.  Laughing is allowed; sharing your own bloopers is encouraged!
2. Deleting a group
Did you know that deleted Groups do not go via the Recycle Bin, so they are gone for good?
So, when you want to do this, first check to which content the group has access. If that is only to your site, you can safely delete it; if is has permissions to other sites, please talk to the owner(s) of the other site(s) first!
How to check: Click on the group name on your permissions page, click Settings >Â View Group Permissions and you will see a pop-up like this:
3. Removing a group from a site and forgetting its name
Good luck finding that in your site collection’s list of groups! (which likely contains at least 3 x as many groups as there are sites, and most likely many more)
A good naming convention, as well as keeping some documentation or screenshots of your permissions setup may help limit the damage. Another good idea is noting the MembershipGroupID’s of the group’s URL. These can be found in the group’s URL, e.g.
…/Share/_layouts/15/people.aspx?MembershipGroupId=165
The 3 default groups of a site are created with subsequent numbers, so if you remove one of those you can probably find them by changing the MembershipGroupID at the end of the group URL. In the screenshot above, Owners, Members and Visitors group have numbers 164, 165 and 166, respectively.
4. Clicking on “manage parent” to edit permissions
You need to change permissions of a site that has inherited permissions. Without thinking you click on “Manage parent” and start making changes, not fully realizing that you are now changing the permissions for both sites. You should have clicked on “Stop Inheriting Permissions” first!
The damage can vary.
I have once changed the top site of a site collection that way. The good news was that I finally got rid of a lot of outdated “Limited Access” users, but it was only later that I realized I had also removed everyone’s permissions from various site collection galleries.
5. Removing yourself from a group, site or library
This is generally annoying but benign, as long as you have quick access to a site collection administrator who can add you back. Â I get about one call a week from someone who has locked themselves out.
6. Not clicking “Show Options” when you share something with “Everyone”
This sends an email to all the company (and gives them contribute permissions if it is a site). Well, at least people know you and your site exist, but I do not know if “Everyone” will appreciate your marketing tactics! 🙂
And (in my opinion) the most disastrous of them all:
7. Inheriting the permissions from the parent site
You click “Delete unique permissions’ without realizing you are not at the document library, but at the site level. The permissions of your site will now be the same as the parent site.
You may not be the site owner of that site. Even worse, you may not even have access! An even if someone is kind enough to create unique permissions again and give you back your access, all unique permissions are gone.
An example: this site has unique permissions.
This site has some content with different permissions
When I click “Delete unique permissions” in the site I get a warning in a mix of English and Dutch – which is the first time I have seen this:
And if you click OK the permissions are inherited from the parent and there are no unique permissions anymore. The original groups also have no access anymore.
While this may be a good reset of your site if you have completely lost the overview of the permissions, it can be a nightmare if you have a well-managed site with confidential content that needs well-managed unique permissions.
General recommendations
- Make sure you have an overview of the permissions of your site. It can be a simple mention in the description of the list or library (“this list is only accessible for the MT”), or a separate document with a detailed description.
- Stop and think before you hit a button – if in doubt contact your help person.
Have you made any other permissions management mistakes? Do share!
Update March 2018:
Via Twitter I received some more gems from Stefan S:
8. Renaming a SP group that is used in the Target Audiences setting of a webpart; it will disappear. You should re-enter the group.
9. Forgetting that Members groups have the permission level Edit instead of what used to be Contribute.
Nice blog Ellen. And yeah, you’re not a real SharePoint Specialist until you’ve completely destroyed the permissions on an intranet, and then fixed it. 🙂
Another gotcha is 100% SharePoint’s fault- caused by setting the current user (as an individual) as the Owner of a newly-created SP group. Then when that person leaves or changes roles, no one else (other than Site Collection Admins or Farm Admins) has any visibility into that group’s membership. Group ownership should NOT be automatically set to the current user- the group creator should be prompted to select from available Full Control groups, or some other method, to guard against this scenario.
Thanks, Nancy! Yes, that is a very annoying habit of SharePoint, and one that I spend a lot of time remediating.