CIS-SP Practice Questions

The Choice Action setting on a transform field map determines how the system handles an incoming value for a choice or reference field when that value does not match an existing choice or referenced record. Setting this action to Ignore instructs the import process to skip the transformation for that specific field, leaving it blank on the target record, but continuing to process the rest of the row. This is the correct strategy when you want to prevent the automatic creation of new, potentially invalid, choices or referenced records (i.e., "dummy records") in the target tables, thereby maintaining data integrity.

B. To reject new rows that doen't have choice values present.

This describes the reject choice action, which stops the transformation for the entire row if a matching choice or reference value is not found.

C. To insert missing rows in a referenced table.

This describes the create choice action, which automatically creates a new choice or a new record in the referenced table if a match is not found.

D. To transform a field value using a script.

Transforming a field value with a script is accomplished by enabling the Use source script option in the field map, not by setting the Choice Action.

1. ServiceNow Product Documentation - Field maps: In the section "Create new choices or add new referenced records," the documentation outlines the three Choice action options. It specifies that ignore will "ignore new values in the source field," which directly supports the reasoning for avoiding the creation of new records.

2. ServiceNow Product Documentation - Add a field map: This document details the fields on the Field Map form. For the Choice action field, it states that ignore will "ignore the new value." This confirms that the field's value is disregarded, preventing the creation of a new record as described in the create option.

When an administrator in a child domain attempts to modify a record (such as a policy or business rule) that belongs to a parent or global domain, the system prevents direct modification. Instead, it creates a copy of the record in the administrator's current domain. This new record is called an override. To maintain the relationship between the original record and the new override, the system automatically populates the sysoverrides field on the new record with the sysid of the original record. This allows the system to use the domain-specific version for users in that domain.

B. sysprimarydomain: This is not a standard system field used in the domain override process.

C. sysadmindomain: This is not a standard system field used in the domain override process.

D. sysdomainowner: This is not the correct field name. The standard field that links an override to the original record is sysoverrides.

1. ServiceNow Product Documentation - Domain Separation Explained: In the section "How domain separation works," the documentation details the override process: "When a user in a child domain modifies a record from a parent or global domain, the system creates a copy of the record in the child domain. This copy is called an override. The system then adds a reference to the original record in the sysoverrides field on the new record."

2. ServiceNow Product Documentation - Dictionary Overrides: The documentation on Dictionary Overrides explains the function of the sysoverrides field, stating, "The Overrides field (sysoverrides) contains the sysid of the record it overrides." This confirms the field's purpose in linking a domain-specific version to its global or parent counterpart.

In a ServiceNow instance with Domain Separation, a user's visibility into different domains is determined by an inheritance model. Visibility can be explicitly granted to an individual user by adding domains to the 'Visibility domains' related list on their user record. Alternatively, and more commonly for scalability, visibility is granted to a group. Any user who is a member of that group automatically inherits the domain visibility assigned to it. These two methods allow users to see records and data from domains other than their session domain.

C. Role: Roles grant permissions to access applications and perform actions (e.g., create, read, write, delete), but they do not control data visibility across domains.

D. Default Domain: The Default domain is a specific domain assignment for system-level configurations. Assigning a user to it does not grant them visibility into other tenant domains.

1. ServiceNow Product Documentation - Domain separation visibility:

"Visibility domains grant users visibility to a domain other than their own. You can grant domain visibility to a user or a group." This statement directly supports both correct answers (A and B). The documentation further clarifies, "Users inherit visibility from any groups that they are a member of."

Source: ServiceNow Product Documentation, "Domain separation visibility," Rome release.

2. ServiceNow Product Documentation - Grant a user domain visibility:

This document outlines the procedure for adding domains to the domainvisibility related list on a user's record, confirming that visibility can be granted directly to a user.

Source: ServiceNow Product Documentation, "Grant a user domain visibility," Washington DC release.

3. ServiceNow Product Documentation - Domain separation and roles:

"Roles control access to applications and modules. Domain separation controls access to data." This reference explicitly distinguishes the function of roles from domain visibility, confirming that roles are not a means of granting domain visibility.

Source: ServiceNow Product Documentation, "Domain separation and roles," Washington DC release.

The glide.knowman.alloweditglobalarticles system property is specifically designed to override the default security behavior in a domain-separated environment for Knowledge Management. By default, knowledge articles in the 'global' domain can only be edited by users who are also in the global domain. When this property is set to true, it explicitly grants users in other, specific domains the ability to check out and edit these global articles. The user must still possess the necessary underlying permissions (e.g., contributor access to the specific knowledge base) to perform the edit. The edited article remains in the global domain.

A. Users in global can check out and edit global articles

This describes the default behavior. Users in the global domain with appropriate roles can always edit global articles; enabling this property does not change their permissions.

B. Users from any domain with a knowledge admin role and can check out and edit global articles

