Configuration that can be delegated to internal or external customers

  • Release version: Australia
  • Updated March 12, 2026
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Configuration that can be delegated to internal or external customers

    Domain separation in ServiceNow allows service providers (SPs) to configure services offered to their customers while maintaining control over critical elements. Customers can manage data within their domain without affecting licensing or other customers, such as creating reports or managing configuration items. However, customization of fields and business rules that could impact others should remain under the SP's control.

    Show full answer Show less

    Key Features

    • Customer Management: Customers can manage certain aspects of their domain, like creating reports and updating user data, without impacting other customers.
    • Role Management: SPs should establish "customer admin" roles for domain-specific tasks while ensuring overall governance is maintained.
    • Catalog Items: Customers can create and update catalog items using domain separation and Catalog Builder, which allows safe updates to specific fields.
    • Flow Designer: Customers with the flowdesigner role can build workflows while needing governance to prevent process conflicts.
    • Choice Fields Management: Only SP admins should manage choice fields due to their complexity and impact on the entire instance.

    Key Outcomes

    By implementing these configurations, ServiceNow customers can effectively manage their domains, enhance service offerings, and ensure data integrity while minimizing risks associated with shared environments. This structure supports a balanced approach to customer empowerment and service provider oversight.

    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. Levels of access allowed for customers of service providers

    Green icon Can give access

    Examples:
    • 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.

    Yellow icon Proceed with caution

    Examples:
    • 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.

    Red icon Do not give access

    Understanding how choice fields work is helpful to understand why only the SP admin team should be managing them.
    • 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: