Process Separation
About 37% of the CIS-SP exam — see all 6 domains.
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_overridesfield 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_overridesis 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_overridesfield 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_domainset to your current domain andsys_overridesset to the original. - Test with users and records in that domain and in a sibling domain.
Sample questions from this domain
Three of the 110 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 restrict which records each tenant can read, so users see data only in their own domain, its child domains, and global records, never a parent's.
- B. To allow different domains to have different business logic and configuration (e.g., business rules, UI policies) while sharing one instance. ✓
- C. To give each customer its own database schema and storage, so tenant business logic never shares a table with another tenant.
- D. To let each tenant's administrators hold the admin role inside their own domain so they can configure the instance themselves.
Why: Process separation lets domains run different business logic and configuration, such as business rules, UI policies, and notifications, on one shared instance (processes flow down, with overrides where a tenant differs). Restricting which records a tenant can read describes data separation, not process separation. Domain separation does not give tenants their own schema or storage; tenants needing physical database isolation need separate instances. Process administration is not a way to hand tenants the admin role: the admin role passes every role check and can change its own domain, so it should never be given to tenants.
Which field on a process record, such as a business rule, links a domain-specific copy to the higher-level record it replaces for that domain?
- A. sys_domain
- B. sys_domain_path
- C. sys_overrides ✓
- D. sys_update_name
Why: sys_overrides is set automatically when an administrator in a lower domain modifies a policy owned by a higher domain: the update becomes an insert in the admin's current domain and sys_overrides points to the original record. sys_domain only records which domain owns the record, not which record it replaces. sys_domain_path is the automatically created path field used by the domain paths query method. sys_update_name identifies the record for update set tracking and has nothing to do with domain overrides.
When a domain overrides a baseline business rule, what happens for records in that domain?
- A. The domain's overriding business rule runs instead of the baseline/parent version. ✓
- B. Both the override and the baseline run, and the override executes second.
- C. The baseline rule runs, because a global business rule takes precedence over any domain copy of it.
- D. The override runs only when the user's home domain matches the override; otherwise the baseline runs.
Why: When an admin modifies a higher-level policy from a lower domain, the platform inserts an override, and for a relevant transaction the overriding domain-specific record is used instead of the original. For records in the overriding domain, the override replaces the baseline rather than running alongside it, so the two rules do not both execute. Global rules do not take precedence over domain overrides; the search starts at the record's domain and moves up. The user's home domain does not decide this: process administration uses the record's domain, which takes precedence over the user's domain.