Domain separation and Service Level Management
Summarize
Summary of Domain separation and Service Level Management
Service Level Management (SLM) in ServiceNow supports domain separation, allowing organizations to logically group and separate data, processes, and administrative tasks by domains. This separation controls user access to domain-specific data, ensuring users see only content within their authorized domains. Domain separation is supported at a standard level, enabling multiple service provider (SP) customers to use SLM within a single instance securely and independently.
Show less
How Domain Separation Works in Service Level Management
SLM helps customers monitor and report on Service Level Agreements (SLAs), providing clear expectations and tracking when service levels are not met. SLA definitions and task SLAs include domain fields to maintain separation:
- SLA definitions must be created within a tenant domain or global domain to enable task SLAs to attach to tasks.
- Task SLAs are created in the domain of their attached task record and inherit that domain, including associated workflows.
- If a task changes domain (flips), the task SLA domain changes accordingly.
- SLA definitions from ancestor domains can be overridden in sub-domains, supporting delegated administration.
Only authorized roles (Administrator, ITIL, SLA Administrator, SLA Manager) can view SLA records, while general ESS users cannot.
Domain-Separated Tables and Use Cases
The primary domain-separated tables in SLM are:
- SLA definition [contractsla]
- Task SLA [tasksla]
Practical scenarios include:
- An ESS user in the ACME domain creates an incident that automatically attaches a task SLA in the ACME domain. The ESS user cannot view the SLA record.
- An ITIL user in the ACME domain creates an incident and can view the attached SLA record.
- An SLA Administrator can override SLA definitions from a parent domain when working in a sub-domain, enabling customized SLAs per tenant.
- An ITIL user in a sub-domain can create incidents with task SLAs based on overridden SLA definitions specific to that sub-domain.
Practical Benefits for ServiceNow Customers
By leveraging domain separation in Service Level Management, customers can securely manage multiple tenants or business units within a single ServiceNow instance, ensuring data isolation and tailored SLA configurations per domain. This capability supports scalable service delivery and governance for service providers and large enterprises with complex organizational structures.
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
- 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.
Sample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.
For more information on support levels, see Application support for domain separation.
Service Level Management overview
- 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.
How domain separation works in Service Level Management
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.
- 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-separated tables
- SLA definition [contract_sla]
- Task SLA [task_sla]
Use cases
- 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
- 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.