--- sourceDocument: Brazil IT Service Management sourceDocumentLink: https://www.servicenow.com/docs/r/it-service-management Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil IT Service Management ft:clusterId : - itsm bundleId : - itsm workflow : - Technology --- # Domain separation and Service Level Management # Domain separation and Service Level Management {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Service Level Management Domain separation in Service Level Management (SLM) allows you to partition data, processes, and administrative tasks into distinct logical domains. This enables control over user access and visibility, supporting multiple customers or tenants within a single ServiceNow instance. SLM helps monitor, measure, and report on service level agreements (SLAs), ensuring customers receive agreed-upon service quality within defined timescales. Show full answer Show less ## Key Features * **Domain-aware application properties:** Business logic and data parameters are configured per domain, allowing customization for tenants. * **SLA definitions and task SLAs:** SLA definitions must exist in a tenant or global domain to create task SLAs. Task SLAs inherit the domain of their associated task records and follow domain-specific workflows. * **Delegated administration:** SLA definitions in parent domains can be overridden in sub-domains to meet specific tenant requirements. * **Role-based access:** SLA records are accessible only to users with specific roles (Administrator, ITIL, SLA Administrator, SLA Manager) within their domains. ## Practical Use Cases * An end-user service (ESS) user creating an incident in a tenant domain (e.g., ACME) triggers SLA attachment in that domain, but ESS users cannot view SLA records. * ITIL users with appropriate roles can view SLA records attached to incidents within their domain. * SLA Administrators can make domain-specific overrides to SLA definitions when a sub-domain's needs differ from the parent domain, with alerts generated upon changes. * When creating incidents in sub-domains, task SLAs are generated based on the sub-domain's SLA definitions. ## What This Enables You To Do With domain separation in SLM, you can effectively manage multiple tenants or business units in a single ServiceNow instance, ensuring data segregation, tailored SLA configurations, and controlled access based on user roles. This facilitates precise SLA monitoring and reporting per customer or tenant while maintaining centralized administration and flexibility for delegated customization. Domain separation is supported in Service Level Management. 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. ## Support level: Standard {#domain-separation-sla__section_v1y_wcr_xkb} * Includes all aspects of Basic level support. * Application properties are domain-aware as needed. * Business logic: The service provider (SP) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance. * The instance owner must configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application. {#domain-separation-sla__ul_tfh_drj_xkb} Sample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.{#domain-separation-sla__p_ssc_nfg_h1c} For more information on support levels, see [Application support for domain separation](https://www.servicenow.com/docs/access?context=domain-separated-apps&version=brazil&pubname=brazil-platform-security&ft:locale=en-US).{#domain-separation-sla__p_tsc_nfg_h1c} ## Service Level Management overview {#domain-separation-sla__section_pvf_wkx_vcb} * Service Level Management helps customers monitor, measure, and report on agreed service level agreements (SLAs); SLA definitions encapsulate these agreements. * Users can see only content in the domain to which they have access. {#domain-separation-sla__ul_wcr_p35_ndb} ## How domain separation works in Service Level Management {#domain-separation-sla__section_ydt_kth_scb} The intention of SLM is to provide customers with an expectation of service within a known timescale and the ability to monitor when service levels are not being met. To learn specific terms and definitions see [Service Level Management concepts](https://www.servicenow.com/docs/EJAKZdvEHMa7ALGJLB6gHg "The ServiceNow Service Level Management (SLM) application facilitates you to oversee and control the services within the organization."). * SLA definitions and task SLAs have domain fields. However, task SLAs are created only in the domain of its attached task record. * SLA definitions must be defined in a tenant domain (or global) in order for task SLAs to be created and attached to a given task (or extensions). * Task SLAs attach to a task if an SLA definition exists in the task records domain or in an ancestor domain. * Task SLAs always inherit the domain of its attached task record, which includes the workflow running on the task SLA record. If a task record ever flips, the task SLA also slips. * If an SLA definition exists in an ancestor's domain, the definition can be overridden in a sub-domain (delegated administration). {#domain-separation-sla__ul_xvf_bj5_ndb} ## Service Level Management domain-separated tables {#domain-separation-sla__section_j1q_mnh_qdb} * SLA definition \[contract_sla\] * Task SLA \[task_sla\] {#domain-separation-sla__ul_wqh_xk5_ndb} ## Service Level Management use cases {#domain-separation-sla__section_hym_nnh_qdb} * An ESS user in the ACME domain logs in and creates an incident, at which point an SLA is attached. The SLA is created in the domain of the associated task record (incident), which is the ACME domain. The ESS user is not able to read SLA records. These are restricted to the following roles: * Administrator * ITIL * SLA Administrator * SLA Manager {#domain-separation-sla__ul_hyj_3l5_ndb} * An ITIL user in the Acme domain logs in and creates an incident. The process above is the same except that the ITIL user can read the SLA record attached to the incident. * If an SLA definition exists in the Acme domain and doesn't meet the needs of an Acme sub-domain (Acme child) an SLA Administrator can remediate. SLA Administrators can navigate to the ACME SLA definition when their session domain is ACME child, make the relevant changes, and save them. The SLA Administrator is alerted that an override has been created. * An ITIL user sets the session domain to Acme child and creates an incident. The task SLA is created using the SLA definition from Acme child. {#domain-separation-sla__ul_v32_hl5_ndb} **Related topics** * [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=brazil&pubname=brazil-platform-security&ft:locale=en-US)