--- sourceDocument: Yokohama ServiceNow AI Platform Capabilities sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/servicenow-platform Release : - yokohama ft:locale : - en-US ft:publication_title : - Yokohama ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # Domain separation and Service Catalog # Domain separation and Service Catalog {#ariaid-title1} * Release version: Yokohama * * Updated January 30, 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Service Catalog Domain separation in Service Catalog allows you to logically separate data, processes, and administrative tasks into domains, enabling control over which users can view and access data. This feature supports service providers managing multiple customers within a single ServiceNow instance, ensuring data privacy and isolation by restricting access to catalog items based on domain membership. Show full answer Show less To enable this capability, the **Service Catalog - Domain Separation plugin** must be activated. This plugin is essential when you need to isolate catalog items so they are only accessible to requesters within a specific domain, preventing cross-domain access regardless of domain hierarchy. ## How Domain Separation Works in Service Catalog * Catalog items such as catalog items, record producers, content items, and order guides are domain-separated data. * Catalogs, categories, and variables remain in the global domain and are not domain-separated. * Items that need to be shared across domains must be published in the global domain and restricted through user criteria. * Domain separation applies across all requester interfaces including ServiceNow AI Platform, Service Portal, Agent Workspace, mobile apps, and API calls. * Domain information is recorded in domain-separated tables (e.g., sccatitem, scitemoption). ## Catalog Item Creation, Maintenance, and Visibility * Catalog items are created and maintained within the user's effective domain, determined either by single domain visibility or the domain picker selection. * Once created or published in a domain, catalog items can only be modified within that domain. * User criteria associated with a catalog item must be visible within the item's domain to be effective. * Catalog items are only available for request within their domain and the global domain; they are not accessible to parent, child, or peer domains. * For users with access to multiple domains, the domain picker controls which domain's catalog items are visible and requestable. * Order guides containing items from multiple domains only process items from the user's effective domain and the global domain. ## Request Fulfillment and Reporting * Requests, requested items, and records created by record producers are domain-separated and accessible only to fulfillers with visibility in the target domain. * Modifications to requested items are tracked within the domain of the original record, even if edited by a fulfiller from another domain. * Reports retrieve data based on the effective domain of the user running the report, maintaining domain data isolation. * Fulfillers can create requests only within the domain of the parent record or the global domain, and cannot add items from multiple domains to a single cart. ## Catalog Client Scripts and UI Policies * Catalog client scripts and UI policies are domain-separated processes; scripts and policies defined in a parent domain can be overridden in child domains. * The domain context of the catalog item or target record determines which script or policy applies during fulfillment. * It is recommended to avoid overriding catalog client scripts and UI policies to maintain consistency. ## Activation and Configuration To enable domain separation in Service Catalog, request activation of the **Service Catalog - Domain Separation plugin (com.glideapp.servicecatalog.domainseparation)**. Activation is advisable only when there is a need to isolate catalog items strictly by domain to enforce data privacy and access control. ## Practical Impact for ServiceNow Customers Implementing domain separation in Service Catalog enables service providers and multi-tenant customers to: * Maintain strict data isolation between tenants or business units. * Control catalog item visibility and requestability based on domain membership without complex user criteria. * Ensure that request fulfillment and reporting respect domain boundaries to maintain data privacy. * Leverage domain-aware client scripts and UI policies to customize behavior per domain while preserving hierarchy rules. This results in a secure, manageable multi-tenant Service Catalog environment aligned with organizational requirements for data segregation and access control. Domain separation is supported in Service Catalog. 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 {#domain-separation-service-catalog-management__section_oml_4cr_xkb} * Includes all aspects of Basic level support. * Application properties are domain-aware as needed. * Business logic: The service provider (SP) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance. * The instance owner must configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application. {#domain-separation-service-catalog-management__ul_tfh_drj_xkb} Sample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.{#domain-separation-service-catalog-management__p_ssc_nfg_h1c} For more information on support levels, see [Application support for domain separation](https://www.servicenow.com/docs/access?context=domain-separated-apps&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).{#domain-separation-service-catalog-management__p_tsc_nfg_h1c} ## Activation information {#domain-separation-service-catalog-management__section_vnv_rps_d3b} You should activate the Service Catalog - Domain Separation plugin (com.glideapp.servicecatalog.domain_separation) to enable domain separation for Service Catalog. For information on how you can request for the plugin activation, see [Request for domain separation in Service Catalog](https://www.servicenow.com/docs/wjcgBkE6HR3ajujreXxIpw "Enable domain separation in Service Catalog by requesting for the activation of the Service Catalog - Domain Separation plugin (com.glideapp.servicecatalog.domain_separation)."). This plugin should only be activated if there is a need for the following scenarios: * Isolate items to requesters in a specific domain. * Make items unavailable for request in any other domain irrespective of the domain hierarchy. {#domain-separation-service-catalog-management__ul_jns_bgl_33b} If Service Catalog has already been domain separated as a custom solution, activating this plugin may override the existing behavior to enforce the plugin-specific isolation. ## How domain separation works in Service Catalog {#domain-separation-service-catalog-management__section_o1d_5ps_d3b} Service providers supporting multiple customers in a single ServiceNow instance can ensure data privacy across domains using domain separation. Service providers can ensure that items created or published in a specific domain can only be requested by users in that domain without adding additional user criteria to the individual catalog items. In Service Catalog, catalog items (catalog items, record producers, content items, and order guides) are domain-separated as data. Catalogs, categories, and variables are not domain-separated, and belong to the global domain. Also, items that need to be shared across multiple domains must be published in the global domain and restricted by user criteria. Domain separation in Service Catalog is applicable to all requester views in the ServiceNow AI Platform, Service Portal, Agent Workspace, mobile application, as well as to all API calls requesting for items. ## Domain-separated tables {#domain-separation-service-catalog-management__section_w2p_yps_d3b} The Domain (sys_domain) and Domain Path (sys_domain_path) columns are added to the following tables that are domain-separated: * sc_cat_item * sc_item_option * sc_multi_row_question_answer * question_answer {#domain-separation-service-catalog-management__ul_fw2_bqs_d3b} ## Effective domain for a user {#domain-separation-service-catalog-management__section_idz_vhl_33b} For users with visibility to a single domain, the effective domain is the user's domain. For users with visibility to multiple domains, the effective domain is the domain selected in the domain picker. ## Visibility of catalog items - Item creation and maintenance {#domain-separation-service-catalog-management__section_bbg_chl_33b} A catalog item can be created or published in any domain in the hierarchy. For information on creating a catalog item, see [Create or edit a catalog item](https://www.servicenow.com/docs/ghhc5zl8MigPhi0BhtGCdw#t_DefineACatalogItem "Define individual catalog items using Service Catalog. You can create, edit, and copy catalog items.").The item is created in the effective domain of the user. For information on enabling the domain picker, see [Enable domain selection menus in Core UI](https://www.servicenow.com/docs/access?context=t_EnableDomainReferencePickerProperty&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). Once the item is created in a specific domain, all future edits to the item are done in that domain itself. If a catalog item is published using Item Designer, the domain of the item is the domain selected in the domain picker while publishing the item. Once the item is published, it can only be modified and re-published in the domain it was originally published in. Catalog items are domain separated as data. Only for maintenance and administration, the visibility of the catalog items follows the data domain hierarchy rules. For information on domain separation hierarchies, see [Domain separation hierarchies](https://www.servicenow.com/docs/access?context=bp-domain-sep-hierarchies&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). User criteria associated with a catalog item must be visible in the domain of the catalog item. If not visible, catalog item is considered to be not associated with that user criteria. ## Visibility of catalog items - Item request flow {#domain-separation-service-catalog-management__section_hzz_23l_33b} The catalog item created in a specific domain is available in the browse, search, and request experience only in that domain and not available in the peer domains, child domains, and parent domains irrespective of the hierarchy and visibility of the domains. So, requesters can only request for items in their domain as well as in the global domain. For users with access to multiple domains (for example, IT fulfiller), the items are available for request based on the domain selected in the domain picker. To view or request an item of a specific domain, the user should switch to that domain. For information on enabling the domain picker, see [Enable domain selection menus in Core UI](https://www.servicenow.com/docs/access?context=t_EnableDomainReferencePickerProperty&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). When a requester submits a request using an order guide which has items from multiple domains, only the items in the effective domain and the global domain are ordered. The target records such as requests, requested items, or records created by record producers are created in the effective domain. ## Request fulfilment flow and reporting for a domain-separated catalog item {#domain-separation-service-catalog-management__section_pjs_r3l_33b} The target records such as requests, requested items, or records created by record producers can be accessed by a fulfiller who has visibility to the domain that the record has been generated in. For information on visibility in domain hierarchies, see [Visibility domains and Contains domains](https://www.servicenow.com/docs/access?context=c_DomainVisibility&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). Even when the fulfiller modifies the requested item from a domain other than the requested item's domain, the modifications are recorded in the target record's domain. Since the target records are separated as data, the reports retrieve data based on the effective domain of the user requesting the report. ## Request flow by a fulfiller from a different domain {#domain-separation-service-catalog-management__section_mb4_y3l_33b} When a fulfiller creates a request from a parent record such as an incident in Agent Workspace or in ServiceNow AI Platform, the fulfiller can only request for an item from the parent record's domain or from the global domain. Also, the corresponding target records are created in the parent record's domain. Note: Items from multiple domains cannot be added to the cart. ## Catalog client scripts and catalog UI policies {#domain-separation-service-catalog-management__section_k51_2jl_33b} Since the catalog client scripts and catalog UI policies are domain-separated as processes, scripts and policies in the parent domain can be overridden in the child domains. However, these scripts and policies are applicable based on the domain of the catalog item or the domain of the target record. For example, consider that A is the parent domain and B is its child domain. A catalog item in domain B is associated with a catalog client script defined in domain A. If this catalog client script is overridden in the child domain B, the overridden script in domain B is applicable while fulfilling the requested item in domain B. Even when a fulfiller from the parent domain A fulfills the requested item in the child domain B, the overridden script in domain B is applicable. Note: It is recommended to not override catalog client scripts and catalog UI policies. ## Catalog builder {#domain-separation-service-catalog-management__section_gk5_xgc_j4b} An item can only be edited in the domain that it has been created. Catalog UI policies and actions added in catalog builder are created in the same domain as that of the item. * **[Request for domain separation in Service Catalog](https://www.servicenow.com/docs/wjcgBkE6HR3ajujreXxIpw)** Enable domain separation in Service Catalog by requesting for the activation of the Service Catalog - Domain Separation plugin (com.glideapp.servicecatalog.domain_separation). **Related topics** * [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US)