--- sourceDocument: Brazil Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Domain scope # Domain scope {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 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 scope Domain scope in ServiceNow defines the data and process access boundaries for users within a domain-separated instance. Each user operates with two domain scopes during a session: thesession scope, which is initially set to the user's domain, and therecord scope, which is determined by the domain of the record being viewed. By default, record scope overrides session scope to enforce domain-specific data constraints, but users with appropriate roles can toggle between these scopes to expand or restrict visible data across domains. Show full answer Show less ## Key Features * **Session and Record Scope:** Session scope sets the user's domain context on login, while record scope reflects the domain of the current record, ensuring users see only relevant data. * **Domain Scope Toggle:** Users assigned the `domainexpandscope` role can switch between viewing data limited to the record's domain or expanded to their session and child domains using the Toggle Domain Scope UI action. * **Cross-Domain Record Value Selection:** Users with access to multiple domains can select reference values (e.g., users in "Assigned to" fields) from domains other than the record's, without changing the record's domain itself. * **Domain and Company Association:** Users are automatically placed in the domain matching their company. Changing a company's domain cascades updates to associated records like locations, departments, groups, and users. * **Domain Deactivation:** Deactivating a domain automatically deactivates all companies within it and blocks users assigned to those companies from logging in, safeguarding access control. ## Practical Implications for ServiceNow Customers Understanding domain scope helps you enforce strict data segregation in domain-separated instances, critical for multi-tenant or service provider environments. You can: * Control and customize user access to data across parent and child domains easily. * Enable users to toggle visibility to broaden or narrow their data views based on role and need. * Maintain data integrity by ensuring that record domains remain consistent even when cross-domain references are selected. * Automatically align user and company domains to simplify administration and ensure consistent access rights. * Manage domain lifecycle effectively, including deactivation processes that protect your instance from unauthorized access. These capabilities support robust domain separation governance, helping you meet security, compliance, and operational requirements in complex multi-domain ServiceNow deployments. Domain scope defines what users can and cannot access. Every user has two domain scopes when establishing a session in a domain-separated instance. * Session scope is set upon session establishment to the domain listed in the user's user record. Users can manually change their session domain scope from the domain picker. * Record scope uses the domain of the record and is active when viewing the form of any record. {#c_DomainScope__ul_oj3_f3h_1r} By default, the record scope takes precedence over the session scope so that users in higher level domains adhere to each record's data and process constraints. However, these users can choose to expand or collapse the domain scope to show or hide data from other domains. For example, a user in the Service Provider (SP) domain also has visibility into child domains such as the ACME domain. When looking at an incident record from the ACME domain, the user can choose to expand the domain scope to show values from the SP domain or collapse the domain scope to show only record values that match the record's ACME domain. Note: Users always have access to data from domains that have been explicitly granted to them by domain visibility. Users with the domain_expand_scope user role can select the domain scope from the Toggle Domain Scope UI action on the form. When record scope is in effect, click the UI action to expand to session scope and display all data available based to the user's domain and child domains. When session scope is in effect, click the UI action to collapse to record scope and display only data that matches the current record's domain. Note: A record does not display the UI action to toggle the domain scope if the record is in the global domain or if the user's domain matches the record's domain. ## Record value selection from other domains {#c_DomainScope__section_hjn_gg4_2cb} Users who can see multiple domains have the option to select record values from a domain that is different than the record's domain. For example, service desk agents working for a service provider might want to assign certain incidents to themselves to resolve issues on behalf of their customers. When they do this, the incident Assigned to field might contain a user from the SP domain, even though the incident record itself is associated with a child domain such as ACME. Selecting a record value from another domain does not change the record's domain. The record retains its original domain. When a user views a record with values from multiple domains, the user's domain visibility determines what they see. {#c_DomainScope__table_lnm_z3h_1r__entry__2} | When these conditions are met | The user has access to these UI elements | |-|-| | The user has access to the domain of the current record referenced in a field. | The user can: * See reference field display value. For example, sees the user name in the Assigned to field. * See the related record from reference icon. For example, sees the user record for the user in the Assigned to field. * Select values from any visible domain. For example, can select users from either the SP and ACME domains. {#c_DomainScope__ul_t45_cjh_1r} | | The user does not have access to the domain of the current record referenced in a field. | The user can: * Not see reference field display values. (This is the case if domain separation was activated in Madrid or later releases and the user doesn't have access to the domain of that record.) * Only select values from the record's domain. For example, can only select users from the ACME domain. {#c_DomainScope__ul_ljf_djh_1r} | [Table 1. Record value selection] {#c_DomainScope__table_lnm_z3h_1r} ## Domains and associated companies {#c_DomainScope__section_kms_pg4_2cb} With domain separation you can cascade changes you make to a company record to the domain and other records associated to the company. By default, the system automatically assigns users to the same domain as their company. For example, all users of the ACME company automatically become members of the TOP/ACME domain. Note: Users with the admin role can change their own user records and therefore change domains. Service Providers may want to either disable delegated administration or set up an approval process to verify that the user needs the admin role. When you change a company's domain, the instance automatically changes the domain of the following associated records to match the company's new domain. * Locations * Departments * Groups * Users {#c_DomainScope__ul_vxh_kd4_1r} Note: The instance does not automatically change the domain of any record where you have selected the Managed domain checkbox. ## Domain deactivation and associated companies {#c_DomainScope__section_erv_4h4_2cb} When you deactivate a domain, the instance also automatically completes the following actions. * Deactivates all companies in the domain. * Prevents all users assigned to the inactive company from logging in. {#c_DomainScope__ul_i3b_53c_mz} Note: When a user from an inactive company attempts to log in, the user sees an error message similar to Company inactive - your access to this instance is not authorized. For example, if you deactivate the ACME domain from the sample data, the instance also deactivates the ACME company, and the three sample users are locked out. **Related concepts** * [Configuration that can be delegated to internal or external customers](https://www.servicenow.com/docs/Mp8o~IR9AtSIl~_kTGUiBA "Domain separation is designed to give ServiceNow service providers (SPs) the ability to configure the services they offer to their customers. It is not designed to enable their customers to administer those services themselves, except in a few areas that this topic details.") * [Domain assignment](https://www.servicenow.com/docs/J66J2mxUsC2s95mCkolidQ "By default, domain separation adds a domain field to tables and their extensions.") * [Visibility domains and Contains domains](https://www.servicenow.com/docs/UnR3ZJZLsyXqWaCTa4g4sQ "Visibility domains control what a specific user or group of users can see. \"Contains\" domains control what an entire domain of users can see.") * [Concepts for service providers](https://www.servicenow.com/docs/IYy0bbVZtzPNgbE9vncLxA "These concepts work with the existing ServiceNow platform capabilities to help you solve for common use cases.") **Related reference** * [Installed with domain separation](https://www.servicenow.com/docs/pxc3Zy8HzF0PHGAfucU3hA "Several platform components are added or modified with domain separation.")