---
sourceDocument: Zurich ServiceNow AI Platform Capabilities
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/servicenow-platform

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Domain separation and Workflow

# Domain separation and Workflow {#ariaid-title1}

* Release version: Zurich
* 
* Updated July 31, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Domain separation is supported in the Workflow application. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

## Support level: Standard\* {#c_WorkflowsAndDomainSeparation__section_skz_c1s_xkb}

* Includes Basic level
* Business logic: Processes can be created or modified per customer by the service provider. The use cases reflect proper use of the application by multiple service provider customers in a single instance.
* The owner of the instance needs to be able to configure MVP business logic and data parameters per tenant as expected for the specific application.
{#c_WorkflowsAndDomainSeparation__ul_idg_21s_xkb}Use case: As an admin, I need the ability to make comments mandatory on close of a record for one tenant, but not for another.

## Overview {#c_WorkflowsAndDomainSeparation__section_tjg_rg3_zdb}

When domain separation is enabled, workflows and workflow activities inherit the domain of the
user who publishes or creates them.

## How domain separation works in the Workflow application {#c_WorkflowsAndDomainSeparation__section_yx4_tg3_zdb}

While workflows are managed by multiple tables, only the following tables are used for domain separation features:

* Workflow \[wf_workflow\] and Workflow Version \[wf_workflow_version\]: used for [Process administration](https://www.servicenow.com/docs/access?context=c_DelegatedAdministration&version=zurich&pubname=zurich-platform-security&ft:locale=en-US) or process separation.
* Workflow Context \[wf_context\]: used for [Understanding domain separation](https://www.servicenow.com/docs/access?context=c_DomainSeparation&version=zurich&pubname=zurich-platform-security&ft:locale=en-US).
{#c_WorkflowsAndDomainSeparation__ul_abv_b2s_2r}  
Note:  
The Workflow Version table \[wf_workflow_version\] table does not contain a domain field; Workflow Version records inherit their domain from the parent Workflow record.

The Workflow Editor displays a workflow's domain in the title bar after the workflow name.  
Figure 1. Workflow editor domain
**Related topics**   

* [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=zurich&pubname=zurich-platform-security&ft:locale=en-US)

## Workflows and delegated administration {#ariaid-title2}

Delegated administration allows child domains to inherit workflows from higher up the
domain hierarchy and to override them with domain-specific versions if necessary.  
Figure 2. Workflow and delegated administration

Workflow records in the Workflow \[wf_workflow\] and Workflow Version \[wf_workflow_version\]
tables are considered processes. A user in a child domain may check out but not copy a workflow
from a parent domain. When a user in a child domain checks out a workflow from a parent domain,
the system creates a version of the workflow in that user's domain. This new version is a unique
record in the Workflow \[wf_workflow\] table. After the user publishes this new workflow, other
users in the child domain use the new workflow, which overrides the workflow from the parent
domain. The original workflow in the parent domain is no longer visible to users in the child
domain.

For example, a managed service provider (MSP) hosts ITSM services for several companies,
including ACME and Initech, on a single instance. As administrators, the MSP creates a Change
Request - Emergency workflow that applies to all domains because it was created in the TOP
domain, which is the highest domain in the domain hierarchy. This workflow overrides the global
Change Request - Emergency workflow and specifies that emergency change requests require approval
from the CAB approval group. Because of delegated administration, every domain in the hierarchy
sees and uses this workflow. Now suppose the ACME domain requires a different approval policy
where emergency change requests require approval from the emergency CAB approval group. The MSP
creates another version of the Change Request - Emergency workflow in the ACME domain. This
workflow overrides the version in the TOP domain and only applies to users in the ACME
domain.

## Workflow permissions {#ariaid-title3}

When a user starts a new workflow, the workflow runs with that user's domain and
credentials.

The workflow preserves a user's domain and credentials until an activity causes the workflow to
wait, such as an approval activity waiting for approval or rejection. When the stopped workflow
resumes, such as when a user approves a request, the workflow uses the credentials of the
approving user, but continues to run within the domain of the original user.