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 enables service providers (SPs) to configure services offered to their customers while maintaining control over critical system settings. Customers can safely manage data within their own domains that do not impact licensing or other customers, such as creating reports or managing configuration items. However, customers should not have access to customize fields, business rules, or processes that affect other tenants on the same instance.
Show less
The platform’s base administrative roles are designed for a single admin team per instance. Service providers typically assign the domainadmin role to manage domain settings and create new domains. For domain-specific administration, SPs should create tailored “customer admin” roles and access controls to grant selective permissions to their customers.
Delegation Categories
- Can give access: Safe tasks for customers include managing CI data in CMDB, creating reports, updating user data (without roles), and modifying core data records such as departments, groups, locations, and cost centers without role assignments.
- Proceed with caution:
- Catalog Items: Using domain separation for catalog items and Service Catalog, SPs can create items in customer domains and assign roles allowing customers to update certain fields like price and description. The Catalog Builder (since Quebec release) further supports safe item creation through templates.
- User/Group Management: Customers can be given “customer admin” roles to create and modify users and groups, but role assignment changes must be tightly controlled due to security and licensing implications.
- Flow Designer: Customers with the flowdesigner role can build and modify flows in their domain and read flows in parent domains. However, governance requires inclusion of these users in the global admin team to avoid conflicting processes.
- Do not give access: Customers should not have access to modify choice fields. Choice field values are stored globally across tables, domains, and languages, and changes affect the entire instance. Allowing customers to update choices risks data integrity and process failures. Additionally, choice fields cannot be updated directly in production instances due to update set overwrites.
Practical Guidance for ServiceNow Customers
Service providers should carefully design and assign customer admin roles to delegate safe operational tasks while protecting core platform configurations. Domain separation combined with role-based access controls ensures customers can manage their data safely without impacting others. Use tools like Catalog Builder and Flow Designer with governance oversight to balance customer flexibility and system integrity.
Understanding the architecture of choice fields and update behaviors is critical to avoid unintended instance-wide impacts. Restricting access to sensitive configuration elements preserves system stability in multi-tenant environments.
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: