--- sourceDocument: Brazil IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/it-operations-management Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Domain Separation and Discovery # Domain Separation and Discovery {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Discovery Domain separation in Discovery enables Service Providers (SPs) to segregate data, processes, and administrative tasks into logical domains, ensuring that users see and access only their domain-specific data. This separation supports multi-customer environments within a single ServiceNow instance, with SPs controlling the top-level domain and retaining administrative control since delegated administration to child domains is not supported for Discovery. Domain separation is supported at the Standard level, allowing domain-aware application properties and business logic customization per tenant. Show full answer Show less ## How Domain Separation Works in Discovery * A single MID Server can support multiple domains, assigning discovered Configuration Items (CIs) based on the domain of the MID Server user or the user who created the Discovery schedule. * Data domain separation is implemented by impersonating the MID Server user during sensor processing, assigning discovered data to the appropriate domain. * Discovery configuration elements such as classifiers and probes are not domain-separated. * SPs typically use IP-based Discovery, allocating distinct IP address spaces per customer domain, and may use network address translation (NAT) to handle overlapping address spaces. * Visibility and access to discovered data are controlled by the platform's domain hierarchy, with schedules visible only within respective domains, except the SP who can see all domains. ## Domain Separation for MID Server Files Specific MID Server policy records (MIB, JAR, and script files) can be versioned per domain, restricting usage to MID Servers within the same domain. By default, these records reside in the global domain but can be overridden to support domain-specific policies. Attachments on these files may not be visible across domains due to data separation. ## Supported Domain-Separated Tables All tables extending the Base Configuration Item \[cmdb\] table support domain separation. Additional supported tables include Serial Number, TCP Connection, Fibre Channel Initiator/Targets, IP Address to DNS Name, Service, KVM Virtual Device, Load Balancer VLAN components, and Switch Port records. ## Configuring Domain-Separated Discovery Schedules Configuring the "Run as" user in Discovery schedules is essential to direct discovered CIs to the correct domain, maintaining proper data isolation and domain integrity. Domain separation is supported in Discovery. 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 {#c_DiscoveryDomainSeparation__section_rxs_qvq_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. {#c_DiscoveryDomainSeparation__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.{#c_DiscoveryDomainSeparation__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=brazil&pubname=brazil-platform-security&ft:locale=en-US).{#c_DiscoveryDomainSeparation__p_tsc_nfg_h1c} ## Domain separation overview {#c_DiscoveryDomainSeparation__section_mbc_mtj_hdb} Service Providers (SPs) use domain separation to segregate data for each customer. Users in a given domain have visibility only to the data in their own domains or in child domains. SPs typically control the top-level domain, which gives them visibility to data associated with all domains. Given that Discovery domain separation support is considered Standard there is no delegated administration to the child domains. The SPs must retain administrative control. ## How domain separation works in Discovery {#c_DiscoveryDomainSeparation__section_ct2_gdy_s3b} Multiple domains can be supported by a single MID Server. In releases prior to Kingston, each MID Server could support only a single domain. In newer releases, segregating domains by MID Server is useful when the domain is large, or when the domain's resources are held in a customer's data center rather than the SP's. For Discovery on MID Servers supporting a single domain, the discovered CIs are assigned to the domain of the MID User used to authenticated against the ServiceNow instance. In multi-domain MID Servers, the discovered CIs are assigned to the domain of the user who created the Discovery schedule. Discovery implements data domain separation through the MID Server by impersonating the MID Server user during sensor processing. Discovery uses the domain, that the MID Server user is in, to determine which domain the discovered data should be put into. Discovery configuration information, including classifiers, identifiers, probes, and sensors, is not domain separated. Service providers generally use IP-based Discovery. In cases where the SP controls the network addressing, they divide the address space among their customers to ensure that each domain has a distinct IP address space. The SP assigns one or more subnets to a customer or domain and creates Discovery schedules for those subnets. If the SP is remotely managing their customer's data center, there will often be some overlap between address spaces different customers use. In these cases, the SP can use network address translation (NAT) on the IP range and run a Discovery schedule. Once the CIs are assigned to the correct domain, the visibility and read/write access control are provided by the platform through the domain hierarchy. Schedules are visible to users in their respective domains. Cross-domain schedule visibility is not possible, except for the SP who controls the parent domain and has visibility to all domains. ## Domain separation for MID Server files You can create versions of these specific MID Server policy records that only a MID Server from the same domain can use. This process separation is supported for records in tables that extend MID Server Synchronized Files \[ecc_agent_sync_file\]: * MID Server MIB File \[ecc_agent_mib\] * MID Server JAR File \[ecc_agent_jar\] * MID Server Script File \[ecc_agent_script_files\] {#c_DiscoveryDomainSeparation__ul_e25_j4x_tv} By default, all records in these tables are members of the global domain. A user can override the default global domain and create a version of these policies for use in the user's own domain. Note: Attachments on MIB or JAR file records might not appear as they did in a non-domain separated environment. The attachments don't appear because the Attachments \[sys_attachment\] table is data separated. When data is separated between domains, a record in a child domain can't access records in a parent domain. See [MID Server domain separation](https://www.servicenow.com/docs/access?context=c_MIDServerDomainSeparation&version=brazil&pubname=brazil-servicenow-platform&ft:locale=en-US) for instructions on setting up domain separation through the MID Server. ## Domain-separated tables Records in all tables that extend the Base Configuration Item \[cmdb\] table can be domain-separated. In addition, records in these tables can also be domain-separated: * Serial Number \[cmdb_serial_number\] * TCP Connection \[cmdb_tcp\] * Fibre Channel Initiator \[cmdb_fc_initiator\] * Fibre Channel Targets \[cmdb_fc_target\] * IP Address to DNS Name \[cmdb_ip_address_dns_name\] * Service \[cmdb_ip_service_ci\] * KVM Virtual Device \[cmdb_kvm_device\] * Load Balancer Service VLAN \[cmdb_lb_service_vlan\] * Load Balancer VLAN Interface \[cmdb_lb_vlan_interface\] * Switch Port \[cmdb_switch_port\] {#c_DiscoveryDomainSeparation__ul_ttt_nq1_j5} * **[Configure domain-separated Discovery schedules](https://www.servicenow.com/docs/OZrCK2dCO~xQMi6s9dd7XA)** Configuring the "Run as" user in a Discovery schedule directs discovered Configuration Items (CIs) to the correct domain and maintains data isolation. **Related concepts** * [Discovery behaviors](https://www.servicenow.com/docs/ZigXrvYAGGrlFDqQ3FIEmA "Discovery behaviors determine the probes that Shazzam launches, and from which MID Servers these probes are launched.") **Related topics** * [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=brazil&pubname=brazil-platform-security&ft:locale=en-US) * [Domain separation recommended practices for service providers](https://www.servicenow.com/docs/access?context=bp-domain-sep-recommended&version=brazil&pubname=brazil-platform-security&ft:locale=en-US)