Domain

What It Is

A Domain in ServiceNow is a logical container that partitions data, users, and configurations within a single instance when Domain Separation is enabled. Unlike the general IT concept of domains as network boundaries or Active Directory structures, ServiceNow domains operate entirely within the platform as virtual boundaries that control what users can see and access. Each domain maintains its own set of records, users, and administrative controls while sharing the underlying platform infrastructure, creating what's essentially multiple isolated environments within one instance.

Architecturally, domains sit at the data access layer of the ServiceNow platform, intercepting every database query and user interface rendering to enforce separation. The platform's domain engine operates through a combination of database-level filtering and application-layer controls, ensuring that users in one domain cannot accidentally or maliciously access data from another. This happens transparently — most platform functionality continues to work normally, but with an additional filter applied to scope results to the user's domain context.

The business driver for domains emerged from large enterprises needing to serve multiple business units, subsidiaries, or clients from a single ServiceNow instance while maintaining strict data isolation. Before Domain Separation, organizations faced a choice between separate instances (expensive, hard to manage) or shared instances (security and privacy concerns). Domains solve this by allowing a manufacturing conglomerate to give each subsidiary its own ITSM environment, or a managed service provider to serve multiple clients from one platform, each seeing only their own incidents, users, and configuration items.

ServiceNow built domains hierarchically because enterprises don't operate as flat structures. A parent company needs visibility into subsidiary operations, regional offices need to share some resources with headquarters, and global service desks need to escalate issues across business units. The hierarchical model mirrors real organizational structures where child domains inherit configurations, knowledge bases, and user groups from parents unless explicitly overridden. This inheritance saves massive amounts of duplicate configuration work while preserving the ability to customize at each level.

End users interact with domains passively — they log in and see only their domain's data without knowing domains exist. Domain administrators manage separation policies, user assignments, and inheritance rules, making decisions about what gets shared up or down the hierarchy. Platform developers must understand domain context because their scripts, business rules, and integrations need to respect domain boundaries or explicitly work across them. System administrators become domain architects, designing the domain tree structure and managing the complex interplay between separation and sharing that keeps the entire system functional.

Without domains, enterprises would fragment into multiple instances, creating integration nightmares, duplicate licensing costs, and operational complexity. Multi-tenant service providers couldn't exist on ServiceNow because there would be no way to safely isolate customer data. Large organizations would struggle with conflicting customization requirements between business units, and the platform's value proposition for enterprise-scale deployments would collapse. The alternative — role-based access control alone — cannot provide the complete isolation that regulatory compliance, contractual obligations, and business risk management demand.

Where It Fits in the Platform

Domains operate at the intersection of the ServiceNow security model and data architecture, functioning as a foundational layer that influences nearly every other platform component. They sit below applications like ITSM and ITOM but above the core database layer, implementing a filtering mechanism that's transparent to most platform functionality while fundamentally changing how data flows through the system. This positioning allows domains to enforce separation without requiring every application to be domain-aware, though it creates complexity when applications need to work across domain boundaries.

The domain system integrates deeply with ServiceNow's user session management, authentication, and authorization frameworks. When a user logs in, their domain context becomes part of their session state, influencing every query, report, and user interface element they encounter. This creates a cascading effect where domains impact everything from simple list views to complex workflow automations, making domain design decisions architectural choices that ripple throughout the entire implementation.

Key Relationships:

• Domain Separation: The platform feature that enables domains to function, providing the core engine and administrative interface for managing domain-based isolation.
• sys_user_group: User groups can be assigned to specific domains, controlling which users have access to domain-scoped resources and inheriting domain-specific configurations.
• Knowledge Base: Knowledge articles can be domain-scoped, allowing different domains to maintain separate knowledge repositories while optionally sharing content up the domain hierarchy.
• Business Rules and Scripts: Server-side code must account for domain context, as GlideRecord queries automatically filter by domain unless explicitly overridden with setWorkflow or domain-crossing techniques.
• CMDB: Configuration items can be domain-separated, creating isolated views of the infrastructure while allowing parent domains to see child domain CIs for enterprise-wide visibility.
• Data Sources and Imports: Import sets and transform maps must be configured to respect domain boundaries, ensuring that imported data lands in the correct domain context.

