CIS-SP Study Guide: Certified Implementation Specialist, Service Provider

Trademark disclaimer: ServiceNow, Now Platform, and all related product and release names are trademarks of ServiceNow, Inc. This study guide is an independent, original exam-preparation work created for commercial study use. It is not affiliated with, authorized by, sponsored by, or endorsed by ServiceNow, Inc. All technical statements are paraphrased in original prose from publicly available official ServiceNow documentation (Zurich release); no course text is reproduced.

Exam at a glance: 45 scored questions, 90 minutes, multiple choice (single answer) and multiple select. The CIS-SP validates the ability to design, configure, and support a domain-separated (multi-tenant) instance for a service provider, for example a managed service provider or a telecommunications provider serving many customers from one instance.

The domains below are presented in order of exam weight, heaviest first. Process Separation (37%) is the dominant domain, followed by Data Separation/Visibility (20%) and Domain Support in Applications (17%).

Domain 3: Process Separation (37%)

Process separation means the behavior of the platform, not just the data, can differ per domain on one shared instance. Data separation answers "who can see which records"; process separation answers "which business logic runs for which tenant." The docs list the separable business logic as tenant-specific system policies such as email notifications, business rules, client scripts, UI policies, and UI actions, plus UI elements such as views, lists, and forms.

Process administration and overrides

ServiceNow calls this process administration (also called delegated administration): administrators set domain-specific versions of policies.

A policy created in a high domain (global or the TOP process domain) runs for every domain below it, because processes flow down the hierarchy.
When an administrator, working in a lower domain, modifies a policy that belongs to a higher domain, the platform does not change the original. The update is turned into an insert in the administrator's current domain, and the new record's sys_overrides field points to the higher-level record. That new record is the override.
The override is used instead of the original for its domain and that domain's descendants that have no closer override. Other branches keep using the original.
Do not change a higher-level policy and then edit its Domain field; that neither creates an override nor keeps the original.
sys_overrides is a field on process records, not a table. To find overrides across the instance, use the Domain Override Viewer, which lists the tables that contain overrides and counts them per parent record.

Which domain decides the process

Process administration uses the record's domain, which takes precedence over the user's domain. The platform looks for policies in the record's domain, then each higher domain, up to global.
Business rules are always processed from the record's domain (the property glide.sys.domain.use_record_domain_for_processes restricts other processes to the record's domain too).
Test from an actual domain, not from global: the docs warn that overrides do not process properly in the global domain.

Override consequences to memorize

An override is an independent copy. Later changes to the original, including upgrades, do not flow into it; review and reconcile overrides after upgrades.
Deleting an override returns that domain to the inherited original.
An inactive override still replaces the original in its domain, so the behavior is switched off there. This is how you stop a global rule for one tenant. (Confirm on an instance; see the audit notes.)
An override is a replacement. To add steps for one tenant while keeping the global rule, create a separate rule owned by the tenant's domain instead; all policies in the record's domain or higher run.
Prefer few overrides. The docs recommend an 80/15/5 approach: about 80% standard, 15% parametric (driven by properties), and less than 5% one-off configuration.

How specific engines behave

Business rules, client scripts, UI policies, UI actions, data policies, modules and applications can be overridden per domain. Override Copy business rules also copy child records (UI policy actions, data policy rules, UI action views, modules).
Choice lists can be domain-specific: select the domain in the picker, then Configure Choices. A choice added later from global appears at the end of every domain-specific list (inactive there if it is not active at the global level).
Notifications are process-separated, not data-separated. A domain notification for the same event as a global one sends a second email unless its sys_overrides field points to the global notification. Email accounts are not domain separated, and inbound actions run in the sender's domain.
SLA definitions can be overridden in a sub-domain. A task SLA attaches when a definition exists in the task's domain or an ancestor, and task SLAs always take the task's domain.
Legacy Workflow: workflows are process records. Checking out a parent-domain workflow while in a child domain creates a version in that domain; once published it overrides the parent workflow there. Workflow contexts are data-separated.
Workflow Studio (Flow Designer) flows cannot be overridden. Flows belong to the domain of their creator (or the domain picker selection) and run in the domain of the triggering record or user. A flow in one domain cannot override or stop a flow in another, so a TOP flow still runs for child-domain records. Domain-specific flows need unique names and their own trigger conditions.
System properties [sys_properties] cannot be domain separated. Domain-specific values use the System Application Property Value table [sys_application_property_value], which has sys_domain and sys_overrides columns and is checked before sys_properties.

Practical flow for a per-customer process change

Confirm the application supports process separation (Standard level or above).
Switch the domain picker to the target customer's domain.
Open the higher-level record and modify it; the platform saves an override with sys_domain set to your current domain and sys_overrides set to the original.
Test with users and records in that domain and in a sibling domain.

Domain 2: Data Separation / Visibility (20%)

The core rule: data rises up, processes flow down

