Questions for the CIS-SP were updated on : Dec 01 ,2025
Given a parent and child domain, explain data accessibility between domains.
BD
Explanation:
In ServiceNow’s domain separation model, data accessibility is designed to maintain the integrity
and segregation of data across different domains. Here’s how data accessibility works between
parent and child domains:
•
The parent users can access all child data: Users in a parent domain have visibility into the
data of their child domains. This is because the parent domain is considered to have a higher level of
data access privilege, allowing it to oversee and manage the data within its child domains1.
•
The parent users can access all child data, but cannot access domains contained in the child
domain: While parent domain users can access data in their immediate child domains, they cannot
access data in “grandchild” domains or any domains that are further nested within a child domain.
This maintains a level of data isolation and ensures that users only have access to the data they are
permitted to view and manage1.
The options stating that both parent and child users can access each other’s data (A) and that child
users can access all parent data © are incorrect. The domain separation model is hierarchical, not
reciprocal, meaning that child domains do not have inherent access to parent domain data, and
access between domains is not automatically bidirectional1.
For detailed information on domain separation and data accessibility, ServiceNow provides extensive
documentation and best practices, which can be referenced for a deeper understanding of these
concepts12
On a new standalone table, what domain will a new record be created in by default?
B
Explanation:
In ServiceNow, when a new record is created on a standalone table, the domain of the new record is
set to the user’s current session domain by default. This means that the domain context in which the
user is operating at the time of record creation determines the domain assignment for that record.
This behavior ensures that the data is correctly categorized within the domain structure, adhering to
the visibility and access controls that have been established.
The concept of domain separation in ServiceNow is integral to its multi-tenancy model, allowing for
data, processes, and administrative tasks to be segregated across different domains within a single
instance. This is particularly useful for managed service providers (MSPs) who need to maintain
distinct operational environments for multiple customers or departments within the same
ServiceNow instance.
For a new standalone table, unless explicitly defined otherwise, the system defaults to using the
user’s current session domain for new records. This is supported by ServiceNow’s documentation on
domain separation best practices and the management of data within domains12. It’s important to
note that while the default behavior is as described, administrators have the ability to configure
domain rules and behaviors to suit specific organizational needs.
What is the first step an admin must perform before using domain-separation for Service Catalog
items?
D
Explanation:
Before using domain separation for Service Catalog items, the first step an administrator must
perform is to activate the Service Catalog - Domain Separation plugin
(com.glideapp.servicecatalog.domain_separation). This plugin enables domain separation within the
Service Catalog, allowing for the separation of data, processes, and administrative tasks into logical
groupings called domains1. By activating this plugin, the admin ensures that the Service Catalog is
prepared to handle the complexities of a domain-separated environment, which is essential for
maintaining data integrity and proper access controls across different domains21.
If a business rule exists in the parent domain and a separate non-overriding business rule exists in
the child domain, which rule will run for the child domain?
B
Explanation:
In ServiceNow, domain separation allows for the partitioning of data, processes, and administrative
tasks into distinct domains within the same instance. When it comes to business rules, if a business
rule exists in the parent domain and another non-overriding business rule exists in the child domain,
both rules will be executed for the child domain1.
This behavior is part of the domain hierarchy logic, where the child domain inherits the properties
and rules of its parent unless explicitly overridden. Since the business rule in the child domain is non-
overriding, it does not cancel or replace the parent domain’s rule. Instead, it adds to the logic that
will be processed when the conditions for the business rule are met.
Therefore, when an action occurs that triggers the business rules, the system will first run the
business rule from the parent domain followed by the business rule from the child domain. This
ensures that the foundational logic set by the parent domain is always applied, while still allowing for
additional, domain-specific customizations in the child domains2.
It’s important to note that this behavior can be controlled and configured according to the needs of
the organization, and understanding the implications of domain inheritance is crucial for proper
domain separation management in ServiceNow3.
Which are the available Domain Types on a baseline instance?
Choose 3 answers
BCD
Explanation:
In a baseline ServiceNow instance, the available domain types include Primary, TOP, and Customer.
These domain types are part of the domain hierarchy that ServiceNow uses to organize data,
processes, and administrative tasks within the platform.
•
Primary: This is the main domain where the instance is initially set up. It’s the starting point
for the domain hierarchy and typically contains the core configurations and settings for the instance.
•
TOP: The TOP domain is the highest level in the domain hierarchy, above all other domains. It
is used for defining global processes and settings that can be inherited by lower-level domains.
•
Customer: Customer domains are created to represent individual customers or tenants in a
multi-tenancy environment. Each customer domain can have its own unique configurations,
processes, and data that are separate from other domains.
The concept of MSP (Managed Service Provider) and Vendor domains are not standard domain types
in a baseline instance but can be configured as part of a domain separation strategy to cater to
specific business needs. The ServiceNow documentation provides detailed information on domain
separation, including the types of domains and how they are used within the platform. Domain
separation allows organizations to maintain data privacy and process customization across different
business entities within a single instance of ServiceNow.
In a new domain separated instance, which data will a user in customer Domain X definitely have
visibility to?
Choose 2 answers
CE
Explanation:
In ServiceNow, domain separation is used to segregate data, processes, and administrative tasks into
logical groupings called domains. This allows for control over data visibility and operations within an
instance. When it comes to data visibility:
•
Domain X: A user in Domain X will definitely have visibility to their own domain, as this is the
primary context in which they operate1.
•
Child domains of Domain X: Users can view data in their home domain (Domain X) and any
child domains of that home domain. This is because child domains inherit permissions and visibility
from their parent domains, allowing users in a parent domain to see data in the child domains1.
However, users do not have access to data present in their parent domains or other unrelated
domains by default. The primary domain and default domain are typically reserved for global or top-
level administrative purposes and are not automatically visible to users in customer domains unless
specific permissions are granted12.
It’s important to configure domain separation carefully to ensure that users have the appropriate
level of access to data necessary for their roles while maintaining the security and integrity of the
data across the instance31.
Given TOP as a parent domain for MSP, ACME, and Initech, and MSP contains TOP What additional
domain configuration is required for UserA in MSP to read records in ACME?
C
Explanation:
In ServiceNow, domain separation is used to manage data visibility and access control in a multi-
tenant environment1. The ‘contains’ relationship in domain separation defines a hierarchy where a
parent domain contains child domains, and by default, users in a parent domain can see the records
in child domains1.
Given that TOP is the parent domain for MSP, ACME, and Initech, and MSP contains TOP, UserA in
MSP would already have visibility into TOP. However, for UserA to read records in ACME, additional
configuration is required because ACME is not a child domain of MSP by default.
The correct action is to add visibility to ACME for UserA ©. This is typically done by configuring the
user’s domain membership or by adjusting the domain visibility settings to include ACME for UserA.
This ensures that UserA can access records in ACME while still being primarily associated with the
MSP domain1.
The ‘contains’ relationship between MSP and ACME (A) is not necessary because it would imply a
hierarchical relationship that does not reflect the given structure. Adding both visibility to ACME for
UserA and contains between MSP and ACME (B) is also not required and could potentially create an
incorrect domain hierarchy. No additional configurations (D) would not suffice as it would not grant
UserA the access needed to read records in ACME.
Which are required to retrieve and commit an update set?
Choose 2 answers
CD
Explanation:
To retrieve and commit an update set in ServiceNow, certain prerequisites must be met to ensure
proper management and deployment of changes across instances:
•
You must have the admin role ©: Having the admin role is crucial because it provides the
necessary permissions to manage update sets, which includes retrieving and committing them. This
role ensures that only authorized users can make significant changes to the system12.
•
The domain picker must be set to global (D): When working with domain-separated
instances, the domain picker must be set to global to ensure that the update set is applied across all
domains. This is important for maintaining consistency and avoiding conflicts between different
domains within the instance2.
What domain must administrators choose to apply an Updates Set?
A
Explanation:
In ServiceNow, when applying an Update Set, administrators must select the Global domain. This is
because Update Sets are designed to be applied from the Global domain to ensure that the changes
are captured and can be moved across the instance without being restricted by domain separation1.
The Global domain is the default domain where all the configuration records are created and where
administrators typically work unless they switch to another domain for specific tasks1.
The Update Set system in ServiceNow is a mechanism for grouping and moving customizations from
one instance to another or within the same instance. It captures the configuration changes made by
administrators and bundles them into a set that can be transferred and applied elsewhere. Since the
Global domain is the highest level in the domain hierarchy and is not restricted by domain-specific
rules, it is the appropriate choice for applying Update Sets to ensure that the changes are universally
available across all domains within the instance
What's a good globally unique candidate field that could be used to populate UserID?
BCD
Explanation:
When selecting a field to populate UserID in ServiceNow, it’s crucial to choose an identifier that is
globally unique to ensure that each user can be distinctly identified. The best practices for such
identifiers include:
•
Employee Number: Typically, an employee number is unique to an individual within an
organization and does not change, making it a reliable identifier1.
•
Email: An email address is inherently unique as it is tied to an individual and is used for
communication, which also makes it a suitable candidate for UserID2.
•
SSN (Social Security Number): While SSN is unique to each individual, it’s important to note
that using SSN as an identifier should be approached with caution due to privacy and security
concerns. However, it is unique and could technically be used to populate UserID3.
The Last Name is not a good candidate for UserID because it is not globally unique; many individuals
can share the same last name and it can change over time due to personal reasons.
For further details on creating unique identifiers and best practices, ServiceNow provides
documentation and guidelines which can be referred to for implementing these practices within the
ServiceNow environment.
What is the best practice regarding User Criteria and Shared Knowledge Bases?
C
Explanation:
In ServiceNow, the best practice for setting up User Criteria and Shared Knowledge Bases is to define
them in the parent domain. This approach ensures that the knowledge bases are accessible to all
relevant child domains, promoting efficient information sharing and management. When knowledge
bases and user criteria are defined at the parent domain level, they inherit down to the child
domains, allowing for centralized control while still supporting visibility across the domain hierarchy.
This practice aligns with the principles of domain separation, which is a key feature in ServiceNow for
managing data and user access in a multi-tenant environment. By defining these elements in the
parent domain, organizations can maintain a clear and organized structure that supports both
separation and sharing of knowledge as needed.
For more detailed guidance on this topic, ServiceNow’s official documentation provides insights on
designing user criteria for knowledge bases, which can be found in their support portal. It is
recommended to review these resources for a comprehensive understanding of the best practices in
configuring user criteria and knowledge bases within ServiceNow.
A System Administrator wants to setup their domain hierarchy in a new instance, which practice
should they follow when creating the structure?
A
Explanation:
Best practices for setting up a domain hierarchy in ServiceNow recommend creating a structure that
is not too shallow or too deep. A hierarchy that is 3-5 layers deep is considered optimal as it allows
for the use of ‘contains’ relationships where necessary12. This structure should include a default
domain, which typically serves as the catch-all layer for any data that does not belong to a more
specific domain3. The default domain is often the TOP domain or a domain just below it. This setup
facilitates better organization and management of data and processes across different domains
within the instance45.
What happens when the glide.knowman.allow_edit_global_articles system property is enabled ?
A
Explanation:
The glide.knowman.allow_edit_global_articles system property in ServiceNow, when enabled,
allows users in the global domain to check out and edit global knowledge articles. This property is
particularly useful in scenarios where an organization wants to centralize the editing of knowledge
articles to users who are part of the global domain, typically administrators or designated knowledge
managers.
This setting ensures that while users from other domains can view and utilize the global knowledge
articles, the editing rights are reserved for global domain users to maintain consistency and control
over the content. It’s important to note that this property does not extend editing privileges to users
from non-global domains or to all users with a knowledge admin role; it specifically targets users
within the global domain.
The configuration of this property is a part of the knowledge management best practices in
ServiceNow, as it helps in maintaining the quality and integrity of knowledge articles by restricting
edit access to a controlled group of users. This approach aligns with the overall strategy of domain
separation, where the goal is to separate and protect the data and operations of different business
units or domains within the same ServiceNow instance1.
A Service Provider Incident Manager wants to create a 'Plan Definition’ for Task Communication
Management for a specific customer domain when a major incident is accepted on-behalf of that
specific domain. In what domain should they create the definition?
D
Explanation:
In ServiceNow, when a Service Provider Incident Manager is tasked with creating a ‘Plan Definition’
for Task Communication Management specifically for a major incident in a customer domain, the
plan should be created within that customer domain. This ensures that the communication plan is
tailored to the customer’s environment and is triggered only when conditions within that domain are
met.
The ServiceNow documentation provides guidance on setting up communication plans. It states that
a communication plan should be defined for a task record to specify communication tasks and
contact definitions. When the conditions for the plan definition are met, the communication plan
and its associated records are automatically attached to the task record, which in this case would be
the major incident accepted on behalf of the customer domain1.
Creating the plan definition within the customer domain ensures that the communication tasks and
contacts are relevant and specific to the customer’s needs, which is essential for effective
communication management during major incidents. This approach aligns with ServiceNow’s best
practices for domain separation, where customer-specific configurations are maintained within their
respective domains to avoid interference with global settings and other customer domains.
If a business rule exists in the parent domain and is overridden in the child domain, which rule will
run for the parent domain?
C
Explanation:
In ServiceNow, the concept of domain separation allows for data and administrative segregation
between different domains within an instance. When a business rule is defined in a parent domain, it
applies to that domain and all child domains unless specifically overridden in a child domain1.
If a business rule is overridden in a child domain, the original rule in the parent domain continues to
apply only to the parent domain and any other child domains that have not overridden the rule. The
overridden rule in the child domain applies only to that specific child domain1.
Therefore, for the parent domain, the business rule that was created in the parent domain will run.
The child domain’s override does not affect the operation of the parent domain’s business rules. This
ensures that each domain can have customized behavior while still inheriting the broader rules set at
the parent level.
It’s important to manage these rules carefully to maintain the intended data integrity and
operational workflows across different domains within the ServiceNow environment4.