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

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Process administration

# Process administration {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Process administration

Process administration enables ServiceNow administrators to define and enforce domain-specific policies within their organization.
Policies set in a lower domain override those set in higher domains, allowing for tailored configurations that respect the domain hierarchy.
This feature supports customization of client scripts, system policies, application and module names, application roles, and module filters based on domain context.
Show full answer Show less  

## Key Features

* **Domain-specific policy management:** Administrators can create or modify policies specific to their domain without altering global or higher-level domain policies. Changes in lower domains override higher-level settings.
* **Automatic override handling:** When modifying a higher-level domain policy, the system creates a new record in the administrator's current domain with the `sysoverrides` field set, indicating which higher-level policy it overrides.
* **Policy inheritance and precedence:** Policies are applied based on the domain of the record being accessed, not the user's domain. If no policies exist in the record's domain, the system searches upward through the domain hierarchy until it reaches the global domain.
* **Admin role considerations:** Users with the admin role have unrestricted access to all policies and data, regardless of domain assignments. This powerful privilege should be granted cautiously.

## Practical Application for ServiceNow Customers

As a ServiceNow customer, process administration allows you to enforce governance and customization tailored to specific business units or geographic locations represented by domains. You can safely modify policies relevant to your domain without affecting the global or parent domain configurations. When working with policies, always operate within the intended domain context to ensure proper overriding behavior and avoid accidentally modifying higher-level policies directly.

Understanding the domain-based policy hierarchy helps in troubleshooting policy application and ensures that the correct settings are enforced based on the domain of the record in question. This capability improves administrative control, supports delegated administration, and maintains policy integrity across a complex organizational structure.  
Process administration allows administrators to set domain-specific
policies.

The policies set lower in the domain hierarchy override policies set higher in the domain
hierarchy. While in a domain, administrators can set domain-specific versions of these global
policies and settings:

* Client scripts
* System policies
* Application and module names
* Application roles
* Module filters

{#c_DelegatedAdministration__ul_fnp_sjh_1r}  
Warning:  
All users with the admin role have special access to all system features, functions, and data because administrators can override ACL rules and pass all role checks. Grant this privilege carefully.

When users have the admin role, then all policies in the instance are
available to them regardless of the assigned domain. They can enter a specific domain, and then
only policies in that domain or higher are visible and processed during a relevant transaction.
When an administrator modifies a policy that is in a higher domain or the global domain, the
system automatically creates a new record for that administrator's current domain. It does not
modify the original policy, application, or module record. This new record overrides the
original.

To make changes to a policy in a lower-level domain, go into that domain and modify the policy.
This approach creates the policy record in your domain that overrides the original, higher-level
policy record.

Do not change the higher-level policy and then change the Domain field
on that policy. This approach does not create a policy record in your lower-level domain, nor
does it keep the policy record for the higher-level domain.

The sys_overrides field indicates that a policy, application, or module
at a lower level in the hierarchy overrides a record at a higher level. The system automatically
sets this field when an administrator attempts to modify a policy, application, or module that
belongs to another domain higher in the hierarchy.

Rather than changing the higher-level record, the attempted update is changed into an insert,
and the sys_overrides field is set to indicate the higher-level policy,
application, or module that is being overridden. Later when the records for a relevant
transaction are loaded, the overriding domain-specific policy, application, or module is used
instead of the original.

## Domains for process administration {#c_DelegatedAdministration__section_cfs_4cg_l1b}

By default, process administration always uses the record's domain to determine what policies
to apply.

The record's domain takes precedence over the user's domain. If there are no policies in the
record's domain, delegated administration checks for policies in the next highest level of the
domain hierarchy. The search for domain policies continues up the domain hierarchy until
reaching the global domain. If there are no domain policies lower in the domain hierarchy,
processes administration uses the policies for the global domain.

For example, Fred Luddy is a user in the Acme domain who can see records in the child domains
of Acme: Atlanta, Acme: San Diego, and Acme: NY child domains. When this user opens a record in
the Acme: San Diego domain, process administration first checks for policies in the Acme: San
Diego domain. If there are no policies at this level of the domain hierarchy, process
administration checks for policies from the Acme domain. If there are no policies in the Acme
domain, process administration uses the global domain polices as there are no other domains
higher in the domain hierarchy.

