Domain Support in Applications
About 17% of the CIS-SP exam — see all 6 domains.
ServiceNow publishes an Application support for domain separation reference that lists each application's level:
- No support: the domain field may exist, but no logic manages the data. Not considered domain-separated.
- Basic (customer data management): data goes into the proper domain, and the UI, reports, cache keys, and aggregations consider the domain.
- Standard (customer process management): includes Basic. The service provider can create or modify processes per customer.
- Enhanced (customer self-managed configuration): includes Basic and Standard. Tenants configure defined business logic themselves through fail-safe UI.
- An asterisk (for example Standard*) marks effective domain support: the use cases are met even though the domain framework is not used in the standard way.
Examples from the Zurich reference and application pages:
- Incident, Problem, Service Catalog, Knowledge Management, Notifications, CMDB: Standard. Change Management: Basic (change properties are global). Workflow and Workflow Studio: Standard*. Service Portal: No support. Check the reference for every other application, because levels change by release.
- Service Catalog needs the Service Catalog - Domain Separation plugin (com.glideapp.servicecatalog.domain_separation). Catalog items, record producers, content items, and order guides are separated as data; catalogs, categories, and variables are not and stay global. An item is requestable only in its own domain; shared items go in global and are restricted with user criteria. Catalog client scripts and catalog UI policies are process-separated (the docs recommend not overriding them).
- Knowledge Management: knowledge bases, articles, user criteria, and templates are separated. Child-domain users read articles in their own domain and global (given read access), not their parent's.
- Service Portal: portals, pages, and widgets are not separated, but record data inside widgets follows the user's domain. Create separate portals with unique URLs for different tenant experiences.
- Customer Service Management: with the csm_auto_account_domain_generation property, each new account creates a domain under TOP (a sub-domain of its parent account); without it, new accounts go to the Default domain.
- Data in a table with no domain field behaves globally, even when it is written from a domain-separated application.
Sample questions from this domain
Three of the 51 in this domain, with the reasoning. The full set is in the question bank.
What does an application's 'domain support level' indicate?
- A. Which domains an application is installed in, from global down to the leaf customer domains.
- B. How far an application supports domain separation use cases, from No support to Enhanced. ✓
- C. Which domain separation plugin edition the application requires, from Basic to Enhanced.
- D. How many Domain Separation Center audits the application passes, from none to every audit.
Why: Support levels describe, from the perspective of actual use cases, how far an application supports domain separation: No support, Basic (customer data management), Standard (customer process management), or Enhanced (customer self-managed configuration), with an asterisk marking effective domain support. Applications are not installed per domain. There is one domain separation plugin, not editions named after the levels. Domain Separation Center audits check an instance's configuration and are unrelated to an application's documented level.
Why is it important to check the domain support level of an application before relying on domain separation for it?
- A. Because the support level determines how many customer domains the application can be activated in on one instance.
- B. Because not all applications fully support domain separation, and some may have limited or no support, affecting data/process isolation. ✓
- C. Because an application's support level must match the single instance-wide level that is chosen when the domain separation plugin is activated.
- D. Because applications below the Enhanced level store all of their records in the global domain, whatever the user's domain.
Why: Applications differ in how completely they support domain separation, from No support through Basic, Standard, and Enhanced, so checking the level tells you whether data and process isolation will behave as expected. Levels do not cap how many domains can use an application. There is no instance-wide level picked at plugin activation; each application has its own documented level. Basic and Standard applications do separate data, so records are not forced to global below Enhanced.
Where can administrators review the documented domain separation support level of every application in one place?
- A. The Domain Separation Center audit dashboard
- B. The Domain Separated Tables list for each application table
- C. The "Application support for domain separation" reference ✓
- D. The application's row in the Domain Override Viewer
Why: ServiceNow publishes a single Application support for domain separation reference that lists each application's level (No support, Basic, Standard, or Enhanced). The Domain Separation Center configures and runs domain audits and does not show support levels. Domain Separated Tables lists the tables that have a sys_domain column or a domain_master attribute, which is not the same as a documented support level. The Domain Override Viewer lists tables and records that have process overrides.