--- sourceDocument: Australia Build or modify applications sourceDocumentLink: https://www.servicenow.com/docs/r/australia/application-development Release : - australia ft:locale : - en-US ft:publication_title : - Australia Build or modify applications ft:clusterId : - cadev bundleId : - cadev workflow : - Development, Data, and Analytics --- # Domain separation and Build Agent # Domain separation and Build Agent {#ariaid-title1} Release version: Australia Updated August 27, 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 Build Agent Domain separation is a platform-level feature in ServiceNow that enables logical grouping of data, processes, and administrative tasks into separate domains. This allows control over user access and data visibility across these domains. Build Agent supports domain separation by creating standard ServiceNow metadata, such as tables, business rules, and access control lists, that operate within this domain-separated architecture. Domain separation is configured by a ServiceNow AI Platform administrator and not directly by Build Agent. Show full answer Show less ## How Domain Separation Works with Build Agent * **Instance level:** A platform administrator activates domain separation via the Domain Support - Domain Extensions plugin and manages the domain hierarchy using Domain Admin tools. This setup is outside Build Agent's scope. * **Application level:** Build Agent generates application metadata designed to function in a domain-separated environment. Once installed, a platform administrator configures domain settings for new tables and assigns appropriate roles for domain access. * **ServiceNow Fluent SDK level:** The SDK supports setting and reading the `sysdomain` and `sysoverride` fields on records and APIs that respect domain separation, enabling domain-specific data overrides. ## Key Features * Build Agent creates tables that automatically inherit domain separation when extending domain-separated parent tables. * Business rules and scripts generated by Build Agent run within the current session's domain context. * GlideRecord queries are filtered by domain, ensuring data visibility aligns with domain permissions; cross-domain queries require elevated privileges. * Reference fields show only records visible in the current domain. * Scoped applications created by Build Agent have their own namespaces, improving domain isolation and data security. ## Roles and Responsibilities * **Instance Owner:** Manages domain access for applications, configures domain-default field values and domain-specific business rule overrides, and decides which business logic applies globally or per domain. * **Tenant Domain Administrator:** Manages records and domain-specific configurations within their domain and child domains but cannot change application metadata unless explicitly permitted. ## Special Conditions and Considerations * Build Agent cannot configure domain separation settings directly; these must be handled by a ServiceNow AI Platform administrator. * Flows created by Build Agent run in the domain context of the triggering record; cross-domain flows require additional design and administrator configuration. * Metadata created in the global scope is visible across all domains by default, while scoped applications provide stronger domain isolation. * The Fluent SDK supports domain-specific overrides through `sysoverride` without modifying base records. Domain separation is supported for Build Agent. 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. Build Agent creates standard ServiceNow metadata, such as tables, business rules, and access control lists, that participates in domain separation when domain separation is active on the instance. Domain separation is a platform-level feature configured by a ServiceNow AI Platform administrator, not by Build Agent. Build Agent creates scoped applications with their own namespace. When domain separation is active, the platform manages domain visibility of application data automatically through the `sys_domain` field. ## How domain separation works in Build Agent {#ba-domain-separation__section_qln_lzq_ljc} Domain separation configuration occurs at two layers. Instance level : A platform administrator activates the Domain Support - Domain Extensions plugin (com.glide.domain.msp_extensions) and configures the domain hierarchy through Domain Admin. The configuration is outside the scope of Build Agent. Application level : Build Agent creates the application metadata that operates within a domain-separated environment. After you install the application, a platform administrator configures domain separation settings for any new tables and assigns roles to the appropriate domains. ServiceNow Fluent SDK level : The ServiceNow Fluent SDK supports setting the `sys_domain` field directly on records and on APIs that support domain separation. You can also read and write `sys_override` fields to apply domain-specific overrides through the ServiceNow SDK. In addition to tables, you can create other metadata objects in specific domains. Build Agent supports creating the following in a domain-separated environment. * Tables that inherit domain separation when they extend a domain-separated parent table * Business rules and scripts that run within the domain context of the current session * Fluent SDK records and APIs that set the `sys_domain` field and use `sys_override` fields in domain-separated environments {#ba-domain-separation__ul_dy2_ggg_rjc} The following general guidelines apply to data model behavior when working with Build Agent: * When Build Agent creates a table that extends a base system table with `sys_domain`, for example `task` or `cmdb_ci`, the domain column is automatically inherited. Don't redeclare it. * GlideRecord queries in scripts that Build Agent creates are automatically filtered by domain. Queries that must run across domains require elevated privileges configured by a platform administrator. * Reference fields that point to a domain-separated table display only records visible in the current domain. {#ba-domain-separation__ul_pp1_1gg_rjc} ## Roles and responsibilities {#ba-domain-separation__section_ey2_ggg_rjc} The following roles and responsibilities apply when administering domain separation for applications that Build Agent creates. Instance owner : * Controls which domains can access the application, configures domain-default field values. * Manages domain-specific overrides for business rules. * Determines which business logic applies globally vs. per domain. {#ba-domain-separation__ul_wh1_3gg_rjc} Tenant domain administrator : * Creates, updates, and deletes records within their domain and any child domains. * Configures domain-specific values such as categories, assignment groups, and approval workflows. * Can't modify application metadata including business rules, access control lists, or table structure unless the application explicitly permits it. {#ba-domain-separation__ul_qzm_kgg_rjc} ## Special conditions {#ba-domain-separation__section_rln_lzq_ljc} Build Agent domain separation support includes the following conditions and exceptions. * Build Agent creates application metadata but can't configure domain separation settings directly. A ServiceNow AI Platform administrator must configure domain hierarchy, table participation, and visibility rules on the instance. * Flows that Build Agent creates execute in the domain context of the triggering record. Flows that must operate across domains, such as an escalation from a tenant domain to a global domain, require additional design and platform administrator configuration. * Metadata created in global scope is visible across all domains by default. Scoped applications provide better domain isolation. * When using the Fluent SDK, you can set `sys_domain` on records and APIs that support domain separation. The `sys_override` field is also supported, which lets you apply domain-specific field value overrides through the SDK without modifying the base record. {#ba-domain-separation__ul_gvt_ngg_rjc} **Related topics** * [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=australia&pubname=australia-platform-security&ft:locale=en-US)