SharePoint + Case ManagementJayson Kennedy, Feb 16, 2017
Case Management has never been a simple task in the realm of information governance. Content Management Systems like SharePoint have provided some tools on how to tackle this ever-present issue, but knowing how to use them properly has never been obvious. SharePoint is a huge tool, and being familiar with every aspect of it is difficult.
This article will discuss the benefits of using SharePoint to tackle Case Management, and then mention some of the specific functionality that Collabware CLM has created to address some of the gaps left by SharePoint, or simply make it easier.
First, what is Case Management? A “Case” can be understood as a collection of documents all related to something. That something can come in many forms: a person, a place, a thing, an event, a time period, on and on the list goes. It seems simple; a collection of documents all related. But then you have to consider the “why” of the Case File, as in, why does it exist?
Has the Case been created for the purposes of access, findability, or security? SharePoint makes that rather easy to tackle. Or has the Case been created to facilitate retention, a purely Records Management concern? On this side, SharePoint by itself struggles.
I’d like to break up Case Management into two separate halves, since it will be easier to discuss the strengths and weaknesses of SharePoint if we do so. The two halves are its management and its retention.
As I mentioned above, SharePoint excels at the management of Case Files. There are so many ways to create Cases that the decision becomes more a decision of deciding what not to do, rather than what to do. I will mention a few good techniques that I have encountered briefly, and discuss both their management benefits and their retention benefits.
Cases as Sites
Some organizations choose to create an entire site, either a site collection or just a subsite, to represent a Case. There are some big benefits to this. First, the security and access aspects are greatly narrowed. The Case is only found in one place, and only those who need access to it get access to the site. Likewise, Search can be managed very easily, since all the content is collected in one place. Users can either browse the site structure or search the contents of the site. Simple keyword searching might not be ideal, depending on the volume of the Case, but there are other ways of tackling findability within SharePoint.
The only drawback of creating a Site to represent a Case is that retention is not very easy. You could always lock down the Site by removing all users’ permissions and then eventually just delete the site and its contents, but this isn’t very formal. It doesn’t align with many of the best practices in records management, because it relies on users tracking the retention of the Case separately from the Case itself. It’s usually best to tie the retention of a Record or Case to the item itself. This reduces the amount of mistakes that can be made. SharePoint does provide some tools to allow administrators to apply retention at the site level, but this must be done by the SharePoint management team, rather than be automated and tied to a File Plan. As always, features that require the IT Team to get involved are much more difficult to roll out than an automated records management system that can be activated by regular users.
Overall, Cases as Sites are very easy to create and manage. Likewise, for the end users, finding and contributing to Cases is very simple because it is all in one place. Retention can be applied, but it can be complicated and messy.
Cases as Libraries
Drilling down further the SharePoint ladder, we come to representing Cases as a Library within a Site. This method makes sense for those Cases that are created repeatedly, like Employee Files or Procurement Processes. Users once again have the advantage of having all the content collected together in one place, and even the Case Type is collected together on the same Site. Searching within a library is even easier than searching across a Site, because there are Sorting and Filtering options within Document Libraries. Document Libraries can be updated to use a custom Content Type that has metadata fields supporting the Case File, although this metadata capture can only be done on documents associated with the Case, not the Case itself. Still, having custom metadata fields on a library dedicated to a single Case is excellent, because Libraries can have Default Metadata Values, allowing any item uploaded to it to automatically have metadata values with zero user input.
However, you cannot apply retention to a Library with SharePoint’s Records Management tools. Whereas Site Collections can be, there are no options to apply individual retention to a library. The list would need to be locked off in some way and then deleted by an administrator. It is possible to declare all documents inside as a Record and apply retention to them in a bulk way by levering a script to update a “Case Closed” date, but this requires a bit of technical expertise.
Cases as Document Sets
The bottom-level, so to speak, of the SharePoint hierarchy. Obviously, we cannot go any further down, because all that is left are the documents themselves. As we already established, a Case is a collection of documents. But Document Sets, what are Document Sets?
A Document Set is the combination of a Folder and a “Document”, sort of. Document Sets allow documents (and Folders) to be created inside of them, acting like a Folder. But Document Sets can also have their own Content Types and metadata values. They can be treated like documents, including have versioning. Document Sets also come with the excellent feature of being able to “share” metadata values with the documents inside, meaning that if the Document Set and the Document both have the same metadata field, updating the Document Set will update the Document. Not even Default Library or Site Column Values can do this, because they cannot update metadata values after-the-fact. Obviously, the more metadata, the better. Metadata is the cornerstone of any good Content Management System, and SharePoint excels at this. In fact, Document Sets can even be configured to come with a default set of documents already created inside of them when they are created. It’s brilliant.
However, these benefits once again come with the downside of not allowing Document Sets to be declared a Record in place, which is extremely unfortunate. You can send the Document Set to the Records Center, and at that point it can have retention applied, but this can be a major drawback, considering Document Sets tend to be living records and need to be either continuously referred to or even added to. It might not make sense to your users to remove the Document Set from its original context simply to apply retention.
Luckily, Collabware CLM does allow Document Sets to have retention and disposition applied to them in place. Our team zeroed in on Document Sets as one of the ideal ways of carrying out Case Management in SharePoint, and sought to fill in this gap left by SharePoint. Along with allowing Document Sets to remain in place and still have retention and disposition, we have modified Document Sets slightly for Records Management purposes. With Collabware CLM, Document Sets can be marked as Records wherever they live, preventing both deletion and updating. This update is pushed to all the documents inside the Document Set as well, aligning them under the same Retention Policy and preventing any unwanted modification. Finally, Retention is applied at the Document Set level, making it far more simple to manage Cases. Once the Document Set is closed, the final retention period can be completed. Once it is completed, the Records Management team approves disposition on the Document Set, rather than all the individual items making up the Document Set. This aligns more closely with traditional Case Management, since it is the Case being closed and destroyed, not the individual items.
Cases as Aggregates
Aggregates are a new feature in Collabware CLM 2016, a feature that our team created to address the one major flaw with all Case Management in SharePoint, the location. All the options above, while good, all have the potential to run into the same issue: Security. This issue comes up quite often when I assist organizations with rolling out Case Management in SharePoint. The basic problem is that a Case might include documents created by different user groups with different security requirements. In some cases, the organization flat-out states that certain working groups’ content cannot intermingle. This isn’t an unusual requirement, but SharePoint has extreme challenges here. This is one of the reasons that the Aggregate was created for Collabware CLM 2016.
Aggregates have their own separate existence, and can be managed as an item (like a Document Set), but with no firm location. Items are simply associated with the Aggregate, regardless of where they happen to reside in SharePoint. This allows the items to maintain their original security and allow users from separate groups to contribute to the same Case. If required, Aggregates can create Site Collections to house most of the Case documents.
Like Document Sets, Aggregates can share metadata values with associated items, as well as have Retention applied to the Aggregate, rather than its individual items. Disposition occurs at the Aggregate level, and it is even able to destroy all associated content, regardless of its location. The content associated with an Aggregate can also have a separate existence from the Aggregate, allowing it to locked down as a Record and go through its own, potentially shorter retention. An advantage over Document Sets that Aggregates have is the ability to automate associated content capture through the Collabware CLM 2016 Content Rule Engine. Documents with specific metadata can be linked to Aggregate immediately, reducing end user overhead.
Aggregates have all the features that a Document Set has, but it also has additional flexibility, making it an ideal tool for Case Management. However, I advise that organizations should only use Aggregates when Document Set limitations make them undesirable as a Case Management solution. Document Sets are simpler to set up, so for those organizations who do not have strict security requirements, they might be the faster solution.
Hopefully this overview of the different ways of doing Case Management within SharePoint highlighted some of the ways that SharePoint excels and some of the gaps it leaves, as well as how Collabware CLM fills those gaps.
Tagged: ECM, Employee Files, Lifecycle Workflow, SharePoint, Aggregates, Case Management, Records Management