SharePoint Document Management – Doing it Right!

Security is a real issue when we are discussing SharePoint Management. You know that. No wonder one of the most common mistakes enterprises are facing when dealing with SharePoint, is having end users with more access privileges to documents that they should.

It seems a simple problem to solve, but the reality of controlling employee’s access to confidential content, and making sure their access is not too broad, is a challenge for many.

That is why I decided to include, as one of the coverage points of our SharePoint Document Management blog series, some tips about SharePoint permissions, sharing how to give access to resources correctly, how to prevent SharePoint security breaches, and how to plan your permissions without compromising your document management and automation system in SharePoint.

Plan for SharePoint document management

1. Analyze existing documents. Determine document types, properties;
2. Create a flexible and easily extendable Content Type structure;
3. Choose where and how to store documents in SharePoint;
4. Create fields, sites, libraries and lists. Add Content Types;
5. Plan for permissions;
6. Define and automate SharePoint document naming;
7. Unify document templates location;
8. Distribute content to smaller files;
9. SharePoint Document Automation;
10. Implement Workflows;
11. Optimize views and libraries;
12. Findability and Search;
13. Backup & Recovery;
14. Plan retention and SharePoint Content database growth;
15. Have a Migration plan.

Step 5. Plan for permissions

Planning permissions is a crucial part of every document management system, not only because of the confidential factor of enterprise content, but because inconsistent security plans can provide hard to overcome obstacles to the company document generation process.

You should plan them carefully especially in environments with lots of documents or items, or when content needs to be moved around constantly. With growing number of documents and libraries you can easily lose track of permissions, get performance issues and compromise security.

Not only you may require securing differently the same document to distinct users, but also you may have to change its set of access permissions during its lifecycle. And this is what makes this scenario so challenging. I will go through both cases now:

Setting SharePoint Permissions according to Users

You will notice that SharePoint did a great job providing options to customize permissions, and in the most diverse aspects, making the process of building a document management system really unique to every enterprise.

SharePoint Groups

The first aspect is that SharePoint not only allows the permissions to be set to individual users, but also to a group of them (SharePoint Groups). Permissions granted to a group are valid for all the users included in it. The rule here is: Use groups to assign permissions, leaving user based permissions only to really specific cases.

Note: For SharePoint 2010, Microsoft recommends to use AD groups, instead of using SharePoint groups, because of the limited search continuous crawl capabilities.

Group Permissions – recommendation by Microsoft

The secret is how you plan your SharePoint Groups. Make sure you group users with identical access demands. Try filtering them by department, or project, or even job description. The less unique cases, the easier it is to keep track of what is going on.

Where to set permissions in SharePoint

The second point is that permissions can be set according to where the users should have access to: from a more broad access, with a root Site Collection level permission, to more precise ones, like Site level, List/Library, Folder and Item level. With the help of some 3rd party tools, you can even set Column level permissions.

Where to set permissions in SharePoint

Always assign permissions to the highest level possible. Permissions of lower levels are inherited from parent ones, unless you break them and create a unique permission called Fine Granted Permissions (FGP). In most of the cases, Site or Library level permissions should be sufficient.

SharePoint Permission Levels

The point I want to bring up is that, if a SharePoint permission level is not absolutely precise for your needs, you can duplicate it and customize it to your demand. E.g.: customize the Edit permission, excluding the option to delete documents.

Changing Document Permissions during its Lifecycle

Like I’ve mentioned before, sometimes you will have to change a document’s permissions during its lifecycle or according to some business process.

For example: One group of users should have only “Read” documents permissions in a library, and they are required to participate in an approval Workflow. However, participating in workflows that don’t contain an impersonation step may require users to have “Edit” permissions. To work around that situation you can apply different techniques to control access.

Technique One: using Workflows

You can use a secondary Workflow that changes the user’s permissions to “Edit”, only for the approval action to get completed. You can do that by breaking the Permission Inheritance, and setting the “Edit” permission to that particular user or group.

After the user approves the document, you simply need to bring back the permissions by inheriting library or folder permissions again. This can be done by another workflow. Try to Google “How to Create a Workflow to Change Item Level Permissions” if you need more instructions.

Another option is to use Event receivers to control edit permissions. This is very powerful, because you can make security decisions based on any metadata of a list or library.

Technique Two: using Folders

You can use different folders with different sets of permissions and move documents between them to control access during the document’s lifecycle. And don’t worry about loosing workflows history or other data. They are safe as long as you are working in the same SharePoint Library.

Technique Three: using Groups Membership

Sometimes, when you have custom modules in place, you may wish to restrict access to specific features, buttons, etc. For that purpose, use group membership. For instance, you can create a SharePoint group and name it accordingly. Then you can add specific users or groups to the SharePoint group to allow them to use or execute a feature. Of course, your code behind it should be adapted for that kind of scenario.

Define Security Responsibility

Who is going to be responsible for maintaining your SharePoint security? That is a critical question that if answered wrong can erase all the work done so far. New users and new documents are always going to be created, and if the security plan it’s not followed correctly, a security breach can be created in a blink of an eye. Study your company structure and determine a responsible user.

This is what I wanted to present related to permissions. If you have any questions or suggestions, just leave us a comment. And please check it out the next posts of this series where I will discuss the importance of an automating document naming, and much more.