Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Now Platform capabilities
Table of Contents
Choose your release version
    Home New York Now Platform Capabilities Now Platform capabilities Flow Designer Domain separation and Flow Designer

    Domain separation and Flow Designer

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    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.
    Related topics
    • Domain separation

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Domain separation and Flow Designer

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      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.
      Related topics
      • Domain separation

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank 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 the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login