---
sourceDocument: Australia Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/platform-security

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Delegating configuration options to customers

# Configuration that can be delegated to internal or external customers {#ariaid-title1}

Release version: Australia  
Updated July 31, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 is designed to allow service providers (SPs) to configure services they offer to customers while restricting customers from administering those services extensively.
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 customize fields, choices, business rules, or other processes that affect multiple customers on the same instance.
Show full answer Show less  
The base system's administrative roles are intended for a single admin team per instance. The **domainadmin** role is typically assigned to SP resources to manage domain settings and creation. For domain-specific administration by customers, SPs should create custom "customer admin" roles with tailored access controls.

## Delegation Categories

### Can Give Access

* Manage Configuration Item (CI) data in the CMDB within their domain.
* Create reports.
* Update user data or add new users without roles.
* Modify core data records such as departments, groups, locations, and cost centers, provided no roles are assigned.

### Proceed with Caution

* **Catalog Items:** Using domain separation for catalog items combined with Service Catalog, SPs can create items within customer domains and assign roles to allow customers to update safe fields like price, description, and images. The Catalog Builder (introduced in Quebec release) enables SP admins to create item templates that customers can safely use to create new catalog items.
* **User/Group Management:** Customer admin roles can be created to allow user and group record creation and modification, but role assignment and removal should be tightly controlled by SPs due to security and licensing implications.
* **Flow Designer:** Customers with the **flowdesigner** role can build, read, clone, and modify flows within their domain without scripting. However, governance requires that all process-affecting users be part of the global admin team to avoid conflicts.

### Do Not Give Access

Customers should not be given access to update choice fields because changes affect the entire instance and can disrupt processes. Choice fields are stored in the **syschoice** table, organized by table, domain, and language. Updating these fields involves replacing all values, which can cause conflicts or loss of data if done by customers. Also, updates to choice fields cannot be safely applied directly in production due to potential overwriting by update sets.

## Practical Implications for ServiceNow Customers

* Service providers should limit customer access to safe areas within their domains to prevent unintentional impact on other customers or the instance.
* Custom "customer admin" roles enable controlled delegation of administrative tasks tailored to customer needs.
* SP admins must maintain governance over critical configurations such as choice fields, roles, and process workflows.
* New tools like Catalog Builder provide safer, user-friendly options for customers to manage certain configuration items.  
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 {#ds-before-you-begin__section_cb1_m43_z4b}

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.

![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.
{#ds-before-you-begin__ul_sdc_vgc_bpb}

![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](https://www.servicenow.com/docs/access?context=domain-separation-service-catalog-management&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US)) 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](https://www.servicenow.com/docs/access?context=catalog-builder&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US) (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](https://www.servicenow.com/docs/access?context=flow-designer&version=australia&pubname=australia-application-development&ft:locale=en-US): 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.
{#ds-before-you-begin__ul_gw5_2jc_bpb}

![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.

{#ds-before-you-begin__ul_zgv_wmc_bpb}

To learn more, see:

* [Exploring user administration](https://www.servicenow.com/docs/access?context=exploring-user-administration&version=australia&pubname=australia-platform-administration&ft:locale=en-US)
* [Create an ACL rule](https://www.servicenow.com/docs/Lzody1XQD2voxixQyZBrMA "Configure custom access control lists (ACLs) to secure access to new objects or to change the default security behavior.")
* [Service Provider Learning Path on ServiceNow University](https://snc.do/path)
* [Domain separation for service providers](https://snc.do/sp)
* [Service Provider Concepts](https://snc.do/spc)
* [Application Support for domain separation](https://snc.do/app)
* [Domain separation release notes](https://snc.do/rn)
{#ds-before-you-begin__ul_qdz_54c_bpb}
**Related concepts**   

* [Domain assignment](https://www.servicenow.com/docs/yQ01IIvBKxYfoM2X4nEMCQ "By default, domain separation adds a domain field to tables and their extensions.")
* [Visibility domains and Contains domains](https://www.servicenow.com/docs/aNsyfZc1uDbaap~JdLFN_w "Visibility domains control what a specific user or group of users can see. \"Contains\" domains control what an entire domain of users can see.")
* [Domain scope](https://www.servicenow.com/docs/YspDvyB0yG~KYm~VrZ~hGg "Domain scope defines what users can and cannot access.")
* [Concepts for service providers](https://www.servicenow.com/docs/L~yJ6Rwx9JF_~ImQqBNnVA "These concepts work with the existing ServiceNow platform capabilities to help you solve for common use cases.")  
**Related reference**   

* [Installed with domain separation](https://www.servicenow.com/docs/YswX2UI2_7T_JbVTg0CVig "Several platform components are added or modified with domain separation.")