Members of a domain see data in their own domain and its child domains, plus global records. Users have no access to data in parent domains, peer domains, or other branches.
A parent domain therefore sees all of its children's data by default, and a child never sees its parent's (non-global) data.
Global is the absence of a domain on a record. Global records are available to every user unless security restricts them, so shared data lives there.

Domain assignment

Each record has one domain, stored in sys_domain. The value comes from, in practice: the user's company, a business rule, a module argument (sysparm_domain=sys_id), a form template, the parent record, or the domain on the user record. If none applies, the record takes the domain of the user who creates it.

Users, groups, locations, departments, and CIs take their company's domain. Changing a company's domain cascades to its locations, departments, groups, and users, except records with Managed domain selected.
Related records inherit the parent's domain (a change task from its change, attachments and emails from their record, task SLAs from their task).
Deactivating a domain deactivates its companies, and their users cannot log in.

`sys_domain` and `sys_domain_path`

Creating a Domain ID field named sys_domain automatically creates sys_domain_path. The domain paths query method (the default) uses it and is faster than older methods.
The path is recalculated when the hierarchy changes and is not captured in update sets, so validate the hierarchy after importing update sets. Use sys_domain in scripts, never the path.

Visibility domains vs. Contains domains

Visibility domains are a user-to-domain grant, added on User or Group records; group members inherit the group's visibility domains. They are always in effect regardless of the domain picker. Grant through groups, and use them sparingly.
Contains is a many-to-many, domain-to-domain relationship: when domain A contains B and C, users in A see data from all three. It is controlled by the domain picker and affects data only, never processes. Many Contains relationships create slow OR queries, so treat them as exceptions.
The parent-child hierarchy itself comes from each domain's Parent field, not from Contains.

Domain scope

Every session has a session scope (the user's domain, changeable with the domain picker) and a record scope (the record's domain, used when a form is open). By default the record scope wins.
Users with domain_expand_scope can use Toggle Domain Scope to expand to session scope or collapse to record scope.
By default, reference picker and related list data on a form are limited to the record's domain (glide.sys.domain.use_record_domain_for_data).

Global, Default, and TOP

Global: the absence of a domain; available to all users.
TOP: the conventional primary process domain. It holds processes and overrides and should never contain users.
Default domain: tasks and users with no domain are placed here automatically (Domain - Default - Task and Domain - Default - User). Only admins see it by default. Records in Default signal a configuration problem to triage. If no Default domain is set, those records go to global.
User placement: user records belong in customer domains (occasionally data domains), never in global or process domains. Only admin accounts belong in global.

Domain-separating a custom table

Add a field named sys_domain of type Domain ID (the name is reserved, so no u_ prefix is added and sys_domain_path is created too). Add business rules like Domain - Set Domain - Task and Domain - Default - Task so new records get the right domain. Do not domain-separate base system tables, and never sys_ tables such as sys_dictionary. The platform blocks separation of ACLs, script includes, system properties, and dictionary tables.

Domain 5: Domain Support in Applications (17%)

ServiceNow publishes an Application support for domain separation reference that lists each application's level:

No support: the domain field may exist, but no logic manages the data. Not considered domain-separated.
Basic (customer data management): data goes into the proper domain, and the UI, reports, cache keys, and aggregations consider the domain.
Standard (customer process management): includes Basic. The service provider can create or modify processes per customer.
Enhanced (customer self-managed configuration): includes Basic and Standard. Tenants configure defined business logic themselves through fail-safe UI.
An asterisk (for example Standard*) marks effective domain support: the use cases are met even though the domain framework is not used in the standard way.

Examples from the Zurich reference and application pages:

Incident, Problem, Service Catalog, Knowledge Management, Notifications, CMDB: Standard. Change Management: Basic (change properties are global). Workflow and Workflow Studio: Standard*. Service Portal: No support. Check the reference for every other application, because levels change by release.
Service Catalog needs the Service Catalog - Domain Separation plugin (com.glideapp.servicecatalog.domain_separation). Catalog items, record producers, content items, and order guides are separated as data; catalogs, categories, and variables are not and stay global. An item is requestable only in its own domain; shared items go in global and are restricted with user criteria. Catalog client scripts and catalog UI policies are process-separated (the docs recommend not overriding them).
Knowledge Management: knowledge bases, articles, user criteria, and templates are separated. Child-domain users read articles in their own domain and global (given read access), not their parent's.
Service Portal: portals, pages, and widgets are not separated, but record data inside widgets follows the user's domain. Create separate portals with unique URLs for different tenant experiences.
Customer Service Management: with the csm_auto_account_domain_generation property, each new account creates a domain under TOP (a sub-domain of its parent account); without it, new accounts go to the Default domain.
Data in a table with no domain field behaves globally, even when it is written from a domain-separated application.

Domain 1: Initial Domain Setup and Architecture (11%)

Enabling domain separation

