Domain separation and Workflow Studio

  • Release version: Zurich
  • Updated July 31, 2025
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Domain separation and Workflow Studio

    Workflow Studio supports domain separation, allowing ServiceNow customers to segment business logic—such as flows, actions, and subflows—by tenant domain. This enables multiple tenants or service provider customers to have isolated configurations and processes within a single instance. Domain separation controls visibility, access, and execution context for data and workflows based on the user’s domain, ensuring logical grouping and secure multi-tenancy.

    Show full answer Show less

    How Domain Separation Works in Workflow Studio

    • Content Ownership: Flows, actions, and subflows inherit the domain of the user who creates them. Selecting a different domain from the domain picker overrides the user’s default domain for content creation.
    • Execution Context: Flows run in the domain context of the record or user that triggers them, not necessarily where the flow was created.
    • Trigger Domain Assignment: The domain context when a flow triggers depends on trigger type—such as API calls, email sender, record, scheduled events, or catalog requests—ensuring actions respect domain boundaries.
    • Access Control: Users can only run Workflow Studio content accessible within their current domain context or its parent/child domains. Cross-domain triggering is limited to hierarchical relationships (parent-child), preventing sibling domain access.
    • Record Operations: These respect domain context and process separation rules, showing records belonging to the current domain and its children but not to sibling or parent domains unless allowed by the separation model.
    • Flow Execution: Multiple flows in different domains that meet trigger conditions will all run independently, with no flow able to block another.

    Best Practices and Guidelines for ServiceNow Customers

    • Centralized Management: Service provider administrators in the top domain should author and manage domain-specific content to ensure proper multi-tenant behavior and flow execution.
    • Unique Naming: Use unique and domain-specific names for flows, actions, and subflows to avoid confusion and ensure clear domain ownership (e.g., “Validate incidents - ACME”).
    • Domain Artifact Consistency: Flows and actions must only include components from their own domain or parent domains, preventing cross-domain contamination and activation errors.
    • Editing Restrictions: Administrators must switch to the relevant domain to view or edit domain-specific Workflow Studio content, as parent domains cannot see child domain flows.
    • Approvals Configuration: Workflow Studio can be configured to generate group approvals for domain-separated requests, either for all group members or restricted to those visible from the request’s domain.

    Domain separation is supported in Workflow Studio. Workflow Studio supports domain separation of business logic, which lets each tenant domain have its own flows, actions, and subflows. 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*

    • 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.
    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.

    How domain separation works in Workflow Studio

    The system domain separates Workflow Studio content according to these rules.

    Workflow Studio content inherits the domain of the user who creates them
    Flows, actions, and subflows belong to the domain of the user who creates them. For example, when a service provider (SP) administrator in the TOP domain creates a flow, it belongs to the TOP domain.
    Note:
    The domain selected from the domain picker overrides the domain the user belongs to. For example, when an SP administrator in the TOP domain selects the ACME domain from the domain picker, any content created belongs to the ACME domain.
    Workflow Studio content runs from the domain from which it is triggered or initiated
    Flows, actions, and subflows run from the domain of the record or user who initiates them. For example, when a user from the child domain ACME triggers a flow belonging to the parent domain TOP, the flow runs in the context of the child domain ACME.
    Table 1. Domain assignment by trigger type
    Trigger type Domain assignment
    API call Domain of the user making API call
    Email trigger Domain of the email sender
    Record trigger Domain of the triggering record
    Scheduled trigger Domain of the flow
    Service Catalog trigger Domain of the requested item record
    Workflow Studio only runs content accessible from the current domain context
    The system can only run content to which the current domain context allows access. See Understanding domain separation to understand data separation and the domain hierarchy. For example, a user in the child domain ACME can trigger flows belonging to the parent domain TOP, but cannot trigger flows belonging to a sibling domain such as INITECH.

    Workflow Studio runs record operations from the current user domain context. A read operation such as the Lookup Records action returns records based on the currently selected domain and its children. For example, if the currently selected domain is the TOP domain, you will see records from the TOP domain and all its children such as the ACME and INITECH domains. If the currently selected domain is the ACME domain, you will see records from the ACME domain and its children, but you will not see records from the parent TOP domain.

    Note:
    Record operations use the data or process separation rules applied to the table the record belongs to. For example, suppose you have process-separated the Business Rule table. If you add a business rule to the TOP domain, the business rule will be accessible to record operations in child domains such as the ACME domain because process separation allows access to records from parent domains.

    Flows that call another application such as a decision table or workflow also run from the current user domain context.

    Workflow Studio runs all flows whose trigger conditions are met
    A flow in one domain cannot override or prevent a flow from another domain from running. Workflow Studio runs any flow that is visible to the current user and whose trigger conditions have been met. For example, a flow belonging to the TOP domain that is triggered by the creation of an incident record runs anytime an incident is created, regardless of whether the incident is created in the ACME or INITECH child domains.

    General guidelines

    Follow these general guidelines when using domain separation with Workflow Studio.

    Ensure that tenant flows, actions, and subflows are run properly for domains
    Since tenants cannot override Workflow Studio content, a service provider (SP) administrator from the TOP domain must author and manage them to ensure they run properly for domains. While you can create domain-specific flows, users working from domains higher in the hierarchy may trigger multiple child domain flows. For example, a user working in the TOP domain can trigger flows in child domains such as ACME and INITECH.
    Note:
    Flow authors can see only Workflow Studio content available from their current domain and any parent domains in the hierarchy. Workflow Studio does not display content visible from Contains domains.
    Provide a unique name for each flow, action, and subflow
    Since all domains share Workflow Studio content, have an SP administrator in the TOP domain uniquely name each flow, action, and subflow to ensure that a flow intended for one domain does not duplicate the name of a flow in another domain. For example, add the domain to the flow name such as Validate incidents - TOP, Validate incidents - ACME, and Validate incidents - INITECH.
    Ensure that flows and actions only contain artifacts from current or parent domains
    Workflow Studio prevents the activation of any flow containing artifacts unavailable to the current or parent domains. For example, if you create a domain-specific flow that belongs to the ACME domain, it cannot contain actions or subflows belonging to the sibling domain INITECH.
    Edit Workflow Studio content in the domain to which it belongs
    Users in a parent domain can't see flows, actions, and subflows in a child domain. They must change to the domain to which they belong to edit them. For example, an administrator in the TOP domain can't see flows from the ACME domain. The administrator must switch to the ACME domain to see and edit them.