Avoiding domain path in scripts
Domain paths can cause the values of your script to change or even break, so don't use them in scripts.
Your script should not depend on the domain path because if you ever change the domain hierarchy, the domain path recalculates and its value changes. When this happens, your scripts are useless or can throw errors or break. The best strategy is not to write your scripts based on domain paths.
Use the sys_domain field in your scripts rather than depending on the domain path. If you ever change the domain hierarchy, the domain path recalculates and its value changes, which can cause your scripts to be useless, throw errors, or break. Look for base system business rules, which use the sys_domain field, to get some ideas before creating your own scripts.
The ServiceNow platform does not capture the sys_domain_path values in an update set in order to avoid issues with differences in the domain hierarchy for each instance. Therefore, you should validate the domain hierarchy after you import an update set to ensure that the domain path values for your records are correct.
To learn more about domain path, see Request domain separation and Domain Separation Center.
Parent Topic:Domain separation recommended practices for service providers
Related topics
Segregating and securing data with domain separation
Alternatives to domain separation
Evaluating the need for domain separation
How a database query works with domain separation
Domain separation levels of support
Service provider reference architecture
Domain-separate a custom table
Customizing domain properties and themes
Managing domain separation for specific uses
Configuring domain separation with the domain picker
Domain separation performance considerations
Checking domain logs for errors and warnings
Importance of the Default domain
Contains queries and domain access
Slow queries and SQL debugging
Domain separation and the Customer Service Management (CSM) plugin