Request the Domain Support - Domain Extensions Installer plugin (com.glide.domain.msp_extensions.installer), usually called the Domain Separation plugin, before activating com.snc.pa.domain_support. Activate it at the start of an implementation, ideally before other plugins. Enabling it late puts every existing record in global.
Domain separation can be disabled but cannot be removed from an instance. For a live instance, the Post-Production Domain Separation Activation Utility (com.glide.domain.activation_utility) gives a guided setup.
The plugin adds the domain_admin role (create, edit, delete domains), sys_domain on tables such as groups, group members, companies, locations, departments, role assignments, emails, attachments, and reports, the task_for field on Task, and the Domain business rules.

Creating the hierarchy

Domains are created under All > Domain Admin > Domains. The form has Name, Type (Vendor, Customer, MSP by default), Primary, Default, Parent, Active, and Description, with Companies, Contains Domains, and Contained By related lists.
Only one domain can be Primary (the top of the domain map, with no parent and at least one child) and only one can be Default.
The Domain Map (Domain Admin > Domain Map) is a read-only picture of active domains with a Parent (only the primary domain may have no parent).
Deactivate domains you no longer need; do not delete them. The Delete by domain cleanup queue removes inactive leaf domains in a controlled way.
Change the hierarchy rarely and in small batches; each change triggers cascade updates (Domain Work Requests). The Domain Job Manager can pause and queue these jobs.

Domain picker and properties

The domain picker sets the session domain. The domain reference picker (glide.ui.domain_reference_picker.enabled) suits long domain lists. glide.ui.polaris.domain_picker.role controls who sees the picker in Next Experience (itil and admin by default).
The number of domains does not hurt performance as much as what they contain; avoid loading many domains (over 30) by import without testing.

Architecture guidance

Use domain separation when tenants need data segregation, provider-managed per-tenant processes, and some global processes and reporting on one instance. Use separate instances when tenants need total separation of system properties or physical database isolation.
Typical hierarchy: global, then TOP (process domain), then customer domains, with a Default domain for lost records. Restricted and Unrestricted branches under TOP let one Contains grant reach most customers.

Domain 4: Foundational Data Management (11%)

Import Sets and Transform Maps load customer data. Rows get a domain the same way as any record: from business rules (company), from a transform that sets sys_domain (to the domain record's sys_id), or from the domain of the user running the import.
Run imports in the target domain context, or map sys_domain per row from a source column (field map or onBefore script).
Coalesce lookups run through the normal domain-restricted query, which includes global and child-domain records, so a weak coalesce key can match and update a record outside the intended tenant.
Place shared reference data in global; data in a parent domain is not visible to children. Customer-specific users, groups, locations, and CIs belong in the customer's domain (usually through their company).
Validate sys_domain after loads and triage anything that landed in the Default domain.
Update sets carry configuration, not data, and do not carry sys_domain_path; make sure target domains exist before committing domain-owned configuration.
Data archiving keeps each record's domain.

Domain 6: Platform Governance and Reporting (4%)

Reporting: report results follow the domain of the user running them, so the same report returns different data per tenant, and a provider user above the customers can aggregate across them. Reports are separated into domains and have an Overrides field; from global, use Expand Domain Scope to see them all.
Domain Separation Center (All > Domain Admin > Domain Separation Center, or /domaincenter): configure and schedule the built-in audits (inactive by default; daily, weekly, or monthly), run them now, review audits with errors and warnings, and enable detailed domain logging. Avoid daily audits on large tables.
Domain Log [syslog_domain]: holds domain path recalculation results and audit details. Verbose logging (glide.sys.domain.verbose) plus session debug shows the domains each query was restricted to.
Customer administration: domain separation is built for the provider to configure services. Customers can safely manage reports, CIs, and users without roles; for that, create custom "customer admin" roles and ACLs. The admin role passes every role check and can change its own domain, so do not give it to tenants. Choice lists and other global parameters stay with the provider's admin team.
Global parameters common to every domain include system properties, dictionary overrides, field labels (sys_documentation), the data model, ACLs, and inbound actions.

Fast-recall cheat list

Data rises up, processes flow down. Parents see children's data; children inherit parents' processes; global records are visible to all.
Override = insert in the lower domain, linked by sys_overrides (a field). It replaces the original for that domain and its descendants.
Record's domain decides the process, not the user's domain.
Inactive override = behavior off in that domain. Deleting the override restores inheritance.
Workflow Studio flows cannot be overridden; legacy workflows can (check out in the child domain).
Notifications: set sys_overrides on the domain copy or users get two emails.
Visibility domains: users and groups, always on. Contains: domain to domain, data only, follows the picker. Parent field: defines the hierarchy.
Default domain catches tasks and users with no domain; only admins see it.
No users in global or TOP; only admin accounts in global.
Support levels: No support, Basic, Standard, Enhanced (asterisk = effective domain).
Catalog: items separated as data; catalogs, categories, variables are global.
Service Portal: No support; widget data follows the user's domain.
sys_properties cannot be separated; use application property values.
Domain Separation Center = audits, not domain setup or support levels.
Customer admins: custom roles and ACLs, never the admin role.
Enable early with com.glide.domain.msp_extensions.installer; it cannot be removed later.