Demystifying SharePoint permissions
Permissions can become confusing in SharePoint. A few basic principles help clear the mist a little.
The more complex you allow your permissions structure to become, the less secure and, ultimately, the bigger nightmare it is to administer. Here are basic descriptions of permission levels you may grant to your SharePoint site and apps.
Full Control: the whole shebang
This role or permission level should be tightly controlled. Anyone with this access level should be required to have a lot of training. It does permit the person to delete the site and all its contents. Consider setting aside a user ID with this permission and using it only when the job needs that level of access.
Design allows you to create lists and document libraries, edit pages, apply themes and borders, as well as approve items, if you’ve enabled draft item approval or a publishing site. Use this permission to edit and approve pages, list items and documents.
Create new subsites
Designer access grants most of the privileges a subsite owner might need; however, that level does not permit the creation of subsites under the highest level site a subsite owner governs. If your governance favors the creation of subsites, this access level can be added.
Edit allows users to add, edit and delete lists. It also allows users to view, add, update and delete list items and documents. This level of access would be appropriate for core team members who will be creating content to site visitors and enabling business process for the team itself. This requires at least a basic level of SharePoint training. Make sure everyone knows how to restore things from the recycle bin.
This permission level does not allow users to create lists and libraries. It does allow them to view, add, update and delete list items and documents. This would be appropriate for internal team members who only need to add content to lists and libraries, or to site visitors who will be entering list items or adding documents that initiate and further business processes. For example, if you’ve created a help ticket system using Issues List app (template), people submitting tickets will need contribute access to submit tickets.
This restricted access level is granted to those who can only read, but not add, any content. Policy libraries, FAQ lists, contact lists and other
apps where the content is only meant to be consumed, rather than edited, deleted or augmented, should have this as the default access level. While users with this level of permission may not edit the content in the lists or libraries, they may download the content and edit it locally. They will not be able to upload the modified content.
View only allows site visitors to read content but not download it. They will be granted view access in the browser, but they will not be allowed to open it in the desktop Word app.