This is incorrect because the functionality is not exclusively limited to the knowledgeadmin role. Any user with the required contribution permissions can edit the article, not just administrators.

C. Users with admin rights from global domain can check out and edit global articles

This is incorrect for the same reason as option A. This is standard behavior for administrators in the global domain and is not the change effectuated by this property.

1. ServiceNow Product Documentation - Domain separation for Knowledge Management: "By default, users in a specific domain cannot edit knowledge articles in the global domain. To allow users to edit global knowledge articles, set the glide.knowman.alloweditglobalarticles system property to true. When this property is set to true, users in a specific domain can check out and edit a global knowledge article. The edited article remains in the global domain." (ServiceNow Vancouver Docs, Doc ID: KB0752083).

2. ServiceNow Product Documentation - Knowledge Management properties: The property glide.knowman.alloweditglobalarticles is described as: "Allow users in a domain to edit a global article. When set to true, users in a domain can check out and edit a global article. The edited article remains in the global domain." (ServiceNow Vancouver Docs, Section: "Installed with Knowledge Management").

Process Separation is a core component of ServiceNow's Domain Separation architecture. It allows different domains (e.g., representing different customers or business units) to have unique business processes, user interfaces, and business logic (like business rules, client scripts, and UI policies) on a single instance. This capability enables a domain-specific administrator, often with the domainadmin role, to manage their domain's configuration and processes independently. This practice of managing a specific domain's processes and configuration is known as domain administration. Therefore, Process Separation is the technical mechanism that enables the function of domain administration.

A. proxy administration: This is not a standard ServiceNow term. It generally refers to an administrator acting on behalf of another user, which is different from managing a domain's processes.

B. delegated administration: This is a broader concept. The entire Domain Separation model (including both data and process separation) is a form of delegated administration, not just Process Separation itself.

C. process administration: This term is too generic. While Process Separation involves administering processes, it is not the specific term used as a synonym in the context of Domain Separation.

E. admin administration: This is a redundant and meaningless term in the context of ServiceNow administration.

1. ServiceNow Product Documentation - Domain Separation: The documentation explains that Domain Separation enables the delegation of administrative tasks to domain-specific administrators. The section on "Delegated administration" states, "Domain separation allows you to delegate the administration of individual domains. For example, you can grant a user the domainadmin role. A user with this role can act as an administrator for a specific domain." This directly links the feature to the function of domain administration. (Reference: ServiceNow Product Documentation, search for "Domain Separation" and "Delegated administration").

2. ServiceNow Product Documentation - Domain Separation setup: The setup guide details the domainadmin role, which is explicitly created to perform domain administration. The permissions granted to this role, such as creating and modifying policies, business rules, and other logic within their assigned domain, are the direct result of the Process Separation feature. (Reference: ServiceNow Product Documentation, search for "Domain Separation setup" and the domainadmin role).

On a baseline ServiceNow instance where the Domain Support - MSP Extension plugin is activated, several default domain types are created to support common Managed Service Provider (MSP) business structures. These predefined types are 'MSP', 'Customer', and 'Vendor'. They serve as classifications within the [domain] table to logically organize the domain hierarchy. The 'MSP' type is for the provider's own domain, 'Customer' for client domains, and 'Vendor' for third-party supplier domains, enabling tailored data and process segregation.

B. Primary: 'Primary' is not a domain type; it refers to the default domain assigned to a user in their user record, determining their domain upon login.

C. TOP: 'TOP' is the name of the root record in the domain hierarchy from which all other domains extend. It is not a classification or a 'type' of domain.

1. ServiceNow Product Documentation - Domain separation setup: In the section "Default domain types," it is stated: "The Domain Support - MSP extension plugin creates the following domain types by default: Customer, MSP, Vendor." This directly confirms the correct answers. (ServiceNow Product Documentation, Utah release, "Domain separation setup").

2. ServiceNow Product Documentation - Domain separation for Managed Service Providers (MSPs): This document explains the intended use of these types: "Classify domains as either MSP, Customer, or Vendor domains to logically separate them. For example, you can create business rules that apply only to domains classified as Customer domains." (ServiceNow Product Documentation, Utah release, "Domain separation for Managed Service Providers (MSPs)").

The recommended approach for a successful and maintainable Domain Separation implementation, as advised by ServiceNow, is to heavily rely on standard data separation. This model suggests that at least 80% of separation requirements should be met using the out-of-the-box sysdomain field on data records. Approximately 15% can be handled through data-driven rules, where domain assignment is automated based on record attributes (e.g., company). Critically, configuration-level separation (creating domain-specific business rules, UI policies, etc.) should be minimized to less than 5%. This strategy reduces complexity, lowers maintenance overhead, and simplifies future platform upgrades.

A. Incorrect. This model significantly understates the reliance on Standard separation (should be 80%+) and vastly overestimates the acceptable level of Configuration separation (should be <5%).

B. Incorrect. This option incorrectly prioritizes data-driven separation over Standard separation. The primary method should always be the standard, out-of-the-box functionality.

