Context and domain separation

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    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 Context and domain separation

    Context and domain separation in ServiceNow define how a user’s session determines accessible processes, data, and user interface (UI) elements. This context is shaped by user profiles, groups, company criteria, business rules, workflows, and domain settings. It governs what data and UI modules a user can see and interact with, ensuring data segregation across domains.

    Show full answer Show less

    User Session Context

    A user’s session context begins with their home domain, typically aligned with their company’s domain, as set by the system administrator on the user record. When users log in, the domain picker automatically selects their home domain, which they can change to any child domain within their session context. The session context includes the home domain, child domains, and the global domain, limiting database queries to data within these domains.

    The context affects not only interactive users but also service accounts used for integrations, applying domain constraints to database queries to maintain security and data segregation.

    Record Context

    When users access specific records, the record context activates, determining applicable UI elements and processes based on the record’s domain. Record context persists even if users change their session domain and supports concurrent record views in multiple browser tabs with independent contexts.

    Practical Importance for ServiceNow Customers

    • Ensures secure and appropriate data access by restricting visibility and operations to defined domains and their hierarchies.
    • Supports multi-domain organizations by allowing users to work within their home domain and related child domains seamlessly.
    • Enables controlled integration behavior through domain-aware service accounts.
    • Maintains consistent UI and process behavior tied to domain-specific records.

    Related Configuration and Management Topics

    For effective use and customization of domain separation, customers should explore configuring domain properties and themes, managing domain separation for specific use cases, setting up domain hierarchies, handling performance considerations, and troubleshooting using domain logs. Understanding domain assignments, domain paths query methods, and best practices for avoiding domain path issues in scripts is also essential.

    The context of a user's session determines the processes, data, and user interface (UI) as the user browses through list views, home pages, reports, and knowledge articles. The context is determined by the processes that you create, the business rules that you set, your workflows, and other factors.

    User session context

    Many factors determine the context of a user session, such as user profiles, groups, company criteria, and so on. In the following diagram, you see that the incidents that a company has created are part of the context.

    User session context

    The user in this example has a home domain of Cloud Dimensions.

    1. The branding reflects the settings in the Cloud Dimensions domain and company record.
    2. The application navigator shows the items that are inherited from higher-level domains as well as the modules that are defined in the Cloud Dimensions domain.
    3. The home pages and list data reflect the data that is visible to the user. This data is based on the user’s session context. In this case, the user in the Cloud Dimensions domain can see the data in Cloud Dimensions, child domains, and the global domain.

    User session context starts in the home domain

    In the following diagram, you can see the elements of the context.

    User session context home domain

    The system administrator sets users' home domains on their user records. Typically, a user’s home domain is set to the same domain as their company’s domain. When the user logs in, the domain picker sets automatically to the user’s home domain. Users can return to their home domain at any time by clicking the arrow icon on the domain picker.

    The domain picker's list includes domains within the user’s session context. Users may further limit their session context by selecting child domains with the picker.

    The context of the user session includes the user's home domain and any child domains. This set of domains in the user’s session context is appended automatically to every query that is sent to the database. That way, the results are limited to just the data in these domains and global data. This process is embedded in the compiled code that is not accessible.

    Service accounts that are used for integrations also have user session context. There is user context and records context, each with its own data in its own domain. These contexts affect the integrations. Database queries (records) are limited in the same way as interactive users (users), meaning that they work as normal but are limited by whatever constraints the developer has configured.

    You can learn about additional ways to add domains to a user’s session context in Service provider reference architecture.

    Record context

    As a user drills into individual records, record context is activated. The record context determines the UI elements and processes to apply to the record.

    A record’s domain dictates the process, data, and the availability of UI elements within the record.
    Note:
    • Record context persists even if the user's domain changes.
    • Users can view records concurrently in multiple browser tabs, while maintaining their own record context.

    Record context