Domain separation and Flow Designer

Domain separation and Flow Designer

Flow Designer 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 then control several aspects of this separation, including
which users can see and access data.

Overview

Support: Level 2

Domain separation is
supported in this application. Not all ServiceNow applications support domain
separation; some include limitations on the data and administrative settings that can be
domain separated. To learn more, see Application support for domain
separation.

How domain separation works in Flow Designer

The system domain separates Flow Designer content according to these
rules.

Flow Designer 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.

Flow Designer 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

Flow Designer 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.

Flow Designer 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.

Flow Designer runs all flows
whose trigger conditions are met

A flow in one domain cannot override or prevent a flow from another domain from
running. Flow Designer 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.

Design considerations

Follow these design considerations when using domain separation with Flow Designer.

Have a Service Provider (SP) administrator in the TOP domain author and manage tenant
flows, actions, and subflows

Since tenants cannot override Flow Designer content, an SP
administrator from the TOP domain must author and manage them to ensure they run
properly for all domains. While you can create domain-specific flows, be aware that
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 Flow Designer content available
from their current domain and any parent domains in the hierarchy. Flow Designer does not display
content visible from Contains domains.

Provide a unique name for each flow, action, and subflow

Since all domains share the same Flow Designer 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 flows and actions only contain artifacts available from the current or parent
domains

Flow Designer 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 Flow Designer content in
the domain to which it belongs

While users in a parent domain can see flows, actions, and subflows in a child domain,
they must edit them in the domain they belong to. For example, an administrator in the
TOP domain can see flows from the ACME domain but must switch to the ACME domain to edit
it.

Domain separation and Flow Designer

Domain separation and Flow Designer

Flow Designer 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 then control several aspects of this separation, including
which users can see and access data.

Overview

Support: Level 2

Domain separation is
supported in this application. Not all ServiceNow applications support domain
separation; some include limitations on the data and administrative settings that can be
domain separated. To learn more, see Application support for domain
separation.

How domain separation works in Flow Designer

The system domain separates Flow Designer content according to these
rules.

Flow Designer 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.

Flow Designer 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

Flow Designer 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.

Flow Designer 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.

Flow Designer runs all flows
whose trigger conditions are met

A flow in one domain cannot override or prevent a flow from another domain from
running. Flow Designer 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.

Design considerations

Follow these design considerations when using domain separation with Flow Designer.

Have a Service Provider (SP) administrator in the TOP domain author and manage tenant
flows, actions, and subflows

Since tenants cannot override Flow Designer content, an SP
administrator from the TOP domain must author and manage them to ensure they run
properly for all domains. While you can create domain-specific flows, be aware that
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 Flow Designer content available
from their current domain and any parent domains in the hierarchy. Flow Designer does not display
content visible from Contains domains.

Provide a unique name for each flow, action, and subflow

Since all domains share the same Flow Designer 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 flows and actions only contain artifacts available from the current or parent
domains

Flow Designer 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 Flow Designer content in
the domain to which it belongs

While users in a parent domain can see flows, actions, and subflows in a child domain,
they must edit them in the domain they belong to. For example, an administrator in the
TOP domain can see flows from the ACME domain but must switch to the ACME domain to edit
it.

Confirm

SubscribeSubscribedUnsubscribeLast updated:Tags:JanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecemberNo Results FoundVersionsSearch preferences successfully updatedMy release version successfully updatedMy release version successfully deletedAn error has occurred. Please try again later.You have been unsubscribed from all topics.You are now subscribed toand will receive notifications if any changes are made to this page.You have been unsubscribed from this contentThank you for your feedback.Form temporarily unavailable. Please try again or contact
docfeedback@servicenow.com
to submit your comments.The topic you requested does not exist in therelease. You were redirected to a related topic instead.The available release versions for this topic are listedThere is no specific version for this documentation.Explore productsClick to go to thepage.Release notes and upgradesClick to open thedropdown menu.DeleteRemoveNo selected versionReset