C. Incorrect. While the percentage for Configuration is correct, the recommended target for Standard separation is higher (80% or more) to ensure maximum use of the core platform feature.

1. ServiceNow Training Courseware: CIS - Domain Separation Implementation. In the "Domain Separation Architecture and Best Practices" module, ServiceNow explicitly presents the "80/15/5" rule as the target model for implementation: 80% or more Standard data separation, 15% or more data-driven separation, and less than 5% configuration/process separation.

2. ServiceNow Product Documentation: Domain separation best practices. While the documentation does not state the exact percentages, it strongly reinforces the principle behind them: "Avoid creating domain-specific configurations unless absolutely necessary... Over-configuration can lead to performance issues and upgrade difficulties." This supports minimizing the configuration percentage to the lowest possible value, as reflected in option D. (ServiceNow Product Documentation, Quebec release, "Domain separation best practices" section).

3. ServiceNow White Paper: A Guide to Implementing Domain Separation. This guide emphasizes that the goal of domain separation is data segregation, not creating distinct application logic for each domain. It states, "The key to a successful Domain Separation implementation is to keep it simple... Limit the amount of domain-specific customization." This aligns with the 80/15/5 model where customization (configuration) is kept below 5%.

In a domain-separated ServiceNow instance, child domains inherit configurations and processes, including business rules, from their parent domains. When a business rule exists in a parent domain and a separate, non-overriding business rule is created in a child domain for the same table, the system's behavior is additive. Both business rules will be triggered and executed for records within the child domain, provided their respective conditions are met. The parent domain's rule typically runs first, followed by the child domain's rule, allowing for layered business logic across the domain hierarchy.

A. The parent rule will run: This is incorrect because the child domain's own separate business rules are also active and will execute in addition to the inherited parent rule.

C. The child rule will run: This describes the behavior when a child domain rule is configured to explicitly override a parent domain rule. The question specifies a "non-overriding" rule.

D. Neither rule will run: This is incorrect. Unless their conditions are not met or they are inactive, both rules are in scope for the child domain and will execute.

1. ServiceNow Product Documentation: Override a business rule for a domain. In the "Results" section, the documentation explicitly states: "If you do not override the business rule, both the parent business rule and the child business rule run." This directly confirms the additive nature of non-overriding rules.

2. ServiceNow Product Documentation: Domain separation business rules. This document explains the fundamental principle: "By default, business rules in a parent domain apply to all child domains." This establishes the basis of inheritance, which is then supplemented by any rules created directly in the child domain.

ServiceNow's domain separation model operates on a hierarchical, top-down principle of data visibility. Users assigned to a parent domain have the ability to view and access data within their own domain as well as all data contained within any of its child domains. This allows a service provider (in the parent domain) to manage and report on all its customers (in child domains). Conversely, users in a child domain are restricted from accessing data in the parent domain or any sibling domains, ensuring data segregation and security for each tenant.

A. Incorrect because data access is not bidirectional. Child domain users cannot access parent domain data by default.

C. Incorrect as this describes bottom-up visibility, which is the opposite of how ServiceNow's domain hierarchy functions.

D. Incorrect because parent domain visibility is recursive; it extends to all descendant domains, including any domains contained within a child domain.

1. ServiceNow Product Documentation: Domain separation explained. "Users in a parent domain can view and access data from its child domains. For example, users in the TOP domain can access data from all other domains... Users in a child domain cannot see data in their parent domain."

2. ServiceNow Product Documentation: Domain hierarchy. "By default, users can see data in their own domain and in child domains. For example, a user in the TOP domain can see records in the TOP domain, the MSP domain, and the Customer A and Customer B domains." This confirms that visibility cascades down the entire hierarchy.

The ServiceNow Domain Separation audit is a tool designed to identify and help resolve potential configuration issues. The audit results page provides a comprehensive report that includes a list of all records or configurations affected by identified errors or warnings (C). For each issue, the system provides recommended actions to remedy errors and warnings, guiding the administrator on how to correct the misconfiguration (D). The interface for the audit results also includes functionality such as the ability to re-run the audit, allowing administrators to verify that their fixes have resolved the reported issues (E).

A. incorrect user domain logins: The domain audit focuses on configuration health and data integrity, not real-time user authentication events like incorrect logins, which are typically found in system or event logs.

B. escalate the errors as incidents: While an administrator might manually create an incident based on audit findings, there is no native, built-in action within the domain audit report to automatically escalate errors as incidents.

1. ServiceNow Product Documentation - Run the domain separation audit:

"The domain audit provides a report of potential domain configuration issues and data mismatches. The audit also provides recommended actions to remedy errors and warnings." (Supports D)

"Each error or warning includes a link to the affected record or configuration." (Supports C)

The documentation page shows a screenshot of the Domain Audit Results page which clearly displays a "Re-run Audit" button as a primary action available on the form. (Supports E)