Domain separation hierarchies
Summarize
Summary of Domain separation hierarchies
Domain separation hierarchies in ServiceNow enable instance owners to organize and control processes, data, and workflows across multiple domains within an instance. Defining a clear domain architecture helps track and manage data access and process execution in parent-child relationships, ensuring proper segregation and governance.
Show less
The architecture typically includes a TOP domain for processes (without users), a default domain to temporarily hold unassigned data, and various child domains representing customers or business units. The global domain represents records without any domain assigned and is accessible to all users unless restricted.
Key Features
- Parent-Child Hierarchies: Parent domains have access to child domain data and processes, facilitating structured process flows and data sharing.
- Contains Domain Relationships: Used to grant data access rights without affecting processes, allowing specific groups or individuals to access data in other domains.
- Visibility Hierarchies: Enable users in one domain to always see data from another domain, beyond parent-child relationships, but should be used sparingly to avoid unintended access.
- Default Domain: Holds data without assigned domains to prevent records from defaulting to the global domain. Instance owners must triage and reassign these records accurately.
- Restricted vs Unrestricted Domains: Domains can be divided to enforce strict access controls (Restricted) or allow broader access (Unrestricted), supporting customer-specific or shared service models.
- Domain Visibility Groups: Allow fine-grained control over data visibility across domains, particularly useful within restricted domain hierarchies.
Practical Considerations for ServiceNow Customers
- Process Isolation: Define the TOP domain for global processes and avoid placing users there to maintain clean process governance.
- Data Assignment and Cleanup: Monitor the default domain regularly to identify and reassign "lost" data to appropriate domains, preventing data leakage into the global domain.
- Hierarchy Design: Choose between parent/child, contains, or visibility hierarchies based on your organization's data access and process sharing needs, balancing ease of access with security.
- Use Cases for Domain Separation: Implement restricted domain hierarchies for customers requiring tight data segregation, and unrestricted ones where broader access is acceptable.
- Performance Impact: Be aware that "contains" relationships add database query conditions that might affect performance with large domain sets.
- Security Best Practices: Avoid moving data manually between domains during active use to prevent configuration issues and data loss.
Next Steps
ServiceNow customers should design domain hierarchies aligned with their organizational structure and security requirements, using domain separation features to segregate data and processes effectively.
Leverage domain visibility groups and containment carefully to balance user access needs and data protection. Regularly review default domain contents to ensure data integrity.
For complex requirements, consider consulting the Service Provider Reference Architecture for detailed guidance on establishing scalable and secure domain hierarchies.
Create a hierarchy when defining a domain architecture to track your processes and workflows.
Sample domain separation hierarchies
- In the following example, TOP is a process domain. It should never contain users. Rather, TOP should contain the new processes that instance owners develop and the overrides to these processes from the global domain.
- Only the service provider (SP) has access to the default domain. This domain never
contains active users. It contains only the "lost" data that you need to reassign to the
correct domain. Note:When data is not assigned to a specific domain, it moves to the default domain. It is temporarily "lost" and needs to be assigned to its correct domain.
- Tasks and users without a domain are placed in the default domain automatically when
you create or update domains. You can override that action by either clearing the
Default option on this record or selecting the
Default option on another domain record. If you have not set a
default domain yet, tasks and users with no domain move to the global domain.
- Don't move data between domains while you are using the instance.
- If any data ends up in the default domain, that means you have a configuration or procedural problem to address.
You don't see the word "Global" in this diagram because there is no global domain. Remember that "global" is the absence of a domain on a record.
For example, a table that has no domain field means that the table contains all global records. A table that has a domain field means that any record without a domain is a global domain.
The word "global" is in the domain field. It is placed there automatically when the record has no domain.
- Use the default domain to make sure that records do not end up in the global domain on tables that should never have global records.
- Instance owners must then triage the records in the default domain and move them to the correct domain.
Domain hierarchies
- Parent/child: Process and data affected
- Design that is based on a process flow.
- Remember that the parent domains can access all data in the child domains.
- "Contains" domain: Only data is affected. For example, making SP in the diagram
contain TOP does not make processes in SP run in the TOP domain and downward.
- Grants data access rights to individuals in groups that require dedicated access to certain domains.
- Contains causes or conditions to be added to database queries that can cause performance issues with large domain and data sets.
- Visibility: Hierarchy that is always visible to users once you provide access. Only
the data is affected, not the processes.
- Grants data access of a domain to another domain that did not have that access when the parent-and-child hierarchy was built.
- Enables users to see all the data in the domains that they have visibility access
for, all the time, regardless of the record they are working on. Note:Use sparingly, as Visibility can allow complete access that you may not intend.
Basic principles of defining a domain hierarchy
Unrestricted and restricted use cases for domain separation.
Many SPs have customers who implicitly state that access to their domains must be tightly regulated, which constrains the use of the “contains” function at the TOP domain. The following diagram explains how to mitigate that regulation by dividing domains into Restricted and Unrestricted domains.
Customers exist in a specific "vertical" of the domain separation hierarchy. This means they only consume processes defined in their domain and all parent domains above theirs in the hierarchy. Any processes defined in domains that are not in their linear parent-child hierarchy do not apply.
Note:Customers or "tenants" are entities that are segregated from each other completely, not like departments or business units that share resources with each other.- Super verticals (restricted, manager services, and so on) are allowed as long as the customers only ever belong to one of them.
- Services, products, or offerings that need to be horizontally available to all customers are not defined within separate domain hierarchies.
- Under TOP, you might create two domains, Unrestricted and Restricted.
- Place customers and their domains that don't have SP visibility restraints under Unrestricted.
- Place customers and their domains that do have that requirement under Restricted.
- System admins can then use “contains” and “visibility” functions in an efficient, targeted manner.
- Apply "contains" to Unrestricted, so a single “contains” can grant visibility to most customers.
- Apply domain visibility using ”domain visibility groups” to specific domains as needed.
The following diagram delineates how to choose which hierarchy model is right for you. You can choose separate hierarchies, hybrid, or shared hierarchies depending on which processes and functionality you want in your domain structures.
To learn more about hierarchy architecture, see Service provider reference architecture.