Our view of SharePoint includes our content and the content to which we have been granted permissions, but what if we need to see something else?. If we remember Set Theory, the documents we can’t see is the Compliment of us relative to SharePoint. This is illustrated in the first Venn Diagram below by the part of Circle A that does not lie within the intersection of Circle B. No matter how you decide to organize your SharePoint environment, sooner or later you are going to run into one of two problems. Problem one, you are going to find documents in a common library that should not be available to everyone with access to the library. Problem two, the inverse, you are going to be told that “Joe will be helping us review this document” and Joe doesn’t have access. The magnitude of these problems depends on where in the hierarchy the request is made. SharePoint provides us with many ways to deal with this problem, but each solution has its price.
Permissions can be changed at any time, extended in broad or granular fashion and tailored to meet very specific requirements. I can give someone access to Sites, Libraries, Folders or even individual documents if I need to. In my last reference to Set Theory, I call attention to the addition of a third set a.k.a. Circle C, or perhaps “Joe”. The issue is obvious, adding individual or overlapping permissions gets very complicated very fast. In addition, the problem with this approach is that “who has access to what?” is usually only shared by the person who owns the content and the person administering SharePoint. I might add that only the administrator is likely to remember the unique permissions a year later.
A different approach is to alter the site structure to create places where different groups of documents are stored and the corresponding support staff has access. In other words, make your storage granular and your permissions general. This might alleviate the need to remember “who has access to this library?” Unfortunately, it leaves you with a new problem – “where is that document?” Either way, you are dealing with the second diagram and you need to consider that it has seven possible locations as opposed to three.
Project Sites – Several years ago, I thought I had found the best of both worlds, a Project Site. Project sites are designed to support multiple disparate groups of people as they work on individual projects. Resources like calendars, task lists and contacts can be shared, but libraries have their own permissions. This works well during development, but when the project is complete, the product (often a document) usually needs to go someplace else. The original problem appears again when some of the people on the team that created the document no longer have access to the final product.
Fortunately, SharePoint 2010 added the necessary tool to make my favorite solution work – Document IDs. Now, a document can be developed in one library, and then moved to a permanent repository while appearing to be in both places. If I only want one copy of a document, I can move it to its permanent home, assign granular permissions and leave a link to the document in the place it was developed. If I don’t want to mess around with granular permissions, I can leave a copy of the document in the site where it was developed, but store the original in the appropriate repository. Either of these approaches lets the people who worked on a document reference their prior work while everyone else finds things where they expect them to be.
#SharePoint #permissions #sharepoint