A prospect recently asked me an unusual question in regards to security; they wanted to make records visible based on a field on the Case. For the purposes of this blog, let us say it is a Classification level (Unclassified, Secret, Top Secret). Unless you were part of the right Classification group you had no visibility of the other records; The Top Secret group can see the Top Secret Cases and so on.
If this was the only criterion, this would not be a problem as we could use Business Units. We create three Business Units under the parent, put the Users in the right one and set the User security role to allow Business Unit visibility of Cases.
If this was the end of the story, it would not make for much of a blog but there was a second dimension to their security requirements; that of geography. As well as restricting the Case access by Classification, they also wanted to restrict it by geography. The people in the ‘North’ group are split into those who deal with different Classification Cases.
The quick and dirty way to deal with this requirement is to add Classification Business Units to each geographic region.
We then rinse and repeat as before, assigning Users to the right Classification Business Unit, under the region they work in.
The problem with this model is if we have staff who work across multiple regions or if we need to do reporting on all Top Secret Cases. It works for simple models, but things will get complex quickly as we generate a lot of Business Units.
An Alternative Approach
I considered a different model to try and resolve the above issues. Rather than using User ownership for the Cases, I thought about shifting to Team ownership. The client wanted the group to be responsible for the Case, not a person, so this worked fine. Even if they wanted to mark a person as a case manager, we could create another lookup, instead of the Owner field, on the Case.
Using the Team, this now becomes the intersection for security.
The regions remain defined by the Business Units and these are linked to the Team using its system lookup field. The Classifications are a custom lookup or an option set on the Team (not the Case) and the Security Role defines the access the Users get.
From an administration perspective, things are simpler as we use separate entities for the region and Classification; no frankenstructure to try and capture all permutations. Also, a User can be assigned multiple Teams which allows them to cross Classifications or Regions, as needed.
Finally, reporting is simpler as it is defined through the Team associated to the Case.
The only downside I can see is that it will generate quite a few Teams. This can be limited by only defining a Team for the lowest geographic nodes and assigning Users multiple Teams. So, for example, if our regions go down to a state level, we generate Teams for the states and assign national Users all the Teams from the states for their Classification. For our initial set of Teams we can also import them using the Import Wizard making their creation easier.
Generally speaking, I try to keep security as open as possible but, sometimes there are good business reasons to enforce it. In this case it was difficult to meet the client’s needs through ‘traditional’ User ownership. Team ownership and, specifically, the ability for multiple Teams to be assigned to a User provides flexibility which cannot be achieved with just Business Units.