Segregating and securing data with domain separation
-
- UpdatedAug 1, 2024
- 2 minutes to read
- Xanadu
- Now Platform Administration
You can segregate and secure data on the ServiceNow platform in multiple ways, depending on your customer's needs.
Segregating data in multiple ways
The following diagram shows four ways that you can segregate data. You can use separate instances, domain separation, contextual security and business rules, and the reference architecture itself as ways to segregate data.
- Customizing the reference architecture with qualifiers and filters so that departments and groups within a company can focus on their own work. By segregating the data between these departments or groups, a department or group can't see another department or group's records.
- Adding contextual security and Before Query business rules as additional layers of security to guard against data breaches. See Context and domain separation and Before Query business rules to learn more about domain separation and business rules.
- Adding another level of security in a company by using domain separation. The data from every database query is limited to the data that is visible in a domain before contextual security and business rules are executed.
- Using separate instances to segregate the data at the database and application layer.
Separate instances, domain separation, contextual security and business rules, and the reference architecture are ways to segregate data. These four ways relate to each other as indicated by the Comprehensiveness of need arrow in the diagram. How each layer interacts with the other layers depends on how you set up your domain separation configuration.
Not all organizations require domain separation. You might find other alternatives, such as separate instances or a single instance without a domain. To learn more about these alternatives, see Evaluating the need for domain separation.
On this page
Related Content
- Domain separation explained
With domain separation, you can segregate application data, UI, and business logic, such as rules or workflows, in a single customer instance. Separating these elements into logically defined domains supports specific hierarchies for all customers using your applications.
- Domain separation hierarchies
Create a hierarchy when defining a domain architecture to track your processes and workflows.
- Context and domain separation
The context of a user's session determines the processes, data, and user interface (UI) as the user browses through list views, home pages, reports, and knowledge articles. The context is determined by the processes that you create, the business rules that you set, your workflows, and other factors.
- Alternatives to domain separation
You can use a separate instance as an alternative to domain separation for your customers. A separate instance allows you the flexibility to meet the requirements for data separation within the groups and departments in an organization with little to no impact on others.
- Evaluating the need for domain separation
You may find that domain separation doesn't always work for your customers' organizations. It's best that you base your decision to go with domain separation by looking at your customers' needs.
- Benefits of domain separation
Domain separation may work better for your customers' organizations than any other method for separating the data between groups and departments.
- How a database query works with domain separation
Using database queries with domain separation in your customers' applications help them protect their data. These queries then speed up the configuration and build processes.
- Domain separation levels of support
Choose from three categories for domain separation of an application for your customers' organizations.
- Service provider reference architecture
Your customers can access service provider (SP) services by using a portal that is designed for them to reach their domain-separated instance.
- Domain separation terms
With a ServiceNow instance, you can improve efficiency, add greater security, and increase performance for your customer organizations. It's helpful to understand some of the most common terms as you create your configurations.
- Domain-separate a custom table
You may need to create custom tables in separate domains. This topic covers both the procedure and the concept behind domain-separating a custom table.
- Customizing domain properties and themes
You can customize your customers' company properties and themes within the domains that you have configured. Customization makes their instances fit in with their companies' overall look and feel.
- Managing domain separation for specific uses
You can set up separate domains for email notifications and customize the properties of catalog, tables, users, groups, and views. This enables you to provide more specific behavior in each domain, giving your customers more flexibility.
- Configuring domain separation with the domain picker
Use the domain picker wisely, and remember the 80/15/5 approach so that you do not customize too much and impact the performance of your instance.
- Domain separation performance considerations
As you configure domain separation in your application and services, make sure that you consider the number and properties of domains you create. Too many property-heavy domains can impact the performance of your instance.
- Setting up domain hierarchies
You can avoid slowdowns and performance impacts in your instance by knowing how domain hierarchies work and by setting them up properly.
- Checking domain logs for errors and warnings
Check the domain logs to find errors or warnings in your domain path processes and hierarchy configurations.
- Importance of the Default domain
Organizing your domains is a crucial part of the domain separation process. If you don't set a default domain, new tasks and user records go to the global domain. Anyone can see the records in the global domain, which means that data can be seen when it is not supposed to.
- Contains queries and domain access
Use a "contains" query only in special cases, such as when users or groups need to see data from a domain that they don't have access to, but you don't want to move those users to a domain. Creating domain "contains" and user or group access for a domain should be an exception, only when absolutely needed.
- Domain paths query method
You can create effective queries with domain paths.
- Slow queries and SQL debugging
Debugging SQL and slow queries can help you resolve slowness issues in an instance.
- Before Query business rules
You can use a Before Query business rule to help support data segregation on an instance. ServiceNow applications that support domain separation may support the separation of data and data routing only, have advanced business logic separation, or support tenant (customer) level administration of the application.
- Avoiding domain path in scripts
Domain paths can cause the values of your script to change or even break, so don't use them in scripts.
- Domain assignments
How you assign a domain impacts the value of the sys_domain field. The assignments contain designs and business properties that affect how the application functions in each domain.
- Domain separation and the Customer Service Management (CSM) plugin
For the best outcome, be aware of how the properties in the CSM plugin work. When the plugin is enabled, you can see the status of your records in your domains.