CSM Domain Separation: Case Domain Assignmen

[EnriqueC]

Hello ServiceNow Community,

We are working with ServiceNow Customer Service Management (CSM) in a domain-separated environment and need guidance on automatically assigning Cases to the appropriate domain.

Environment

For illustration, assume the following domain structure:

• Parent Domain (TOP): A domain from which certain agents operate.
• Domain Customers A: A customer associated with one domain.
• Domain Customers B: A different customer associated with another domain.

Agents may have visibility into customer records across domains, depending on the configured access and visibility rules.

In our implementation, a Service ID represents a customer telecommunications service, such as a DID (Direct Inward Dialing), Broadband, or Dedicated Internet Access (DIA). A service may also contain or be associated with network components such as an access point, switch, or SD-WAN device.

A Case can be associated with both an Account and a Service ID.

Requirement

When a user creates a Case, the system must determine the appropriate target domain based on the associated Account and Service ID, regardless of the user's active domain.

This behavior must be consistent across the following entry points:

1. Account
2. Service ID
3. Cases – Open Table
4. Knowledge

Users must not need to change the Domain Picker manually.

Current behavior

Our testing indicates that the resulting Case domain can vary depending on the creation method.

In some scenarios, the Case inherits the user's active domain, even when the associated Account or Service ID belongs to another customer domain. In other scenarios, the Case is created in the expected customer domain.

Questions

1. What is the recommended, supported approach to determine the Case's sys_domain from the associated Account and Service ID?
2. How should the system handle situations where the Account and Service ID indicate different target domains?
3. At what point in the record creation lifecycle should the target domain be determined to ensure that the Case is inserted into the correct domain?
4. How can this behavior be implemented consistently across all four creation entry points?
5. Are there any out-of-the-box CSM capabilities or Domain Separation limitations that should be considered before implementing a customization?

We would appreciate recommendations on the supported architecture, relevant documentation, or implementation examples.

Thank you for your help.

[abirakundu23]

Hello  @EnriqueC ,

Please follow document: https://www.servicenow.com/docs/r/yokohama/customer-service-management/domain-separation-customer-se...

Please find the answer of the following questios:

1. What is the recommended, supported approach to determine the Case's sys_domain from the associated Account and Service ID?

->  Check whether the Case is expected to inherit its domain from the associated Account in your ServiceNow release. Also verify how the Service ID relationship is handled.

2. How should the system handle situations where the Account and Service ID indicate different target domains?

-> If the Account and Service ID belong to different domains, define an explicit business rule. Avoid silently choosing one domain; validate the relationship and reject or flag inconsistent data.


3. At what point in the record creation lifecycle should the target domain be determined to ensure that the Case is inserted into the correct domain?

-> Your configuration should be present in correct target domain . 

4. How can this behavior be implemented consistently across all four creation entry points?

->

Test Case creation from the Account, Service ID, Cases list, and Knowledge. Ensure the same server-side validation applies regardless of the UI entry point.


5. Are there any out-of-the-box CSM capabilities or Domain Separation limitations that should be considered before implementing a customization?

-> There is no OOB CSM Domain separation limitation.

Please mark helpful & correct answer if it's worthy for you.

[fknell]

Hi @EnriqueC,

You might need to build plenty of workflow, because it's not only about where the records are created. All the configuration data, I-base, products, etc., sits in the customer domain.

All I have seen is a simplified version for agents belonging to the service provider using 'New Call' to capture the skeleton with the requested for and company from the target domain. The record has been injected with the correct domain scope of the caller, and the agent was forwarded into the child record (case, incident, service request) for completion. 

For everything else, the users working on multiple domains have to work in the domain, manually switch into the target domain, and process records there.

Attached systems you can control by using a user/account from the intended domain scope.

Hope this helps!

[Kailash Bhange]

Hi @EnriqueC,

What you are seeing is expected platform behaviour. In CSM with domain separation, the design is one account = one domain, and related records such as contacts and cases are meant to live in the account's domain. But at the platform level, a new record's domain comes from one of several sources (a business rule, the module/sysparm_domain, a template, the parent record, the user's domain), and if none of them applies, the record falls back to the domain of the user who creates it. Some of your entry points hit that fallback, especially when the Account is not populated at the moment of insert.

The most reliable way to get the same result everywhere is to decide the domain on the server, at insert time, in one place:

1. Create one before-insert business rule on the Case table (sn_customerservice_case)
- When: before, Insert (and optionally Update when Account or Service ID changes)
- Order: high (e.g. 1000) so it runs after OOB rules that default the account from the contact/consumer
- Condition: Account is not empty OR Service ID is not empty

2. Resolve the target domain in a clear order of precedence, for example:

(function executeRule(current, previous) {
var accDomain = current.account.nil() ? '' : current.account.sys_domain.toString();
var svcDomain = current.u_service_id.nil() ? '' : current.u_service_id.sys_domain.toString(); // your Service ID field

if (accDomain && svcDomain && accDomain != svcDomain) {
// Account and Service ID disagree - decide your rule here (see point 3)
current.setAbortAction(true);
gs.addErrorMessage('The selected Service ID does not belong to this account.');
return;
}
var target = accDomain || svcDomain;
if (target)
current.sys_domain = target;
})(current, previous);

No current.update() is needed (it is a before rule), and because it runs server-side it applies to Account, Service ID, Cases > New, Knowledge, Agent Workspace, portal, APIs and inbound email in exactly the same way. The user's Domain Picker no longer matters.

3. Account vs Service ID mismatch
I'd treat this as a data-quality problem rather than something to resolve silently. Two common options:
- Prevent it upfront: add a reference qualifier on the Service ID field so it only shows services that belong to the selected Account (and auto-fill Account from Service ID when the agent starts from the service).
- Enforce it on save: abort the insert as in the sample above. Only let one side win (e.g. Service ID over Account) if a service can legitimately be delivered to a customer from another domain, and if so document that rule.

4. Entry points
With the business rule in place, you don't need separate logic per entry point. Just make sure each entry point sets Account and/or Service ID before the record is saved (e.g. the Create Case action from Account/Service ID passes the reference, and from Knowledge or the open Cases list the agent selects the contact/account before saving). If Account can be empty on insert, derive it from the contact's account or from the Service ID's account first in the same rule.

5. Things to check before customizing
- Make sure CSM domain separation is set up the documented way: account domains created (csm_auto_account_domain_generation, enabled through ServiceNow Support) and agents/managers assigned to the TOP domain so they can see across customer domains.
- Child records (case tasks, etc.) inherit from the parent, so fixing the case domain also fixes those.
- Avoid hard-coding domain paths or sys_ids in scripts. Always read the domain from the referenced record.
- Test as a non-admin agent whose own domain is TOP, so you can confirm the case lands in the customer domain and is still visible to that agent after save.

I'd also keep the logic in a single rule (or a Script Include called by it) so it's easy to review during upgrades.

If this helps, please mark it helpful or accept it as the solution so others can find it.

[sanjaygupta]

I would recommend a centralized Before Insert Business Rule on sn_customerservice_case to handle domain assignment consistently across all Case creation entry points.

• Use the Account's sys_domain as the primary source.

• Retrieve the Account domain before Case insertion.

• Validate the Service ID domain against the Account domain.

• If both domains differ, reject the creation or route it for review.

• Check the csm_auto_account_domain_generation property.

• Test all four entry points, including integrations and scripted inserts.

Standard CSM domain assignment is Account-driven. Service ID-based assignment may require customization depending on your table configuration.

Avoid modifying out-of-box Domain Separation Business Rules. Test your customization in a sub-production instance first.

Hope you find this helpful.