In the course of four years of SharePoint consulting, the one thing I always hear from clients that makes me cringe is, “I don’t want other users messing with my documents.” Shudder. SharePoint is a collaborative tool.
But what happens when we go from collaboration to documents wholly owned by individuals? We create a complex permission hierarchy that is not only hard to document and manage, but is also detrimental to the organization. In kindergarten we were taught to share our toys, and in the business world we need to be taught to share our documents. Restricting document permissions brings with it a host of pitfalls.
The first and most glaring problem created by having SharePoint document permissions restricted to a single user is the sick day. It’s 10 minutes until a report is due and Employee A is sick. Employee A is the only user with rights to the most up to date version of the report in SharePoint. IT has site collection admin privileges, but they’re unreachable, as the newest fire is being put out from their queue. You’re dead in the water.
Now let’s assume that Employee A has decided to leave the company. All of those documents with unique permissions must now be set to the person taking his place. I’d much rather have IT putting out fires than focusing on adjusting permissions to hundreds of documents that belonged to an old employee.
You may even run into a limit of unique permissions, though it is extremely unlikely. SharePoint has a limit of 50,000 unique permissions per list or library (same in 2010 and 2013). If you hit this limit, you have done something very wrong in the managing of your documents.
Do the documents belong in SharePoint?
There are certainly instances where documents must have restricted permissions. Some documents simply can’t be shared (e.g. HR files). In these instances, is SharePoint the right vehicle to store documents? Sometimes.
Even if SharePoint is not used as a collaboration tool, it does still offer some advantages. Metadata is still a powerful tool, even if only one user can see it. Versioning and shredded storage combine to make a killer document history app while not putting a strain on storage. Information management policies can still be applied to the documents despite the restrictive permissions, allowing for archival and deletion of outdated documents.
When those features are not necessary, SharePoint may not be the best storage device. Storing these documents on hard drives is still not recommended for purposes of backup and recovery, but SharePoint’s value is not realized with these documents. A managed network share may be the best option in these cases.
If unique permissions are a must…
Whenever possible, I try convincing clients that unique permissions are not the way to go. SharePoint will track which users have edited a document and keep previous versions for worst-case scenarios.
So what do I do with the documents that require unique permissions and require SharePoint to utilize other functions? This requires understanding the business process and needs, as well as planning for future conditions. Your organization should get a clear understanding of the documents that need unique permissions, who requires those permissions, and establish a reasonable hierarchy.
Most SharePoint environments will already be split into a hierarchy that mirrors the organizational structure. By default, these provide permission guidelines (e.g. human resources owns the content in the HR site). The lists and libraries in the site will inherit the top-level permissions. In the unique permission areas we have defined, these are best handled with separate containers. Containers can be established with separate lists or libraries or folders inside the existing list (this requires enabling folder creation) or library. If the metadata and workflows for the items and documents are the same and only the permissions are different, folders are the best approach for the new containers.
When creating the folder structure, the number of folders should be as few as possible. In the map of unique permissions, start establishing commonalities. If a certain set of documents requires a set of users to see the documents, group those together under one folder rather than having separate folders for each “kind” of document.
For example, if Employees A through Z need permissions to budgets and receipts, place those documents in one folder called “Budgets and Receipts” (or something more inventive). Place the unique permissions on the folder, which will cascade down into the contents. Inside the “Budgets and Receipts” folder, subfolders can be created for the individual document types. Note though that it is not recommended to create a deep folder structure; two or three levels would be the maximum recommended.
By creating these containers and applying permissions only where we need to, the organization has a much clearer picture of what has unique permissions. The organization can also more easily adjust in the future for personnel changes. This does require some upfront planning, but the future payoff will create a return on the investment.
Andy Wessendorf has been a SharePoint consultant since 2010. He works daily with InfoPath, SharePoint Designer and Excel Services. He is active in the SharePoint community and has presented at events, such as SharePoint Saturday.
