One of the most frequently asked questions we received when our customers were implementing the previous version of Collabware CLM was “How do I deal with multiple working groups who share a single Record Category?” The disconnect between User Groups and Record Category is one that comes up often in ECM implementations, and dealing with that disconnect is important.
Dealing with Multiple Working Groups Who Share a Single Record Category in Collabware CLM.
The central issue for those organizations appeared when they made the decision to move the Records to the Records Center for long-term storage, but they recognized that Repositories consist of a single location that all Records related to a single Category live. For certain customers this posed a challenge, due to their stricter security requirements; essentially, users from one group should not have access to records managed by another group. Normally this is not an issue, but if both these groups are classifying the same Records to the same Category, eventually their records will end up in a shared space: the Records Repository. As you may know, Records Repositories have a set of permissions assigned, and everyone has basically the same view access.
Our initial attempt to address this was to create another type of Record Category that could live beneath a shared Category. We called it a Partition, and its purpose was to slice the Category into smaller chunks, each dedicated to a different user group. For the most part, this solution worked alright, but it wasn’t ideal.
As we developed Collabware CLM 2016, we kept this scenario in mind. In the end, we decided that Aggregates should be able to handle this situation well enough, since Aggregates could easily represent a working group, and users from that group could simply send their long-term records to the Aggregate Site.
But, as usual, we are a company that prides itself on the flexibility of our software: flexibility always leads to better ECM, because organizations have options to work with and determine what works best for their specific needs. We spent a bit of time thinking about this scenario and tried to resolve it without relying on Aggregates. After all, while Aggregates are a great feature, some users might still want to go with the basic Record Repository. This blog will outline our recommended approach to dealing with the outlined scenario when there is a need to continue to use the Records Repository.
New Features in Collabware CLM
The solution relies on two new features that were not available in previous versions of Collabware CLM: the Set Security Workflow Action, and the ability to branch a single Workflow based on different Content Rules.
The Content Type
As always, many of our solutions rely on a custom content type. Since the scenario itself implies the existence of a custom content type (how else would you determine which user group a particular Record belongs to?), we will outline what this potential content type would look like.
The most important piece of metadata we need here is the Working Group itself; this is a basic set of terms, usually created as a Choice field or sometimes a full Taxonomy Pick List.
The Workflow is able to leverage this information, so it is important to ensure that it is captured on the item.
The Set Security Action
Set Security is a fairly simple action, but it has a lot of power. When it is configured, we select whether to overwrite or revert the security, and in the case of overwriting security, what Access Control Levels to overwrite it with. In our scenario, we want a different security setting for each of our four working groups; this means we need four different Access Control Levels.
For each instance of the Set Security Action, we will apply one user group, and also add the Records Managers user group to ensure they are not accidentally locked out. In the end, we should have four different Set Security Actions on our Workflow.
.png)
Content Rules in Workflows
The idea of being able to follow different paths within a single Workflow opens up the potential for many different ways of managing content. One that is particularly useful is the Workflows ability to evaluate an item against one or more Content Rules to determine which path it should follow. Content Rules are great because they require no input from the user – they not choosing a path, the Records Manager is designing a system where the choice has already been made simply by the user populating basic metadata (or even setting it as default metadata in specific locations)!
For our scenario, the Content Rule required is very simple; we just need to separate items based on which User Group they have assigned.
Once we build out Content Rules for every different potential Working Group, we’re pretty much done.
All of these different Actions can once again lead back into a single path, or they can continue as separate paths, it’s really up to the organization.
What This Can Do
The purpose of this little Workflow trick is to separate content based on Working Group and lock it down to just that group of users. In this way, we have resolved the original issue of having multiple groups submitting the same Records and potentially working in the same Records Repository.
It also skirts around the ever-present concern of unique SharePoint Permissions in any given location, which is around 50,000 unique permissions. Because we are only applying 4 different permissions, and we are applying it in an automated way, there is no risk of running into that threshold.
Without having to configure anything out of the ordinary, an organization can maintain their Records Center primacy. Users can search and browse within the Records Center without any risk of them seeing items they should not be able to see.
This is a huge thing for ECM projects that are struggling with that crucial disconnect between the users and the record categories, and should lead to a more consistent and reliable approach to managing Records in the Records Center.
