Segregating your data using Data Restriction
The Dovetail SDK (fcSDK) includes Data Restriction Technology.Data Restriction allows you to segregate your Clarify/Dovetail database so that different sets of users can use the same forms (and customizations), yet see different sets of data from the database. This can include any items such as cases, sites, contacts, parts, etc.
For example, suppose you have two different groups that support different product lines. You might set up Data Restriction so that the users in group 1 can only see group 1’s sites, contacts, solutions, cases, and parts. Likewise, group 2 would only see their data. The user’s do not even know that they are not seeing all of the data from the database.
Data Restriction based on Geography
A common data restriction setup is to segregate data via geography. For example, users in Europe may only see data (cases, contacts, sites, etc.) for those customers that are in Europe. Users in North America may see data for customers in the US and Canada. Additional levels can go even deeper – such as Eastern US, Central US, and Western US.
Data Restriction in the Dovetail SDK
Using a simple scheme change, you can put restrictions on any database table or view.
Every time a user performs a query or an update using the SDK, the SDK determines if that table or view is restricted, and automatically modifies the SQL for you. This has one very profound consequence: No form customization is required to use restrictions.
Basically, if you enter restrictions (once) in the database, every time you use the SDK, you will automatically have data restriction working for you. This makes it simple, and easy to use.
Data Restriction Architecture
A restriction set is defined as a set of up to five levels of restriction for an object. The objects with restriction sets are commonly the following:
- employee
- site
- queue
- part number
- script
- action item (task)
- lead
- opportunity
- dialogue
- literature request
- solution
However, you can restrict any objects you want, in any way that you want. It should be noted that many objects in Clarify (such as case and contact), can be best restricted by using a common object (site in this situation).
An administrator starts by creating a set of restrictions that will be given to the users. There can be as many restriction groups as desired, or only a few. It is solely dependent on how each administrator wishes to partition their data as to how restriction groups are set up. Setting up restriction groups well is the key to this product!
Most employees/users will be placed in just one restriction group. That is, the data they should be able to view and modify. But there are times (for examples, managers) where an employee may need to spend time working on different sets of data. In this case, they can be added to multiple restriction groups. But even when a user is placed in multiple groups, only one of those groups can be active at a time. The user can only view/modify data for one restriction group, and if they want to modify/view data from a different group, they have to switch the group they are in.
As mentioned before, Data Restriction works “under the covers.” So, a user who creates a new site will automatically give that site their current restrictions just as a part of creating that site. After that, the site will only be visible to people who have restrictions to see the site.
What about cases and contacts?
A case (and a contact) are both related to a site. So by restricting the site, that same restriction will be used when querying for cases and contacts.
While only a small number of objects are restricted (see above), all of the objects in the system are essentially restricted – using the base restricted objects. For example, contacts are restricted based on the site(s) at which they are located. So even though the product does not place restriction fields on the contact (or case) objects directly, the end-user will still see those as a restricted object.
Tagging
Tagging of data is common in many contemporary applications. Essentially, Data Restriction works a lot like tagging. Entities in the database (such as a site) are tagged, or marked with data that indicates which restriction group they belong to. This tagging happens automatically within the SDK. In addition, the SDK automatically filters data retrieved from the database based on the tag (or tag set) of the current user.
A Data Restriction Example
Suppose you have two customer service representatives in your company; Jane, who takes care of customers for Joe’s Clam Shack (JCS) and Betty, who takes care of customers for company Bubba’s Bait Shop (BBS).
Now suppose that in your database, you want sites s1, s2, and s3 as customer sites for JCS , and sites s4, s5, and s6 as customer sites for BBS.
The administrator can set the first level restriction of Jane to be JCS, and the first level restriction of Betty to be BBS. When Jane creates new sites s1, s2, s3, their level 1 restrictions will automatically be set to JCS (because a site gets the same restriction set as its creator). Likewise for sites s4, s5, s6 for Betty and BBS.
Now when Jane presses the Find Caller button on the new case screen, she will only see contacts for sites s1, s2, and s3. If Betty performs the same operation, she will only see contacts from sites s4, s5, and s6.
Now you may have a manager (Marcus) who wants to be able to switch back and forth, and see data from either Jane’s or Betty’s customers from time to time. The system administration can set up Marcus’ account so that he (Marcus) has two restriction sets (one set has level 1 = JCS and the other set has level 1 = BBS) and can switch back and forth between them. Only one set will be active at any time.
It is also possible to break down the restriction sets into finer distinctions by using levels two and three of the restriction sets. Say you have another employee (Edward) who only deals with people from Joe’s Clam Shack in the eastern region. His restriction set would look like level 1 = JCS, level 2 = East. You may have yet another employee, Wendy, who deals with Joe’s Clam Shack western region. Her restriction set would be level 1 = JCS, level 2 = West. There might be a site s7 with restriction set JSC/East. Edward has access to that site but no others. Jane also would have access to site7 because she has access to any objects whose level 1 restriction is JCS.
Administration Support
The administration of Data Restriction is completed by the Dovetail Admin web application. An admin can setup data restriction groups, assign users to groups, define which entities are restricted, etc.
There is also programmatic access to Data Restriction via the APIs within the SDK. If a user belongs to multiple restriction groups, you can use the FCSession method ChangeResGroup to programmatically change the current restriction group for that user.
Restricting Your Database
The mechanism for modifying your restrictions is to setup the restriction tables provided with this product. A sample restriction file is provided with Dovetail Agent which makes this easy.
There are two fundamental operations that the SDK must perform for restriction to work. The first is that when new rows are added to restricted tables, the SDK must automatically add restrictions to that new row. For example, if the site table is restricted, you want the SDK to add the current user’s restriction to each new site row added to the database.
In the lexicon of tagging, these new entities are automatically tagged with the restriction group of the current user.
The other operation that the SDK restriction-enables is querying. For each table or view (you often will data-restrict your views), you will enter one or more rows to the “res_sql_clause” table. Again, a sample file is provided with Dovetail Agent. Each row in this table refers to one “where” clause that will be added to the SQL statement every time you query that table or view. Each of these clauses will be “AND-ed” to the SQL before it is executed.
Data Restriction within an Application
As I mentioned earlier – Data restriction works at the SDK level – so your applications do not have to change to support it – and its essentially invisible to the end users. Lets see what happens using the same exact form (web page) from the same application (Dovetail Agent), but simply logging on as different users.
Logging into Dovetail Agent as a user in the EMEA restriction group, that user will only see the 2 contacts that are tagged as EMEA:
Logging into Dovetail Agent as a user in the North America restriction group, that user will only see the 3 contacts that are tagged as North America:
Logging into Dovetail Agent as a user with no restrictions, that user will see all 45 contacts in the database:
Considerations
I always recommend that organizations carefully consider whether Data Restriction is the right tool for the job. The Data Restriction functionality is powerful, but it does take some careful setup. And it can be a bit confusing to wrap your head around all of the data setup involved. At times, a simple customization to the application itself is all that is needed – as opposed to the full Data Restriction functionality. But when this type of functionality is required – it can be a very powerful tool in your arsenal.
