---
sourceDocument: Australia Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/pt-BR/build-workflows
Release :
- australia
ft:locale :
- pt-BR
ft:publication_title :
- Australia Build workflows
ft:clusterId :
- crworkflow
bundleId :
- crworkflow
workflow :
- Creator
---
# Domain separation and Workflow Studio
# Domain separation and Workflow Studio {#ariaid-title1}
* Versão de lançamento: Australia
*
* Atualizado 12 de mar. de 2026
*
*  5 min. de leitura
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\* {#flow-designer-domain-separation__section_pvf_wkx_vcb}
* 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.
{#flow-designer-domain-separation__ul_gln_mrr_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.
## How domain separation works in Workflow Studio {#flow-designer-domain-separation__section_ydt_kth_scb}
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.
Nota:
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.
{#flow-designer-domain-separation__table_ity_dsj_vhb__entry__2}
| 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 |
[Tabela 1. Domain assignment by trigger type]
{#flow-designer-domain-separation__table_ity_dsj_vhb}
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](https://www.servicenow.com/docs/access?context=c_DomainSeparation&version=australia&pubname=australia-platform-security&ft:locale=en-US) 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.
Nota:
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 {#flow-designer-domain-separation__id_zb5_tvb_ptb}
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.
Nota:
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.
**Tópicos relacionados**
* [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=australia&pubname=australia-platform-security&ft:locale=en-US)