Query rules in Customer Service Management (CSM) is a feature that controls ‘Read’ access to CSM cases based on Roles and conditions defined in the query rule tables. There isn’t much detailed documentation available about this feature and is often overlooked hence I decided to write this blog to understand this in a little more detail
Background
Normally to control read access for your case record you would do it by evaluating ACLs or query business rules by writing your own scripts and logic. This becomes cumbersome, especially in the case of CSM where the configuration provided by the product Out of the box is very difficult to unpack with several ACLs running on the table adding one more with your own logic would just add to the complexity. Don’t forget you may have different case types too
How it works
To solve this issue the product comes with an application called ‘Query Rules’ where you can go and define the conditions to access the records for your CSM Case table
By default it allows you to select any table, however, it is only honored for CSM application only since the ‘read’ ACLs in sn_customerservice_case evaluates them before granting access
If you notice the read ACL’s on the case tables, they first check the system property ‘sn_cs_queryrules.use_query_rules’ is set to ‘true’. This basically defines whether to use query rules to evaluate read access for the record (default value is true for new instances post-London release)
Once it passes through this, it moves on to evaluate the filter conditions defined for your role and record type being accessed on the ‘sn_query_rule’ table.
It then checks the current record against the filter conditions defined in the query rules table to confirm if they are a match and subsequently grants the access to the case
Note: if there are >1 query rules for the same table & role but with different conditions, both will be evaluated and if anyone passes to be true the access would be granted to the record
Where would this be useful?
The application itself is being used in the current Out of the box version of the product. However, it can be expanded to use cases such as those below
- Where you need to provide read access for more explicit scenarios such as Account = X, Created Date > YY, etc.
- Where you need to provide access based on the case type, asset type, entitlement based, etc.
- Where you need to manage access between different teams of the same department in terms of what they should see
The application provides a simple interface to define your conditions, all at one place. Hence it’s always recommended to use it for RBAC (Role-based access control) in cases
Note: The script-include being referred to in the screenshot above is hidden by SN at the time of writing this blog
Please do keep posting your comment to improve this article based on your experience of using this feature
