Configuration that can be delegated to internal or external customers

  • Release version: Zurich
  • Updated July 31, 2025
  • 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 enables service providers (SPs) to configure services offered to their customers while restricting customers' ability to administer those services broadly. Customers can safely manage data within their domain that does not impact licensing or other customers, such as creating reports or managing configuration items. However, customers should not customize fields, business rules, or processes that affect other customers on the same instance.

    Show full answer Show less

    ServiceNow’s administrative roles, including domainadmin, are designed for a single SP admin team per instance. Service providers should create specific “customer admin” roles with tailored access controls to safely delegate administrative tasks to customers.

    Delegable Configuration Tasks

    • Safe for customers to manage: Configuration item (CI) data in the CMDB, report creation, updating user data (excluding roles), and managing core data records such as departments, groups, locations, and cost centers without role assignments.
    • Proceed with caution:
      • Catalog Items: Using domain separation and Service Catalog, SPs can create customer domain-specific catalog items and delegate updates to safe fields like price, description, and images. The Catalog Builder enables SPs to distribute item templates for customers to create items within their domain using a controlled interface.
      • User/Group Management: Customer admin roles can create and modify user and group records but should not manage role assignments due to security and licensing impacts. Roles require strict control by SP admins.
      • Flow Designer: Customers can use the flowdesigner role to build and modify flows in their domain without scripting, but global governance is necessary to avoid conflicts across domains.

    Non-Delegable Configuration Tasks

    Customers should not be given access to modify choice fields because of their complex structure across tables, domains, and languages. Choice fields are centrally managed by SP admins since updates overwrite all existing values and can affect processes globally. Direct modification by customers is not supported and can disrupt workflows and instance stability.

    Practical Guidance for ServiceNow Customers

    • Use domain separation to safely delegate data management tasks within customer domains without risking impact to other customers or licensing.
    • Create and apply customer-specific admin roles with carefully scoped access, avoiding delegation of sensitive controls like role management or choice field customization.
    • Leverage tools like Catalog Builder and Flow Designer to empower customers to create and manage catalog items and workflows within boundaries set by the SP admin team.
    • Maintain a global governance team to oversee process development and avoid conflicts across domains.

    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: