Separation Rules

Separation Rules are the heart of Simple Data Separation - they define how data will be segregated for a given table, ensuring that data is only exposed to its appropriate audience. You can create a Separation Rule for any table in your ServiceNow instance, including global, custom, and scoped tables.

The Separation Rule form is organized into tabs to simplify configuration:

• Rule Details: Basic configuration & criteria of the Separation Rule

• Rule Overrides: Overrides to provide data visibility even if a user doesn't meet the basic requirements of the Separation Rule

• Caching: Optional caching configuration to speed up data access for complex rules

• Query Details: Details of the generated query, including the ability to customize query code

Rule Details

Rule Overrides

Caching

Query Details

Rule Details

• Table: The table on which you wish to segregate data

• Separator fields: The field(s) around which data segregation will occur. Users will only be granted access if they are a member of the group/department/company/location/etc that is specified on the target record, or unless a Rule Override applies to them (see below).

• Selectively apply: Select whether the rule applies to all groups/departments/etc, or only to the selected groups/departments/etc

• Apply to non-interactive sessions: By default, Simple Data Separation only applies to interactive user sessions. This ensures that background processes and web services maintain full access. Selecting this option will enable data separation for all types of access.

• Cascade rule: Determines whether this rule will also apply to child tables of the Separation Rule table. Note that you can select exceptions to this setting in the Cascade exceptions field. Named tables (comma-separated) will behave opposite of whatever the selected Cascade rule behavior is.

• Hide child tables: When selected, tables that extend the Separation Rule table will not be visible when a user views a list, a reference field, or otherwise accesses the Separation Rule table. This can be useful to secure visibility of child table records. For example, hiding sensitive task-based records that might otherwise be visible if a user navigates directly to a task table list. Note that you can select exceptions to this setting in the Hide child tables exceptions field. Named tables (comma-separated) will behave opposite of whatever the selected Hide child tables behavior is.

  • When using Hide child tables options, the selection of Separator fields becomes non-mandatory. This makes it possible to hide extended tables for security without performing data segregation on the Separation Rule table.

Having multiple Separation Rules active on the same table can result in conflicting query parameters and unpredictable results.

Simple Data Separation will alert you if you attempt to create multiple rules on the same table or if you create rules where a Cascade rule or Hide child tables setting may cause a conflict. In these cases, the app will ask you to configure your Separation Rule accordingly to avoid conflicts.

Rule Overrides

• Admin overrides: Select this to exempt users with the admin role from the Separation Rule

• Approver overrides: Allow a user who is an approver for a task to view that task, even if they don't meet the basic requirements of the Separation Rule

• Owner overrides: Fields on the target record that indicate the user is the owner of that record and should be able to view it, even if they don't meet the basic requirements of the Separation Rule. A good example is that the 'Caller' on an Incident should be able to view and interact with that Incident at all times, regardless of data separation.

• Visibility groups: Groups that are exempt from the Separation Rule. A good example is a group responsible for management or auditing of the records in question.

Access Requests

• Simple Access Requests enable ad-hoc, time-bound access to secured records for individual users. See more @ Simple Access Requests.

Caching

• Enable query cache: When enabled, Simple Data Separation caches the results of the Query script, resulting in faster results on subsequent access attempts

• Cache expiration: The amount of time that a cached query is considered valid. After this duration, the Query script will be recalculated to ensure validity of returned results.

Most customers do not need Caching. Only when the Query script performs many queries or complex calculations should this be used. Caching can affect the 'real-time' nature of query results in active environments - this should be considered when enabling caching and selecting a Cache expiration duration.

Caching for a specific user & table is disabled when they have active Simple Access Requests for that table. This is to ensure that the time constraints of the Simple Access Request are honored.

Query Details

• Customize query: Selecting this option will turn off auto-generation of the Query script and Condition, allowing you to inject your own script. This can be useful when building Separation Rules for complicated data structures where you may need to query against other tables in order to gather data needed for data separation.

• Query: Auto-generated (or customized) script to enact data separation

• Condition: Auto-generated (or customized) conditions under which the Query script is applied

We recommend avoiding Query customization until absolutely necessary. Prior to customization, do as much as you can with our point-and-click configuration to ensure an optimal query script.

To help avoid customization, check our Quickstart Packs to see if we've pre-built a set of Separation Rules to expedite your deployment!