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 and learning materials; 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 multi-tenant / domain-separated Now Platform instance for a service provider (for example, a Managed Service Provider or a telecommunications / Communications Service 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%)

This is the largest and most heavily tested domain. "Process separation" means that the behavior of the platform — not just the data — can differ per customer (per domain) on a single shared instance. Where data separation answers "who can see which records," process separation answers "which business logic runs for which tenant."

The override model

The cornerstone concept is the override. A process artifact (business rule, UI policy, client script, workflow/flow, notification, SLA definition, assignment rule, data lookup, etc.) is created once, usually in a high-level domain such as the global or TOP domain, and applies to every domain beneath it by inheritance. When one customer needs different behavior, you create a domain-specific copy of that artifact in their domain. The copy carries a reference back to the original through the sys_overrides field. At runtime the platform walks the requesting user's domain path and selects the most specific matching version: a copy in the user's own domain wins over a parent-domain version, which wins over the global original.

Key consequences to memorize:

Only one active override of a given parent record may exist per domain. You override the closest applicable record, not necessarily the global one.
An override is a true, independent copy. Editing the global original does not retroactively change a domain copy; the copy has diverged.
Removing (deleting) a domain override causes that domain to fall back to inheriting the parent/global version again.
The sys_overrides field is the field a CIS-SP must recognize as the link between an override and its parent record. It is the process-separation analog of the data-side sys_domain field.

Domain-aware (domain-separated) processes

For an override to be honored, the underlying process engine must be domain-aware. ServiceNow ships many engines as domain-separated:

Business rules run in the domain of the record they act on and can be overridden per domain.
Workflow (legacy Workflow editor) contexts are restricted to the domain of the triggering record; a user must be in the workflow's domain or a parent domain to see its context. Workflows can be overridden per domain.
Flow Designer / Workflow Studio flows, subflows, and actions support domain separation; the running domain governs which version executes and what data is visible to the flow.
Notifications, SLAs, assignment/data-lookup rules, UI policies, and client scripts are all overridable artifacts.
Orchestration / IntegrationHub activities respect the domain of their execution context.

When evaluating an exam scenario, ask: Is this engine domain-separated? and Where in the hierarchy does the version the user sees live?

Contextual data and the running domain

Process separation depends on a clear notion of the current (contextual) domain — the domain in which a given execution is "running." This is normally derived from the record being processed (its sys_domain) or from the logged-in user's domain. Scripts should rely on the platform's contextual domain resolution rather than hard-coding domain sys_ids or parsing the domain path string. Hard-coding domain paths is an explicit anti-pattern because the path is environment-specific and brittle; use the supported APIs/contextual lookups instead.

Practical implementation flow for a per-customer process change

Confirm the artifact's engine is domain-separated.
Switch domain context to the target customer's domain (domain picker).
Insert-and-stay / "Override" the parent record to create the domain copy (the platform stamps sys_domain to the current domain and sys_overrides to the parent).
Modify the copy's logic for that customer only.
Test as a user in that domain and as a user in a sibling domain to confirm isolation.

Domain 2 — Data Separation / Visibility (20%)

Data separation ensures each customer (domain) sees only its own records on the shared instance, while the service provider can see across customers as needed.

The `sys_domain` field and domain stamping

Every domain-separated table carries a sys_domain reference field pointing at the sys_domain table (the domain registry). When a record is created, the platform stamps it with the creating user's current domain. Queries are then automatically constrained by the user's domain visibility so that, by default, users see records in their own domain and its descendants.

`sys_domain` vs. `sys_domain_path`

sys_domain — the reference to the specific domain that owns the record.
sys_domain_path — a materialized path string that encodes the record's position in the domain hierarchy (a hyphenated/!-delimited representation of ancestors). It is what the platform uses internally to evaluate "is this record at or below the user's domain?" efficiently. CIS-SP candidates should know the path field exists and powers hierarchy queries, but should not parse or hard-code it in scripts.

Visibility domains vs. Contains domains

A user's data access is governed by visibility, set on the user's domain (or granted individually):

