Scripting Governance Tool: What changed in Zurich.

[Sanchita Medar]

Introduction to Scripting governance Tool 

Scripting was the most powerful access on your instance — and the hardest to audit.

A script on ServiceNow isn't just a setting you toggle. It can read and write data across any table, bypass business logic, and change how the platform behaves at a fundamental level. 

Before the Zurich release, managing that power was surprisingly hard. Scripting access was controlled by a scattered set of ACLs across individual fields — both out-of-the-box and custom. To audit who could script, you had to manually track every one of those ACLs, cross-reference role assignments, and hope nothing slipped through. Most organisations couldn't do it reliably.

The result: scripting access crept. Developers who changed teams. Admins granted access "just in case." Compliance audits got uncomfortable. Security teams started asking harder questions — and platforms couldn't easily answer them.

The Scripting Governance Tool fixes this with one centralised control. It replaces the scattered ACL model with a single group that governs scripting access across your entire instance.

Before Zurich vs. Zurich and later

Before Zurich	Zurich and Later
–  Scripting access spread across many ACLs –  No single place to see who can script –  Admin role implied scripting access –  Auditing was manual and error-prone –  No way to quickly revoke access at scale	✓ One group can controls all scripting access ✓ Instant audit: just review group membership ✓ Admin role alone no longer grants scripting access ✓ Revoke or grant access in a single action

---

What it does?

One Conditional script writer group (Consisting of snc_required_script_writer_permission role) controls scripting access.

From the Zurich release onwards, editing any scriptable field requires user to have snc_required_script_writer_permission role. Business rules, client scripts, script includes, background scripts, condition strings — all of it, covered by the same check, applied consistently across every scope.

The way it works is a two-layer check. Both must pass before a user can save to a script field:

1. Existing ACL on the script field (existing) — The role-based access check that existed before Zurich. Unchanged.
2. Access to new snc_required_script_writer_permission role (new in Zurich) — Must pass regardless of other roles held.

Passing check one alone is no longer enough. A user who had scripting access before Zurich will be blocked post-upgrade unless they have the role.

⚠ Critical — admin is not exempt. Users with the admin role are not automatically in the Conditional Script Writer group. An admin who isn't in the group cannot edit script fields. This is one of the most common post-upgrade surprises — if your admins need to write scripts, they must be explicitly added to the group.

What happens when you upgrade

ServiceNow doesn't break your instance on day one. A one-time scheduled job runs automatically during the Zurich upgrade and adds all the user with internalrole and 1 functional role to the Conditional Script Writer group. Because of this your internal developers and platform engineers retain the access that they had before the upgrade. Nothing breaks. The new control is introduced — and then it's yours to manage.

Who gets auto-provisioned?

The provisioning job applies different rules depending on whether you have the Explicit Role plugin enabled:

• Explicit Role plugin enabled: Internal users (snc_internal) with at least one functional role are added. External users are never added automatically.
• Explicit Role plugin disabled: Any user with at least one role assigned is added.

Ongoing provisioning: your most important decision

After the upgrade, the system property glide.security.scripting_role.auto_provisioning controls whether new qualifying users are added to the group automatically going forward.

Auto-provisioning ON (default): Any user who gains a qualifying role combination is automatically added to the Conditional Script Writer group. Least friction — but scripting access will grow silently with your user base unless you actively review it.

Auto-provisioning OFF — recommended for tighter control: No one is added automatically. Every scripting access grant is an explicit decision. This is the stronger security posture — scripting access becomes intentional by design. To disable, set glide.security.scripting_role.auto_provisioning to false in System Properties.

---

How to manage it?

Turn the upgrade into a governance practice, not a one-time task.

The Scripting Governance Tool is most valuable when you treat it as an ongoing access management practice — not something you configure once and forget. Here's the recommended path.

1. Audit group membership immediately after upgrade. Navigate to the Conditional Script Writer group and review everyone who was auto-provisioned. Ask: does each person here genuinely need to write or modify scripts? Developers and platform engineers — yes. Business analysts, support staff, process owners — often no.
2. Disable auto-provisioning. Set glide.security.scripting_role.auto_provisioning to false. From this point, scripting access is granted intentionally — not automatically. Establish a internal request and approval process for anyone added going forward.
3. Remove users who no longer need scripting access. Removing a user from the Conditional Script Writer group has no impact on any other access they hold on the platform. Start with users who changed roles, moved teams, or were provisioned broadly as a precaution.
4. Set a recurring review cadence. Group membership drifts. People change roles. Contractors come and go. A quarterly review of the Conditional Script Writer group is a lightweight control that keeps your posture clean and your audit story strong.
5. Use it as compliance evidence. The ability to show an auditor a single group, explain who is in it, and provide a history of how each person was added is genuinely valuable. Build your provisioning process with audit readiness in mind from the start.

Conclusion

Scripting has always been the highest-privilege action in ServiceNow. The Scripting Governance Tool makes it the most governable one too. It doesn't restrict what your developers can do — it makes sure you always know exactly who your developers are, and that the list stays accurate.

The upgrade handles continuity. The opportunity is what you do next: turn an implicit, scattered access model into a deliberate, auditable one that you can stand behind in any security review.

Servicenow Documentation on Scripting Governance tool: https://www.servicenow.com/docs/r/platform-security/access-control/scripting-governance.html