Before Query business rules
-
- UpdatedAug 1, 2024
- 3 minutes to read
- Xanadu
- Now Platform Administration
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.
A Before Query business rule is supplementary code that you use to support data segregation within domain-separated environments.
Using the Before Query business rule for data segregation
- When domain separation is not supported by a ServiceNow
application and you must grant or restrict table or row access to one or more
non-internal customers outside of the service provider organization.Note: Before you begin developing, contact ServiceNow Customer Support about the application roadmap for that product; domain support improvements may be planned for upcoming releases.
- When a table is domain-separated but access to its rows must be granted or restricted
based on certain conditions that apply only to a set of domains in the system.Note: For example, a customer in the X domain has multiple vendors supporting that domain and those vendors are granted access to see only the records that are assigned to them.
Points to consider before creating Before Query business rules
- Where you can, create Before Query business rules at the lowest possible part of the domain hierarchy so that the rule runs only for users that it applies to.
- Know that there are scenarios in the system where business rules may not run or where a user-triggered interaction may not trigger a business rule to run. For example, a business rule won't run when you have transform maps with Run business rules turned off, or you have scripts with the workflow disabled.
- Always populate the condition field to specify when the rule runs. For example, you
can specify if the business rule applies only to certain vendors in a domain. Warning: When designing and coding business rules (especially Query business rules), limit OR clauses and searches in non-indexed fields. Too many OR clauses and searches in non-indexed fields can slow queries or affect how your instance performs.
Use Before Query business rules only when necessary. Too many Before Query rules can affect how your instance performs.
Data Security restricts…. when interacting with
data.When not to use Before Query business rules and ACLs
Be careful when you use Before Query business rules and ACLs to segregate customer data. By using both business rules and ACLs, you create customizations that you then must maintain. Customizations can potentially cause performance issues. Your development teams should create processes to make sure that they don’t break the system.
Domain separation provides both scalability and governance with the current domain path query method (v3), which is a widely supported framework. The ServiceNow Platform and App teams are responsible for maintaining the framework, taking the burden off the customer.
For companies with many customers in many instances, excessive use of Before queries and ACLs may cause the database queries not to perform well.
How domain separation is enabled
You can enable domain separation with a ServiceNow plugin. A product manager, supported by a development team, manages the functionality. Enhancements and fixes for domain separation functionality are included with ServiceNow releases. Instance owners can consult Customer Service and Support resources, such as the Service Portal, at https://support.servicenow.com for assistance with 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.
- Segregating and securing data with domain separation
You can segregate and secure data on the ServiceNow platform in multiple ways, depending on your customer's needs.
- 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.
- 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.