Process Separation
About 37% of the CIS-SP exam — see all 6 domains.
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_overridesfield 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-sidesys_domainfield.
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_domainto the current domain andsys_overridesto 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.
Sample questions from this domain
Three of the 111 in this domain, with the reasoning. The full set is in the question bank.
What is the primary purpose of process separation in domain separation?
- A. To encrypt process data.
- B. To allow different domains to have different business logic and configuration (e.g., business rules, UI policies) while sharing one instance. ✓
- C. To disable workflows globally.
- D. To duplicate the entire instance per customer.
Why: Process separation lets each domain run different configuration and business logic (such as overridden business rules, UI policies, and workflows) on a single shared instance. It is not about encryption, full instance duplication, or disabling workflows.
Which table records the per-domain overrides that implement process separation for configuration records?
- A. sys_audit
- B. sys_domain_path
- C. sys_overrides ✓
- D. sys_email
Why: sys_overrides stores the override relationships that let a domain substitute its own version of a configuration record (such as a business rule) in place of the parent/baseline version. sys_domain_path is for visibility, sys_audit for history, and sys_email for messages.
When a domain overrides a baseline business rule, what happens for users in that domain?
- A. The domain's overriding business rule runs instead of the baseline/parent version. ✓
- B. The baseline rule always wins.
- C. Both rules run and conflict.
- D. No business rule runs.
Why: An override causes the domain-specific version of the configuration record to take precedence over the parent/baseline version for users in that domain. Both do not run simultaneously, separation does not remove all rules, and the override (not baseline) wins in that domain.