---
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
---
# Explore Scripting Governance Tool
# Explore Scripting Governance Tool {#ariaid-title1}
Release version: Brazil
Updated September 10, 2026
 5 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 Explore Scripting Governance Tool
The Scripting Governance Tool, introduced in the Zurich release and updated in Brazil, centralizes control over scripting access on the ServiceNow AI Platform.
It adds a mandatory second permission layer, requiring users to be members of theConditional Script Writergroup (which grants thesncrequiredscriptwriterpermissionrole) to edit any script fields.
This governance mechanism supplements existing field-level ACLs, enabling administrators to manage scripting permissions effectively from one dashboard.
Show full answer Show less
## Why It Matters
Scripting permissions are critical because scripts can modify data across tables, bypass business logic, and alter platform behavior. Prior to this feature, administrators needed to review multiple ACLs individually to control script editing rights. The Scripting Governance Tool addresses this by enforcing a two-layer access model, simplifying oversight and enhancing security by preventing unauthorized script edits.
## Two-Layer Access Model
* **Layer 1:** User must pass the existing field-level ACL on the script field.
* **Layer 2:** User must hold the `sncrequiredscriptwriterpermission` role via membership in the Conditional Script Writer group.
Both layers are required to grant scripting access. Users who previously had access based solely on ACLs will be blocked unless they also satisfy Layer 2 after upgrading to Zurich or later.
## Data Type ACLs and Role Enforcement
The feature introduces nine deny-unless ACLs enforcing Layer 2 for various script-related data types (e.g., `script`, `scriptclient`, `htmltemplate`, etc.). Even **admin** users must meet the two-layer check and do not get automatic scripting access.
## Scheduled Jobs and Properties
To maintain group membership, two scheduled jobs operate:
* **One-time provisioning job:** Runs after the Zurich upgrade to add eligible users to the Conditional Script Writer group, preserving their scripting access.
* **Weekly update job:** Automatically adds or removes users from the group based on eligibility criteria to keep access current.
Administrators can disable automatic provisioning by setting the `glide.security.scriptingrole.autoprovisioning` property to false, allowing manual control.
## Eligibility Criteria
Users qualify for the Conditional Script Writer group if they are internal users with the `sncinternal` role plus at least one other role, and the Explicit Role plugin is enabled. External users or those with conflicting roles (`sncexternal`) cannot gain scripting access.
## Scripting Governance Tool Dashboard
This dashboard helps administrators:
* View all users with scripting access (members of Conditional Script Writer group).
* Identify which groups and roles contain the scripting permission role.
* Manually add or remove users from the Conditional Script Writer group to control scripting access.
* Scan audit logs to find users who have edited script fields over a chosen timeframe, supporting compliance and access reviews.
**Best practice:** Manage scripting access exclusively through the Conditional Script Writer group rather than assigning the permission role as a child role elsewhere, to ensure centralized and effective control.
The Scripting Governance Tool provides a single, centralised control for managing scripting access across your ServiceNow AI Platform.
The Scripting Governance Tool, introduced in the Zurich release, gives administrators centralised control over who can edit script fields on the ServiceNow AI Platform. The feature adds a new permission layer built on the Conditional Script Writer group and its child role, snc_required_script_writer_permission. Users must be
members of this group to edit any script field, regardless of their existing ACL-based access. This permission layer is enforced through data-type ACLs and maintained by scheduled jobs and system properties.
To manage this feature, ServiceNow AI Platform provides the Scripting Governance Tool --- a dashboard where administrators can see which users have scripting access, scan the instance for users who have edited script fields, and
directly add or revoke scripting access from users.
## Why it matters {#explore-sgt__why_sgt_matters}
Scripting can read and write data across tables, bypass business logic, and alter platform behaviour at a fundamental level making scripting access one of the most important permissions to govern on any instance.
Before Zurich, scripting access was controlled solely by ACLs on individual script fields. To determine which users could edit scripts, administrators had to check each ACL individually. There was no single place to view or manage
scripting access across the instance.
Scripting governance feature addresses it by adding a mandatory second layer of access control on top of existing ACL-based permissions. Satisfying a field-level ACL alone is no longer sufficient to edit a script field. Now,
security administrators can manage scripting access centrally by adding or removing users from the Conditional Script Writer group.
## The two-layer access model {#explore-sgt__two_layer_model}
Scripting governance feature enforces a two-layer access model. Both layers must pass independently before a user can edit any script field. Passing one layer alone is not sufficient.
Layer 1 --- Existing field-level ACL
: The user must pass the existing ACL on the scripting field (out-of-the-box or custom). This check is unchanged from pre-Zurich behaviour.
Layer 2 --- Scripting Governance Tool role check
: The user must also hold the snc_required_script_writer_permission role, which is granted through membership in the Conditional Script Writer group.
Important:
A user who could edit script fields before the Zurich upgrade --- because their roles satisfied the field-level ACL --- will be blocked after the upgrade unless they also satisfy Layer 2. The
`snc_required_script_writer_permission` role does not grant new scripting access on its own. It only unlocks access for users who already pass Layer 1.
The following table summarises access outcomes under the two-layer model:
{#explore-sgt__two_layer_model__entry__3}
| Passes field-level ACL (Layer 1)? | Holds `snc_required_script_writer_permission` (Layer 2)? | Can edit script field? |
|-|-|-|
| Yes | Yes | ✅ Yes |
| Yes | No | ❌ No |
| No | Yes | ❌ No |
| No | No | ❌ No |
[ ]
## Data type ACLs {#explore-sgt__section_cy4_24x_x3c}
Scripting governance feature introduces 9 data type ACLs to enforce Layer 2. These are deny unless ACLs that require the snc_required_script_writer_permission role for the following
data types:
Data type
:
* script
* script_client
* script_plain
* script_server
* email_script
* html_script
* html_template
* xml
* condition_string
{#explore-sgt__ul_q5m_m4x_x3c}
Note:
The admin role does not have scripting access by default. Admin users are subject to the same two-layer check and cannot edit script fields unless they are members of the Conditional Script Writer group or explicitly hold the snc_required_script_writer_permission role.To know more, see [Datatype ACL](https://www.servicenow.com/docs/IPxujg6cTAysc31uIKvDMQ "The datatype ACL enables you to write ACLs that apply to all fields of a specific type.").
## Scheduled jobs and properties {#explore-sgt__section_at1_w4x_x3c}
As part of the scripting governance feature, the Conditional Script Writer group is introduced, which has the snc_required_script_writer_permission role as a child role. When the Zurich
upgrade completes, a one-time scheduled job runs to auto-populate all eligible users to this group ensuring no one loses scripting access after the upgrade.
Note:
* The Conditional Script Writer group uses the Non-Assignable group type. Groups with this type can't be selected as the assignment group on task-based or incident-based records (incident, change request, problem, and other extending tables) through the UI, so the Conditional Script Writer group doesn't appear in assignment group look-ups. Existing records that already have this group set as the assignment group aren't affected.
* The Conditional Script Writer group can no longer be selected as the assignment group on any task or incident based --- through the user interface with the base system configuration.
{#explore-sgt__ul_ssm_xsw_fkc}
Once that job completes, a recurring weekly job is created to keep the group membership up to date. Both jobs and their eligibility criteria are described as follows:
Add users to Conditional Script Writer group
: A job that runs once immediately after the Zurich upgrade completes. It adds all users who meet the eligibility criteria to the Conditional Script Writer group, ensuring no user loses scripting access
after the upgrade. After the job completes, the platform disables it.
: The job uses the property glide.security.scripting_role.provisioning_job_running, which is set to true while the job is running and false after it completes. When the job finishes, it creates the
property glide.security.scripting_role.auto_provisioning and sets it to true.
Update users in Conditional Script Writer group
: A weekly job that adds new users who meet the eligibility criteria to the group and removes users who no longer meet the eligibility criteria. It is controlled by the
glide.security.scripting_role.auto_provisioning property:{#explore-sgt__table_e21_cpx_x3c__entry__2}
| Value | Behaviour |
|-|-|
| true (default) | The weekly job runs on schedule and adds qualifying users to the group automatically. |
| false | The job does not run. Users are only added to the group manually by an administrator. |
[Table 1. Update behaviour based on the property]
{#explore-sgt__table_e21_cpx_x3c}
:
To disable automatic provisioning, set glide.security.scripting_role.auto_provisioning to false in System Properties.
Note:
The glide.security.scripting_role.auto_provisioning property is created at runtime and has a different sys_id on every instance. Always reference it by a property name.
## Eligibility criteria {#explore-sgt__section_k5b_kpx_x3c}
Both scheduled jobs use the same criteria to determine which users are added to the Conditional Script Writer group:
{#explore-sgt__table_cmv_kpx_x3c__entry__4}
| Explicit Role plugin | User type | Requirement | Added to group? |
|-|-|-|-|
| Enabled | External | --- | No |
| Enabled | Internal | Must have snc_internal and at least one additional role | Yes |
| Disabled | Any user | Must have at least one role | Yes |
[Table 2. Eligibility criteria]
{#explore-sgt__table_cmv_kpx_x3c}
Note:
The snc_external role and the snc_required_script_writer_permission role are conflicting roles. ServiceNow AI Platform does not allow both role to the same user. External users cannot have scripting access.
## Scripting Governance Tool {#explore-sgt__section_m5b_kpx_x3c}
The Scripting Governance Tool is a dashboard that helps administrators manage scripting access on the ServiceNow platform. It provides visibility into users who are members of the Conditional Script Writer
group --- giving a clear picture of how many users can script on your instance.
You can also view which groups contain the scripting role and which roles contain it as a child role. There are two ways to manage scripting access through the tool:
* Manual configuration: Manually add or remove users from the Conditional Script Writer group to control who has scripting access.
* Scan for users who have scripted: Scan your instance to find users who have scripted within a specific time frame. The scan queries the audit logs and identifies any user who has performed write or update to a table having script field.
{#explore-sgt__ul_n5b_kpx_x3c}
Note:
It is recommended to manage scripting access exclusively through the Conditional Script Writer group. Adding the snc_required_script_writer_permission role as a child role to other roles or groups reduces your ability to centrally control who can script on your instance.