Frequently Asked Questions

What types of tables will Simple Data Separation work with?

Simple Data Separation is compatible with all types of tables in ServiceNow. This includes global tables, scoped tables, and custom tables you create.

How will Simple Data Separation affect the performance of my ServiceNow instance?

Simple Data Separation is very performant relative to other methods of data segregation. In many cases, using Simple Data Separation can improve your data access speeds, due to the fact that a well-crafted query will reduce the amount of data returned from the database. For many tables, this will improve performance.

Compared to ACLs, Simple Data Separation only runs once per query, whereas ACLs run for every row returned. This generally makes Simple Data Separation much more efficient than ACLs

While Domain Separation will be efficient for most queries, it nevertheless adds an additional layer of processing onto your ServiceNow instance. For this reason, Domain Separation is a less efficient overall solution for simple data segregation when compared to Simple Data Separation.

How will Simple Data Separation affect my existing ACLs, Domain Separation and User Criteria?

Simple Data Separation is additive to any existing security and will not disable or override ACLs, Domain Separation or User Criteria that is currently in use. Many customers choose to disable other forms of data separation in favor of Simple Data Separation, but that is a separate manual process.

Does Simple Data Separation work with Database Views?

Yes! You can build Separation Rules on Database View tables just the same as you would on a normal ServiceNow table.

Can I create multiple Separation Rules for the same table?

No, Simple Data Separation will not allow multiple rules for the same table. When combining multiple Separation Rules, the results can be unpredictable. For this reason, we enforce a single rule per table.

If conflicts are detected due to Cascade rule behavior between rules on parent/child tables, a warning will be displayed guiding you to adjust Cascade exceptions appropriately to eliminate the conflict.

How do you recommend deploying Separation Rules between dev/test/production instances?

Separation Rules are captured in update sets. We recommend developing Separation Rules within an update set and using that update set to move configuration between instances, the same as typical ServiceNow development.

We do have customers who will update Separation Rules directly within their production instance. This can provide additional agility in environments where frequent changes to data segregation policies is needed, but we do not recommend this for most customers.

Can I roll back a Separation Rule to a previous version?

Yes! Separation Rules are versioned the same as most other configuration records in ServiceNow. If you need to roll back a Separation Rule to a prior version, simply use the Versions related list on the Separation Rule form to find your desired version and revert.

How do I ensure my task list view is protected?

If a child table is protected by a Separation Rule, a user may still to navigate to a list view of that table's parent and see some data from those child table records. In this case, only the data visible from the parent list view will be shown. If the user tries to click into the child record, the Separation Rule will take effect in and forbid the form view.

For example, if a Separation Rule exists on incident, but a user navigates directly to a list view of task, they will be able to see whatever fields are exposed at the task level. If they attempt to click into the incident from the list, that will trigger a query against the incident table and forbid them to see the form view.

Many organizations don't directly expose a task list view from their left nav, and most users will not navigate directly to the task list view. Furthermore, only fields stored at the task level can be exposed in this way, so all child table data remains secure. However, we recommend creating a non-cascading, highly-specific separation rule on the parent table to ensure that the data is completely secured.