How You Encounter This in Practice

Missing Records in Reports and Lists

You're a ServiceNow developer building a custom report for executives who need visibility across multiple business units, but the report only shows data from one subsidiary. Users are complaining that incidents and requests from other divisions aren't appearing, even though you can see the data exists when you manually navigate to those records. Your carefully constructed GlideRecord queries and report definitions seem correct, but the results are inexplicably incomplete.

Understanding domains reveals that your user session is scoped to a specific domain, and all queries are automatically filtered to that domain context. The missing records exist in child or sibling domains that your current domain context cannot access. To build the cross-domain executive report, you need to either move your user to a parent domain with broader visibility, use domain-crossing query techniques like setDomainQuery(false), or aggregate data through domain-aware scripting that respects the hierarchical structure.

Without domain knowledge, you might assume there's a bug in your code or that records are actually missing, leading to unnecessary debugging sessions and frustrated executives. You might try to fix the wrong problem by modifying queries or rebuilding reports, when the real solution lies in understanding the domain hierarchy and designing your solution to work within that constraint.

Integration Failures in Multi-Domain Environments

You're a system administrator implementing an integration between ServiceNow and an external monitoring tool that needs to create incidents across multiple business units. The integration works perfectly in your development environment, but in production, incidents are only being created in one domain while alerts from other business units are failing or creating records that users can't see. The integration user has all the necessary roles and permissions, but something is still blocking the cross-domain functionality.

Understanding domains reveals that your integration user is assigned to a specific domain, limiting which records they can create and access. Even with elevated permissions, the domain context constrains the integration's scope. You need to either assign the integration user to a parent domain that encompasses all target domains, create multiple domain-specific integration users, or design the integration to dynamically switch domain context based on the incoming alert data.

Without domain awareness, you might spend days troubleshooting authentication, permissions, and API configurations when the real issue is domain assignment. The integration appears to work partially, making the problem harder to diagnose than a complete failure would be.

Configuration Inheritance Conflicts

You're a platform administrator who made what seemed like a simple configuration change to a workflow in the top-level domain, but now users in subsidiary domains are reporting that their customized approval processes have suddenly changed behavior. Some business units are seeing approval steps they didn't have before, while others have lost custom notifications that were working last week. The change you made was minor and well-tested, but its effects have cascaded unpredictably across the domain hierarchy.

Understanding domain inheritance reveals that your parent-level change overwrote child domain customizations that weren't properly protected with domain-specific overrides. Child domains inherit parent configurations by default, but this inheritance can mask or replace local customizations when parent-level changes are made. You need to audit which child domains had custom configurations, understand which changes should inherit and which should remain local, and implement proper override strategies to prevent future conflicts.

Without understanding inheritance, you might try to fix each subsidiary's issues individually, not realizing that a systematic approach to domain override management would prevent the problem. You could also make the opposite mistake — being afraid to make any parent-level changes because you don't understand how to control inheritance, leading to duplicate configuration work across domains.

What People Get Wrong

Domains create data isolation, not security isolation. They filter what users can see and access based on their domain assignment, but they're not a security boundary in the traditional sense. Users with elevated privileges or specific roles can still cross domain boundaries, view data from other domains, or escalate records between domains. Domain separation works in conjunction with the existing role-based access control system — it doesn't replace it. A user still needs appropriate roles to create incidents, approve requests, or modify configuration items, even within their own domain.

This misconception arises because domain separation feels comprehensive — users in one business unit genuinely cannot see another unit's data in normal operation. However, platform administrators, integration users, and certain system processes operate above domain boundaries by design. ServiceNow built it this way because complete isolation would break essential functions like reporting, escalations, and system maintenance. The platform needs ways to work across domains for legitimate operational reasons.

In production, this misunderstanding leads to inadequate security models where administrators assume domain separation provides complete protection and fail to implement proper role restrictions. Users might be given overly broad roles because "they can only see their domain anyway," not realizing that certain roles can bypass domain filtering. Conversely, some administrators over-compensate by creating complex role hierarchies that duplicate domain functionality, creating unnecessary complexity and performance overhead.