Visibility domains define the set of domains whose data a user can see.
"Contains" domains / "Contains" queries let a higher-level domain (e.g., the service provider's top domain) view records in all the domains it contains — the mechanism by which provider staff see across all customers, while a customer user is confined to their own subtree.

Global vs. default vs. TOP

Global domain — the base, system-owned domain; out-of-box configuration and the platform's defaults live here, and global is effectively the parent of everything.
TOP — the conceptual top of a customer's branch beneath global; in many models the service provider operates from a "TOP"/MSP domain.
Default domain — the domain a user falls into when no other domain applies.

Domain-separating a custom table

To make a custom table domain-aware you add a domain field (a domain type column) to it; the platform then participates that table in domain separation, stamping sys_domain on inserts and filtering reads by visibility. This is a common configuration task on the exam.

Domain 5 — Domain Support in Applications (17%)

Domain separation is a platform capability, but each application must explicitly support it; support level varies by product and release. ServiceNow publishes an "Application support for domain separation" reference listing, per application, whether it is supported, supported with conditions, or not supported, and what level (data only vs. data + process).

Candidates should know:

Core ITSM (Incident, Problem, Change, Request) is broadly domain-separated.
CMDB / Configuration Management supports domain separation but has specific behaviors around identification and reconciliation across domains.
Customer Service Management (CSM) is domain-aware, including account/contact and account-address handling, which is central to telecom/CSP and MSP scenarios.
Service Catalog, Knowledge Management, Service Portal, and Mobile each have documented domain-separation behavior — e.g., catalog items and knowledge bases can be scoped per domain so each customer sees its own.
Some applications are not domain-separated, or only partly; always verify against the official support matrix for the target release rather than assuming.

Exam strategy: treat "is application X domain-separated?" as a lookup question whose authoritative answer is the per-release support reference, and remember that data support and process support can differ.

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

This domain covers turning on and structuring domain separation.

Enabling domain separation

Domain separation is activated through the Domain Support – Domain Extensions Installer plugin (com.glide.domain.msp_extensions.installer) and related platform configuration; it is a significant architectural decision and is typically planned before customers are onboarded. Enabling it is not casually reversible, so the architecture is designed up front.

Domain hierarchy and the `sys_domain` table

Domains are records in the sys_domain table arranged as a tree. Each domain has a parent; global sits at the root. Children inherit data visibility and process artifacts from ancestors. A clean, shallow, well-named hierarchy (one branch per customer beneath a provider TOP domain) is the recommended pattern. The sys_domain_path is auto-maintained to reflect each domain's place in the tree.

System properties and the domain picker

Behavior is tuned via domain system properties (for example, the default domain scope and whether the domain picker is shown). Administrators with sufficient rights use the domain picker in the banner to switch their working domain when creating domain-specific data or overrides.

Recommended architecture practices

Keep hierarchies as flat as practical; deep nesting complicates visibility and performance.
Put shared, reusable configuration high (global/TOP) and override low (customer domains).
Avoid hard-coded domain references in scripts.
Plan domain naming and the provider-vs-customer boundary before onboarding.

Domain 4 — Foundational Data Management (11%)

"Foundational data" is the reference/master data customers need (users, groups, locations, companies, CMDB seed data, catalog content, etc.) loaded into the correct domain.

Key points:

Import Sets + Transform Maps are the standard mechanism for bringing customer data in; the transform must place rows in the correct domain (set sys_domain appropriately, often by running the import while in the target domain context or by mapping a domain value).
Data loaded while the import user is in a given domain is stamped to that domain; getting the running domain right is the crux of clean foundational loads.
Foundation/reference data shared across customers (truly common lookups) can live in global so all domains inherit it, while customer-specific master data lives in the customer's domain.
Be deliberate about users and groups: a user's domain and visibility determine what they can do; provider staff often need cross-domain visibility while customer users are confined to one domain.

Domain 6 — Platform Governance and Reporting (4%)

Smallest domain, but still tested.

Reporting respects domain visibility: a report run by a customer user returns only that customer's data; a provider user with contains/visibility across domains can report across customers. The same report definition therefore yields different result sets depending on who runs it.
Reports and dashboards are themselves domain-separable artifacts and can be scoped/overridden per domain.
Governance: use domain logs to find errors/warnings caused by domain-separation misconfiguration (e.g., a record created in an unexpected domain, or a process that crossed a boundary). Delegated/limited administration lets a customer's own admin manage their domain without seeing siblings.
Maintain governance over overrides — uncontrolled per-domain copies create maintenance drift; track which domains have diverged from the global baseline.

Fast-recall cheat list

Process separation = overrides. Create once high, copy-and-modify low; runtime picks the most specific version.
sys_overrides links a process override to its parent record (process side).
sys_domain = the reference field stamping which domain owns a record (data side).
sys_domain_path = materialized hierarchy path string; powers "at or below" queries; never hard-code/parse it.
One active override per domain per parent record; deleting it falls back to inheritance.
Domain-aware engines: business rules, legacy Workflow, Flow Designer/Workflow Studio, notifications, SLAs, UI policies, client scripts, data lookups, Orchestration.
Visibility domains = what a user can see; Contains domains = a parent seeing everything it contains (how the provider sees all customers).
global (root, OOB config) → TOP (provider branch) → customer domains → users in default domain when unspecified.
Add a domain field to domain-separate a custom table.
Import Set + Transform Map loads foundational data; stamp the correct domain (run in target domain context).
Application support varies — check the official per-release support matrix; data support ≠ process support.
Reports respect visibility — same report, different results per runner; use domain logs for troubleshooting.
Anti-patterns: hard-coding domain sys_ids or parsing the domain path in scripts; deep hierarchies.
Enabled via the Domain Support – Domain Extensions Installer plugin; architecture decided up front.