Support level: Standard*

The support level is Standard but has some exceptions or special conditions.

• Includes Basic level
• Business logic: Processes can be created or modified per customer by the service provider (SP). The use cases reflect proper use of the application by multiple SP customers in a single instance.
• The owner of the instance needs to be able to configure minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application.

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.