Understanding SOME of the Pratfalls and Pitfalls of Sharing in a Collaborative World
Digital content sharing with SharePoint is both a tremendously useful set of features and also a set of capabilities fraught with peril – depending on the type of content and the knowledge level of the person doing the sharing.
As most SharePointillists know, SharePoint provides a hierarchical security model. It can get extremely complex either by design or through ongoing usage, but the general scheme goes as follows…
Web Application – This is also known as your Office 365 tenant. Think of this as your collection of offices: your entire company.
Site Collection – Think of this as a “walled security garden”. Your might have an Intranet in one Site Collection at https://tenantName.sharepoint.com and a Project site in a different Site Collection at https://tenantName.sharepoint.com/sites/ProjectXYZ. Think of these as rooms in your offices that can lock securely.
Sites – Sometimes also referred to as Webs (mainly by developers), these include the root site of any Site Collection as well as any subsites. Think of these as standalone filing cabinets.
List and Libraries – These are content “containers” inside each site. Think of these as the drawers in your filing cabinet.
Folders in lists or libraries – While we sometimes discourage the use of folders because of the impact on useful metadata tagging, people will probably always continue to use them – and they aren’t always bad. Think of these as the green (or orange or red or whatever) hanging folders in your filing cabinet. You might use them and you might not.
Individual list items or library documents – Finally we get to the real content! These are the papers or stapled sheaves of papers in the manila folders in the hanging green folders in the drawers in your filing cabinet in the room where you keep your content in your office building in your office in your company.
By the way – metadata? That’s the stuff you write on the manila folder to summarize what’s in it. It’s data about the data in the folder. Very meta.
Permissions can be applied at any of those levels. Applying permissions at too high a level (say, just at the tenant level) means you don’t really have any security or governance at all. If you apply permissions at too low a level (say, on individual documents), then you have an administrative nightmare and rarely really know who has access to what content. (There are performance implications with item-level security too, but I find that the other pitfalls hit you long before the performance ones do.)
Add to the mix that we each have our own OneDrive for Business (OD4B). (We’ll leave personal OneDrive [OneDrive for Pleasure?] out of this conversation, but they also add a wrinkle. At the very least, many of us have two OneDrives. See: OneDrive, TwoDrive, ThreeDrive by John White (@diverdown1964).) Your own OD4B is really meant for you to store your own documents. These documents may be personal, but generally will be work-related in some way. In other words, this is not the place to store your music library.
You may want to occasionally share a document in your OD4B with others, either inside or outside the company. You’ll usually do this from the synced folders on your PC or laptop, but you can also do it through the Web interface or using Office applications like Word, Excel, PowerPoint, etc. Think of this level of sharing as “I have a document and I’d like to show it to you.” You may also want the person you share the document with to make some edits, but it’s more of an ad hoc thing.
If you find yourself working with others regularly on a document or if it will be accessed regularly by a group of people, then it doesn’t really belong in your OD4B. In this case, it ought to live in a library in a SharePoint site. The permissions for that site or library should reflect the membership of the group of people who will play a role in the lifecycle of that document (and its companions in that location). These roles – in a simplistic way – tend to fall into three categories: owner, editor, or reader.
My recommendation is to always try to keep permissions set at the site level, where possible. If you don’t have a key for that specific filing cabinet, you simply can’t see anything in it. Setting permissions at a lower level – either at the list or library level or for individual documents – means you’d have access to the filing cabinet, but only some of the content within it. Knowing who has access to what is confusing, and each person’s view of the site will probably look different, adding to the support issues. Plus, when people don’t understand the permissions, they are likely to just grant highest permissions (everyone has Full Control!) to “clean up permissions”, which actually makes it even worse!
In today’s world, we also regularly want to share content with outside parties. This can be very temporary or quite permanent. We can email files, share individual files, share sites, etc., depending on the needs. “Collabotition” – especially the multidimensional types in some industries like pharma – means that you pretty much have to be good at this. In each case, the person doing the sharing needs to think about:
- what the content is
- why they are sharing it
- who they are sharing it with
- what the time span for the sharing should be
- etc.
Few people consciously think through all of these aspects every time, and as humans we love to do things the same way over and over again. Thus we need to set things up in such a way that we can help or guide people to the right sharing mechanisms – ideally with as little training as possible, but there usually needs to be some.
Outlook adds ANOTHER wrinkle! Office 2016 is extremely “Office 365 aware”. When you attach a file to an email in Outlook from a shared location like your OneDrive for Business, it gives you the option of attaching the file the old way or by sending a link to the document instead. Taking the latter course effectively punches a hole through the firewall to make that document available to the person getting the link.
Other pieces of the governance puzzle that come in here are: retention policies, records management, templating, etc., but each of those are almost conversations in themselves.
All of this can become INCREDIBLY complex, but it only should become that complex when the business requirements dictate it. In many cases people want to over-engineer the technology to prevent people from doing dumb things, and that’s well-nigh impossible. If we lock things down too tightly, then people just start storing things in Dropbox or Google Docs instead, defeating the entire point! Be sure you’re setting things up to both provide a good user experience (UX) AND to protect your organization’s interests. Unfortunately, those two things can often be at odds.