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 for their customers while maintaining control over critical system elements. 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, deeper administrative tasks affecting global configurations and processes remain under the SP’s control.
Show less
Delegatable Configuration
Service providers can delegate certain administrative functions to customers by creating specific “customer admin” roles and access controls. Common safe delegated tasks include:
- Managing Configuration Item (CI) data in the CMDB
- Creating reports
- Updating user data or adding new users without roles
- Modifying core data records like departments, groups, locations, and cost centers without role assignments
For catalog items, domain separation combined with Service Catalog capabilities allows SPs to create items within customer domains and assign roles enabling customers to update safe fields such as price, description, and images. The Catalog Builder (introduced in Quebec release) provides a prescriptive UI for safe customer item creation.
User and group management can be partially delegated by creating “customer admin” roles for user creation and modification, but assigning or removing roles should remain controlled by the SP to avoid security or licensing issues.
Flow Designer access can be granted to customers for creating and modifying flows within their domain, but global governance by the SP admin team is required to avoid process conflicts.
Configurations Not Safe to Delegate
Some configurations should never be delegated to customers because changes affect the entire instance or risk stability:
- Choice fields management: Choice values are stored globally (across tables, domains, and languages) and updating them replaces all existing values, which can impact all domains. Therefore, only SP admins should manage choice fields to prevent conflicts and maintain data integrity.
- Customizing fields, business rules, and other system-wide processes that could affect other customers sharing the instance.
- Adding or removing user roles, which directly impacts security and licensing.
Practical Implications for ServiceNow Customers
ServiceNow customers using domain-separated instances can expect to safely manage domain-specific data and limited administrative tasks when delegated appropriate roles by their service provider. However, core system configurations and sensitive settings remain under the service provider’s control to ensure platform stability and security across all customers on the instance.
Service providers should carefully design “customer admin” roles and access controls to balance operational flexibility for customers with overall governance and security requirements.
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: