Configuration that can be delegated to internal or external customers
Summarize
Summary of Configuration that can be delegated to internal or external customers
Domain separation in ServiceNow is designed to allow service providers (SPs) to configure services for their customers, but it is not intended for customers to administer these services fully. Customers can safely manage data within their own domain that does not impact licensing or other customers, such as creating reports or managing configuration items. However, customers should not customize core elements like fields, business rules, or processes that affect other customers on the same instance.
Show less
ServiceNow’s administrative roles are structured for a single admin team per instance. The domainadmin role is typically assigned to an SP resource to manage domain settings and create domains. For specific domain administration tasks, SPs should create tailored “customer admin” roles and access controls to delegate safe access to customers.
Safe Delegated Configurations
- Managing Configuration Item (CI) data in the CMDB
- Creating reports
- Updating existing user data or adding users without roles
- Modifying core data records (department, group, location, cost center) and adding new groups, departments, cost centers, or locations without roles
Configurations to Proceed With Caution
- Catalog Items: Customers can update safe fields like price, description, and images on customer-specific catalog items created by the SP. The Catalog Builder (introduced in Quebec release) enables SPs to distribute item templates for customers to create new catalog items within their domains via a guided UI.
- User and Group Management: “Customer admin” roles can be created to allow customers to create and modify users and groups, but adding or removing roles should be tightly controlled by the SP to avoid security and licensing risks.
- Flow Designer: Customers with the flowdesigner role can create and modify flows within their domain and clone flows from higher domains. However, governance by the global admin team is essential to prevent conflicting or canceling processes.
Configurations That Should Not Be Delegated
Only the SP admin team should manage choice fields due to their complex structure and impact across the entire instance. Changes to choice fields affect all tables, domains, and languages because choice values are stored collectively and updated as a whole. Allowing customers to update choices would risk breaking processes and cause inconsistencies. Furthermore, choices cannot be safely updated directly in production because update sets might overwrite changes.
Practical Implications for ServiceNow Customers
Service providers should carefully design roles and access controls to delegate only safe configuration activities to customers, ensuring that customers can manage their domain-specific data without risking interference with other customers or core system functions. Governance and oversight remain critical, especially when customers are granted capabilities to modify flows or user/group data. Understanding the limitations around choice fields and core system configurations helps maintain instance stability and security.
Domain separation is designed to give ServiceNow® service providers (SPs) the ability to configure the services they offer to their customers. It is not designed to enable their customers to administer those services themselves, except in a few areas that this topic details.
overview
It is safe for SP customers, on their own, to manage data contained within their domain that does not affect licensing or other customers. For example, it is safe for a customer to create new reports or manage configuration items, but it’s not safe for them to customize fields, choices, business rules, and other processes where they can impact other customers on the same instance.
The ServiceNow base system administrative roles and their access controls on the ServiceNow platform are designed for a single admin team per instance. For example, the domain_admin role is granted to one of the SP’s resources to manage all domain setting for the instance, and to create new domains. For any domain-specific admin tasks, the SP should create new “customer admin” roles and access controls as needed to grant specific access to their customers.
The following image is an overview of common admin functions in varying categories of what is safe for a customer to do.
Can give access
- CI data management in the CMDB
- Report creation
- Updates to existing user data, or new users without roles
- Updates to existing core data records such as department, group, location,cost center, or new groups without roles, and new departments/ cost centers/ location.
Proceed with caution
- Catalog Items: To create customer-specific catalog items that can be updated by the customer, two capabilities can be used together: Domain separation for catalog items (Domain separation and Service Catalog) enables the instance owner to create items in the customer’s domain. The instance owner can create a role to allow customers to update safe fields such as price, description, and images. The Catalog Builder (new in the Quebec release), gives the SP admin team the ability to create item templates that are safe to distribute to customers to create new items within their domain from within a prescriptive UI experience.
- User/Group Management: It’s safe to create a “customer admin” role that can create and modify user records, but adding and removing roles can affect security and licensing. There is no way in the base system to subdivide roles that are safe for a customer to be able to grant them. The same goes for the creation and modification of groups. While the group itself can be modified, the addition or subtraction of roles should be controlled.
- Flow Designer: ServiceNow Workflow Studio is the building tool used to create process (workflow) for tables. The flow_designer role gives customers script-free access to build flows. They can read and clone every flow in domains above them in the hierarchy. They can create and modify flows in their domain. This cannot happen in a silo, however. Anyone who can affect process must be added to the global admin team for governance so processes do not cancel out each other or cause other conflicts.
Do not give access
- Structure of a choice field: Choice field values are stored in the sys_choice table and grouped based on: Table, Domain, and Language.
For example, the State field in a Task is available to every table that extends a Task. That means that each table can have its own values, those values can be multiplied by domain, and the domain values can be multiplied by language.
All of the values for State across all tables, domains and languages are considered the values for the State field.
- How changes to choice fields work: When a choice field is updated, a payload is created with all values for that field (Tables, Domains, Languages). When you install this payload on an instance, all existing values for
the field are deleted and the new values are loaded. This ensures that there are no duplicate entries or leftover values that are no longer valid.
For this reason, it’s impossible to give a customer in a domain-separated instance the ability to update choice fields directly because that would affect the entire instance. In addition, you can’t update choices directly in a production instance because any imported update sets that affect that field would overwrite the existing choices. In some cases, choice fields can drive processes themselves, which would break if a customer were to change those fields.
To learn more, see: