Specializing in Support and Service Software

The roles and permissions functionality of Dovetail Support Center allows an administrator to control which users could view and edit cases. However, in our initial release, there was no way to limit which cases a user could view - it was all or nothing. A customer requested the ability to designate some cases as sensitive and limit the population of users that are able to view those cases. I'm going to show how we were able to take advantage of our existing infrastructure to quickly and easily respond to a feature request.

Identify sensitive cases

The first step was being able to designate which cases contain sensitive information. We added a new IsSensitive property for Case objects that can be set to true or false. A user can set this property when creating the case, or modifying an existing case.

As an extra precaution, an administrator can also create a rule that will automatically mark cases as sensitive if they meet some criteria. For example, we can use the Rule Editor  to make sure that any case created with the word 'paycheck' in its title is marked as sensitive:

Restrict access to sensitive cases

Now that we know which cases should be treated as sensitive, we need to limit which users can view them. We can do this through a combination of permissions and data restrictions.

The application now includes a new right in the permissions editor called "View Sensitive Cases". An administrator can specify that this permission is Not Granted to the general user population by editing permission for the Agent/User role:

The administrator would then make sure this permission is Granted to a more exclusive role (for example "Compensation Specialist") which can be assigned to a specific set of users.

The final step is to pull it all together and make sure users without the "View Sensitive Cases permission" do not see cases that have their IsSensitive property set to true. We need to create a data restriction on Case. Data restrictions are filters applied to all queries to the system for a given object type (for us, the Case object type). They are defined via a .NET Framework class that implements the IDataRestriction<T> interface (although we are considering a Rules Editor-like interface that would allow administrators to define restrictions without writing code). We created the SensitiveCaseDataRestriction:

The power of data restrictions is that they allow developers (at Dovetail, or even customers) to inject their filtering logic that gets applied universally throughout the application, with very little code. For more technical details about how data restrictions work, see my post about systemically applying filters to data access.

See it in action

To demonstrate, I'll log in as Annie Agent, a member of the "Compensation Specialist" role that has access to sensitive cases. When I query for cases in the Triage queue, I see all three:

However, When I log in as Hank Agent, a regular user, and do the same query, the sensitive case is not there:

If I were to perform a full text search as Hank, or look at the recent cases for a contact, or any other place where a list of cases shows up, I would never see that sensitive case.

Summary

I showed how we added the ability to restrict access to cases containing sensitive information to an exclusive set of users. We thought it was a generally useful feature, so we added it to the product. However, even if we hadn't, the flexibility of our platform allows a customer to perform each of these steps (add a property to case, a new permission, and a custom data restriction) to implement the feature as as a customization, with relatively little effort (keep an eye out for a future post).