Why Your Admins Can't Script Post-Zurich Upgrade: Mastering ServiceNow Scripting Governance

BillMartin · 3 weeks ago

The recent upgrade from the Yokohama to the ServiceNow Zurich release brings significant changes to platform security and administrator privileges. If you are a platform owner or administrator, you need to understand these updates to maintain proper system functionality. Crucially, the automatic scripting rights previously granted to users with the admin role are gone. This change is part of ServiceNow's initiative to enforce stronger scripting governance and improve overall platform security. This guide provides a detailed look at the new governance model and a step-by-step solution for restoring necessary scripting access to your administration team.

Understanding Security Shifts in the Zurich Release

Prior versions of ServiceNow allowed anyone with the admin role to freely create or modify scripts without additional explicit permission. This practice, while convenient, carried security risks, including the potential for unintended code execution or malicious modifications. The Zurich release addresses this by introducing script-level access controls.

The New Role of Scripting Governance

ServiceNow has implemented a strict new governance model to ensure only approved and knowledgeable users can modify system scripts. This practice is essential for maintaining platform stability, adhering to compliance standards, and mitigating risks associated with shared administration instances.

Zurich governance is managed through a central interface: the Scripting Governance Tool. This tool centralizes the management and enhancement of scripting rights into a clear, single view.

The official ServiceNow documentation provides detailed summaries of these platform security features.

You can review the specifics of this new control mechanism on the Zurich Platform Security Documentation.

Explicit Permission is Now Required

The core change is the separation of administrative rights from script-writing abilities. Even if a user has the admin role, they cannot write or execute scripts until they are granted the script writer permission.

This explicit permission is delivered through a new system role. If you search within the roles tab in User Administration, you will find this capability listed as "script writer."

ServiceNow also introduced a dedicated conditional script writer group. If you create members within this group, they automatically inherit the script writer role.

This means you must manually configure scripting access, either through the Scripting Governance Tool or directly via User Administration. This configuration ensures that only approved users modify scripts, which is a platform best practice.

Hands-On Solution: Restoring Scripting Access for Admins

If your administrators are unable to access tools like "Scripts - Background" following the upgrade, you must manually grant them the necessary permissions. The best practice is to assign the permission to the specific admin group, allowing all group members to inherit the rights simultaneously.

1. Creating a Simulated Admin Environment

To verify and implement this fix, you can simulate a post-upgrade scenario using a test user.

To start, create a new user named Clark Kent. Ensure this user is active and assign a simple email address, such as clark@atexample.com. Next, create a new group called "Admin Group" to simplify membership identification.

Once the group is created, you must assign the base admin role to the Admin Group. Clark Kent is then added as a member of this new Admin Group. This configuration grants Clark Kent all essential administrative features and capabilities through inheritance.

2. Verifying the Initial Access Restriction

Before making changes, you should confirm the security restriction is in place by testing the user's current permissions.

Take the following steps to verify:

Impersonate Clark Kent: Impersonation is a critical tool for testing and validating that a user persona has the correct rights before deploying changes to a production environment.
Attempt Script Access: Navigate to the Application Navigator on the left side of the interface, type "Scripts - Background," and attempt to click the module.

Upon attempting to access the page, you will see a security error: "Security constraints prevent him from accessing the requested page."

This confirms the new governance behavior. Clark Kent, despite being a member of the admin group and possessing the admin role, is missing the requisite explicit script writer permission.

3. Granting the Script Writer Permission to the Group

The issue is that Clark Kent, like all admins in Zurich by default, lacks the required permission. You will restore functionality by adding the script writer permission directly to the Admin Group. This ensures that every member of that group, including Clark Kent, regains scripting capability without bypassing governing controls.

Follow these configuration steps from your system administrator account:

Navigate to User Administration: Go to User Administration and find the Admin Group.
Add the Role: Drill down into the group record and go to the Roles tab.
Search and Assign: Search for the script writer role.
Save Configuration: Add the role to the group and save the changes.

By configuring the role at the group level, all current and future members of the Admin Group will automatically inherit the ability to write scripts.

4. Final Verification of Scripting Access

Now that the role has been assigned, you must re-impersonate Clark Kent to confirm the fix.

Re-impersonate Clark Kent: Switch back to the Clark Kent persona.
Access Scripts - Background: Navigate back to the Application Navigator and search for "Scripts - Background."
Execute a Test Script: Access should now be successful. To confirm functionality, run a simple test using the system log function.

