{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":1865,"path":"application-development/ba-domain-separation.md","title":"Domain separation and Build Agent","bundle":null,"doc_type":null,"release":"australia","body":"\n# Domain separation and Build Agent\n\nDomain 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.\n\nBuild 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.\n\nBuild 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.\n\n## How domain separation works in Build Agent\n\nDomain separation configuration occurs at two layers.\n\n-   **Instance level**\n\n    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.\n\n-   **Application level**\n\n    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.\n\n-   **ServiceNow Fluent SDK level**\n\n    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.\n\n\nBuild Agent supports creating the following in a domain-separated environment.\n\n-   Tables that inherit domain separation when they extend a domain-separated parent table\n-   Business rules and scripts that run within the domain context of the current session\n-   Fluent SDK records and APIs that set the `sys_domain` field and use `sys_override` fields in domain-separated environments\n\nThe following general guidelines apply to data model behavior when working with Build Agent:\n\n-   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.\n-   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.\n-   Reference fields that point to a domain-separated table display only records visible in the current domain.\n\n## Roles and responsibilities\n\nThe following roles and responsibilities apply when administering domain separation for applications that Build Agent creates.\n\n-   **Instance owner**\n    -   Controls which domains can access the application, configures domain-default field values.\n    -   Manages domain-specific overrides for business rules.\n    -   Determines which business logic applies globally vs. per domain.\n-   **Tenant domain administrator**\n    -   Creates, updates, and deletes records within their domain and any child domains.\n    -   Configures domain-specific values such as categories, assignment groups, and approval workflows.\n    -   Can't modify application metadata including business rules, access control lists, or table structure unless the application explicitly permits it.\n\n## Special conditions\n\nBuild Agent domain separation support includes the following conditions and exceptions.\n\n-   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.\n-   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.\n-   Metadata created in global scope is visible across all domains by default. Scoped applications provide better domain isolation.\n-   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.\n\n**Parent Topic:**[Build Agent reference](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/build-agent-reference-landing.md)\n\n**Related topics**  \n\n\n[Domain separation for service providers](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/domain-sep-landing-page.md)\n\n"}}