The real solution requires understanding domains and roles as complementary systems. Domains handle organizational isolation and data scoping, while roles control functional permissions and capabilities. A properly designed domain-separated environment uses both systems together, with domains defining who can see what data, and roles defining what actions users can perform on that data.

While ServiceNow designed the platform to make most functionality domain-aware automatically, custom code, integrations, and complex configurations often need explicit domain handling. GlideRecord queries respect domain boundaries by default, but this can break scripts that expect to see all data. Business rules might need to operate across domains for escalations or reporting. Custom applications might have features that don't make sense within domain constraints, like global dashboards or cross-organizational workflows.

This misconception exists because ServiceNow's marketing and documentation emphasize the "transparent" nature of domain separation. In simple scenarios, it genuinely works without modification — basic ITSM processes, standard reports, and out-of-box functionality typically respect domains correctly. However, the more customized and integrated your environment becomes, the more likely you are to encounter domain-related issues that require explicit handling.

In practice, this leads to implementations where domain separation is enabled without proper testing of customizations, integrations, and workflows. Scripts that worked perfectly in development suddenly produce incomplete results in production. Integrations start creating records in the wrong domains or fail entirely. Reporting becomes inconsistent as some reports respect domains while others don't. These issues often surface after go-live when it's expensive and disruptive to fix them.

The solution requires systematic testing of all customizations in a domain-separated environment before implementation. Every custom script, integration, and workflow needs to be evaluated for domain compatibility. Developers need to understand when to use domain-crossing techniques like setDomainQuery(false) or gs.getSession().setDomainScope() and when to respect domain boundaries. This isn't automatic — it requires domain-aware design and development practices throughout the implementation.

Admin vs Developer Perspective

For Admins

Admins configure domains through the sys_user_group table's u_domain field and manage user access through role assignments that respect domain boundaries. They troubleshoot issues where users can't see records they expect to access, often discovering that domain inheritance chains are broken or that ACLs aren't properly domain-aware. The critical decision admins make is determining domain hierarchy depth—going too deep creates management overhead, while too shallow doesn't provide adequate separation. Understanding that domain separation affects every table query is essential to avoid accidentally creating system-wide visibility issues when modifying domain configurations.

For Developers

Developers work with domains primarily through GlideRecord queries that automatically filter results based on the current user's domain context, unless they use setDomainQuery(false) to bypass domain restrictions. The gs.getUser().getDomainID() API returns the current user's domain, while gs.getSession().getDomainScope() reveals the active domain context for the session. Scripting patterns must account for domain inheritance when creating records—child domains can see parent domain data, but not vice versa. Developers building integrations need to understand that REST API calls respect domain separation, meaning external systems might receive different datasets depending on the authenticating user's domain.

How It Connects to Other Concepts

• Access Control Lists (ACLs) — Domain separation works in conjunction with ACLs to provide layered security, where ACLs define what operations are allowed and domains define what data is visible. When both are active, users must pass both the ACL permission check AND the domain visibility check to access records. Domain-aware ACLs can reference gs.getUser().getDomainID() in their condition scripts to create domain-specific access rules.
• GlideRecord — Every GlideRecord query automatically includes domain filtering based on the current user's domain context, effectively adding a domain condition to the WHERE clause. Developers can bypass this behavior using setDomainQuery(false) before executing the query, but this requires elevated privileges. The domain filter happens at the database level, making it transparent to most application logic but critical for understanding why queries return different results for different users.
• Business Rules — Business Rules themselves are domain-aware records that can be restricted to specific domains, but their execution context inherits the domain of the triggering record or user. When a Business Rule queries other tables using GlideRecord, those queries respect domain boundaries unless explicitly disabled. This creates subtle bugs where Business Rules work for some users but fail for others based on domain visibility, particularly in Before and After rules that validate against related records.
• Reference Fields — Reference field lookups and choice lists are filtered by domain separation, meaning users only see reference options within their domain scope. This affects the user experience significantly—a user in a child domain can reference parent domain records, but parent domain users cannot select child domain records. Reference qualifiers must account for domain inheritance patterns, and dependent choice lists can break when domain boundaries shift.
• Scheduled Jobs — Scheduled Jobs run in the context of the system user by default, which typically has global domain access, but can be configured to run as specific users with domain restrictions. Jobs that process records across domains must explicitly handle domain context switching or use setDomainQuery(false) to see all records. The domain scope affects which records are processed, making it essential to understand domain inheritance when building jobs that should work across organizational boundaries.
• Import Sets — Data imports must specify target domains during transformation, and the importing user's domain affects which existing records can be matched or updated during the import process. Transform maps can include domain logic to route imported data to appropriate domains based on field values or business rules. Import failures often occur when the import user lacks visibility to target records due to domain restrictions, making domain planning crucial for data migration projects.