For example, run the following code:

gs.info('Hello, I am Clark Kent');

If the script runs successfully, you have successfully restored security functionality and aligned your administrator configuration with Zurich’s enhanced governance model.

Implementing Governance Best Practices

This new model reinforces accountability through manual configuration, enabling tighter control over who can alter core system code. While the manual configuration is necessary at first, note that you can also enable auto-assignment. This optional feature allows ServiceNow to dynamically manage who receives the script writer permission, often based on recent scripting activity.

Benefits of Tighter Scripting Control

This configuration method serves several important purposes beyond basic access control:

Code Quality: Manual approval helps maintain high code quality across the instance.
Security: Prevents unauthorized or accidental execution of custom code.
Compliance: Supports organizational compliance requirements by tracking and limiting access to sensitive scripting functions.

In enterprise environments, this approach is particularly valuable when multiple administrators share responsibility for the instance. It gives platform owners the ability to regularly review scans, documenting who has been scripting and ensuring removals or changes are intentional before they take effect. This prevents accidental revocation of access from key users. If you need more detailed architecture guidance on setting up users, groups, and roles correctly for compliance, look for the full playlists linked on the content creator's channel.

Summary and Next Steps

You have now successfully navigated Zurich’s new scripting governance model. You learned how to:

Understand why admins no longer have automatic scripting rights post-upgrade.
Add the new script writer permission to the appropriate administrative groups.
Verify the scripting access successfully using the impersonation feature.

If this walkthrough helped you, consider joining the community as a member for exclusive content, including deep dives into the Zurich security model, updates on policy and compliance workspaces, and demonstrations of AI-powered IRM. Your support keeps essential ServiceNow tutorials flowing.

Stay tuned for upcoming videos on Zurich security enhancements, CMDB updates, and automated testing capabilities within the new release.

Nikhil Bajaj9

Hi @BillMartin ,

Very informative. Thanks.

Bchaudhary

Any new user are assigned this script role which prevents adding snc_external/snc_internal role. What will be the solution or any guidance ? Thanks

BillMartin

Hi @Bchaudhary ,

I have generated this untested response from gpt. hope it helps ☺️

The behavior you’re observing is expected and intentional in ServiceNow.
The snc_internal and snc_external roles are explicit system roles automatically managed by the platform. These roles are used to distinguish between internal ServiceNow system users and external or integration users, and cannot be manually assigned to users or groups.

When new users are automatically assigned a script role that prevents adding snc_internal or snc_external, it’s part of ServiceNow’s explicit role enforcement model — designed to protect the platform from role misuse or privilege escalation.

✅ Recommended Guidance

Do not attempt to assign snc_internal or snc_external manually.
These are system-managed roles controlled by the platform. ServiceNow automatically applies them when required, for example, to external integration accounts or system processes.
Use standard or custom roles for access control.
- For integration or API accounts, use roles such as web_service_admin, rest_service, or a scoped custom role with only the required permissions.
- For system or automation accounts, configure appropriate permissions using Application Registry credentials or MID Server service accounts.
Validate role assignment rules.
If a custom “script role” or onboarding process is automatically restricting system roles, ensure this logic is limited only to business or developer users — not to managed system accounts.
Follow ServiceNow’s Explicit Roles model.
ServiceNow enforces mutual exclusivity between these two roles:
- Internal users automatically get the snc_internal role.
- External users (like portal or integration users) automatically get the snc_external role.
- A user cannot have both, and neither should be manually edited.

📘 Documentation References

ServiceNow Documentation – Explicit Roles
https://www.servicenow.com/docs/bundle/zurich-platform-security/page/administer/contextual-security/...

Explains how snc_internal and snc_external roles are automatically assigned, their purpose, and why they cannot be manually modified.
ServiceNow Documentation – External Roles and Self-Registration
https://www.servicenow.com/docs/bundle/zurich-platform-security/page/integrate/authentication/concep...

Describes how external users are managed and restricted under the snc_external role.

💡 In Summary

This is not an error — it’s part of ServiceNow’s security design.
You should never manually assign or modify snc_internal or snc_external. Instead, use the appropriate integration roles, service accounts, or custom roles that align with your use case.

Before applying any configuration, it’s best to test in a sub-production instance and confirm behavior with your ServiceNow administrator or support contact.