← Back to Blog

Information Context using SharePoint

An overview of how to use and maintain information context while architecting sites, storage, and collaboration services with SharePoint.

In SharePoint we find ourselves needing to use the massive toolkit provided by the platform in order to create reliable information architectures that are user friendly, appropriate, and will stand the test of time. In doing so, our goal is to deliver a total solution that is both understandable and salable such that users are able to get started right away while allowing the architecture to hold as more and more content is pumped in over time. For today's post, I'm going to be using a hypothetical property management company called ABC Properties Inc. I'm sure there is one, maybe many companies, with this name, but my post isn't meant to reference them in any way.


It turns out, as is often not so uncommon, that ABC has been using SharePoint for some time. As is often the case, the person who setup their information architecture wasn't aware of the best practices, and so they subsequently have just a handful of sites, each with a library or two, and tons and tons of folders, many with security inheritance broken. This often results in users not being able to locate the content they need to complete tasks relating to their many properties located across many states. They usually can't find the content, not because it isn't there, but because the security is set up in such a convoluted way that they cannot see that it's there in the first place. These problems are further complicated by the fact that each of the properties is a user account, rather than the actual people who work there, meaning their user access accounts will be called "Property 1 Manager" for example, rather than "Susie Q". This was probably done so they could secure all those lovely folders more easily. The problem with all of this isn't only that things are hard to find, but that we are lacking any information context whatsoever, so even if access was setup properly, people, even if they were the real people, wouldn't know where to actually save the content.

A Context Based Architecture

In order to begin resolving the disorganization at ABC, we'll need to start over with a new architecture. We'll start by making a new site collection for properties. We'll use this site collection to create a property site template where we can create all the libraries for different types of information that we want to store about each property. We'll also remake the teams and departments into a new site collection called departments. Note that is ABC were a bigger company we could make each department or property it's own site collection, but since it's SMB we will streamline it down to just a few site collections. Finally, we'll make users for each actual person that's out there using the system, and we'll control their access at the site level such that all users will be able to see all the properties where they have access and things within those sites will be relatively predictably similar or familiar to users.


Once the old content has been migrated to the proper new locations and re-secured, you'll notice we now have quality information context, a predictable security model, simplified configuration on all levels, and real audit and tractability for user content access activities. Remember, SharePoint is not a file server, and the use of folders should be minimized wherever possible, but especially where security changes are needed. Always make such changes at as high a level as possible, such as the site or even site collection level, when possible.

Happy SharePointing!