Junior vs Senior Knowledge Gap

Junior developers typically treat domain separation as a simple visibility filter—they understand that users in Domain A can't see records in Domain B, but miss the inheritance hierarchy and its implications. They write scripts that work perfectly in development (usually global domain) but fail mysteriously in production when different users have different domain contexts. The most common mistake is building Business Rules or Client Scripts that assume all related records are visible, leading to null reference errors when domain boundaries block access to parent or child records. They often try to 'fix' these issues by giving users broader roles instead of understanding that the domain architecture needs to support the business logic.

The mental shift happens when someone realizes that domain separation isn't just about security—it's about data architecture that affects every query, every reference field lookup, every workflow decision, and every integration touchpoint. Experienced developers understand that domain inheritance flows one way (child can see parent, parent cannot see child) and that this creates asymmetric data relationships that must be designed for, not worked around. They know that setDomainQuery(false) is not a solution but a carefully considered exception, and they design domain hierarchies based on business processes rather than organizational charts.

Senior architects know that domain separation performance scales poorly with depth—every additional level in the hierarchy adds complexity to every query's WHERE clause, and deep hierarchies can create performance issues that don't appear until production load. They understand that domain separation and delegation often conflict, because delegated administration requires visibility across domain boundaries that domain separation restricts. They've learned that migrating data between domains requires careful planning because changing a record's domain affects all its related records and can break existing workflows, reports, and integrations.

The questions that separate experienced architects from juniors reveal deep understanding: How will domain separation affect our reporting and dashboards when users need cross-domain visibility? How do we handle shared services like knowledge bases or service catalogs that need to be visible across domains but maintained centrally? What happens to our integrations when domain context changes how much data external systems can access? How do we design approval workflows that span domain boundaries? These questions only emerge after shipping domain separation implementations and discovering that the real complexity lies in the intersections between domains and every other ServiceNow capability.

Quick Reference

• The sys_user table's domain field determines base domain access, but users can have additional domain visibility through group memberships in sys_user_group records with different domain values.
• Domain hierarchy depth beyond 3 levels creates measurable performance degradation in queries, particularly on large tables like task and cmdb_ci where domain filtering compounds with other complex conditions.
• The domain_admin role bypasses domain restrictions for all queries, but domain_scope_admin only bypasses restrictions within a specific domain hierarchy branch.
• REST API responses automatically filter results based on the authenticating user's domain context—there's no way to override this through API parameters, only through the user's domain configuration.
• Scheduled Jobs running as system can see all domains by default, but Business Rules triggered by those jobs inherit the domain context of the specific record being processed, not the global system context.
• The sys_domain table's parent field creates the hierarchy, but circular references in this field can break domain separation entirely, requiring database-level fixes to resolve.
• Choice lists on reference fields respect domain boundaries, but dependent choice lists can show inconsistent options when the controlling field's record is in a different domain than the dependent field's available options.
• Domain separation affects sys_attachment records—attachments inherit the domain of their parent record, and users can't access attachments on records outside their domain visibility even if they have the direct attachment sys_id.
• Import Set transformations must explicitly set the domain field value during record creation—if left blank, imported records inherit the domain of the importing user, which can cause unexpected visibility issues.
• The glide.sys.domain.delegated_administration system property controls whether users with admin role can administer users and groups within their domain scope, but this creates security implications that require careful role design.