Introducing the Scripting Governance Tool
So, you’ve just upgraded to Zurich. You’re clicking around and find a new module: Scripting Governance Tool. You open it, and your eyes are drawn to a huge number on the dashboard: Users in Conditional Script Writer Group: 19,798 (or some other very large number).
“Wait,” you’re thinking, “I have how many scripters? I only have 30 people on my platform team!”
Let’s all take a deep breath. This is not the security issue it might first appear to be.
This does not mean all 19,798 of your end-users are suddenly writing Business Rules. To actually write code, they would still need backend access, developer roles, or admin rights to get to the configuration parts of the platform.
So, why did ServiceNow do this? In short, it’s a very broad, catch-all approach to ensure that when this new tool was activated, your existing admins and developers didn’t suddenly lose their ability to write scripts.
The problem isn’t a security fire; it’s a governance muddle. It’s a lot of noise, and it doesn’t align with the tool’s true purpose, which is to be granular and intentional.
Insights provided by:
Bjarne Steen Nielsen
Partner & ServiceNow Certified Master Architect
So, What's the Deal with This Thing?
Historically, ServiceNow’s security model was quite straightforward. If you were an “admin” of some kind (full admin or a delegated admin), you often got scripting rights by default. This created a challenge.
The core philosophy of modern platform governance is: You should only be allowed to script if you know how to script. But you can (and should) still have rights to administer parts of the system without being a coder.
This new Scripting Governance tool is ServiceNow’s answer. It introduces a much more granular role, snc_internal_script_writer_permission, to finally decouple scripting from general administration. This is a very useful idea. It’s how you safely empower citizen developers in App Engine and how you create “low-code admins” who can manage users or catalogs without ever being able to write a line of code.
The challenge? That “Auto-assignment” toggle is Active by default. A background job is actively finding all users (including all your existing admins) and dumping them into a group that grants this new scripting role. It’s ServiceNow’s “cover all bases” approach to make sure all those who have rights today get those rights again.
Our job is to refine this. We need to take that giant, over-provisioned list and pare it down to only the people who should be scripting.
Your First 5 Minutes: Stop the Noise
Defining a new governance policy and implementing it across your platformThis is the immediate fix. We need to stop the job from adding more people to this list.
Once you’re in the tool:
- Look at the “Auto-assignment” section on the main page.
- Click that Active (On) toggle.
- Confirm that it switches to Inactive (Off).
That’s it. The background job is stopped. The list is no longer growing. Now, let’s build a real governance plan.
Building Your Real Governance Plan
Stopping the job was just the first step. Now you need to establish a clear, long-term governance model. We recommend this 3-step approach.
1. Establish Your Scripting Policy
Before you change any groups, you must first define your policy: Who should be allowed to write scripts? This is a business-level decision, not a technical one.
Your policy might include:
- Core platform developers
- Approved citizen developers in your App Engine program
- Specific integration specialists
You can use the “Scan for users who have scripted” feature as a data-gathering tool. It helps you find who is scripting today, which you can then compare against your new policy to identify any gaps.
2. Implement Your Policy with Groups
Now that the auto-assignment job is off, you need to fix the group it was populating and implement your new policy.
- Build Your New Groups or assign to : Create one or more new groups that align with your policy from Step 1 (e.g., “Platform Core Scripters,” “App Engine Scripters”). Alternatively, you can use existing, well-managed developer groups if they are a perfect fit.
- Assign the Role: This is the most important part. Assign the snc_internal_script_writer_permission role directly to these new, intentional groups.
- Populate Your Groups: Add your approved scripters (identified in Step 1) into your new groups.
- Clean the Default Group: Go to the “Conditional Script Writer Group” that the tool’s dashboard pointed to. This group likely contains thousands of users. Remove all members from this group. Since you’ve already stopped the auto-assignment job, it won’t be repopulated.
Now, you have a clear, auditable system. The only people who can script are the ones in the specific groups you’ve designated, which hold the snc_internal_script_writer_permission role.
3. Continue to Monitor
Your governance is now in place, but it’s not “set it and forget it.” You must continue to monitor scripting activity. Periodically re-run the “Scan for users who have scripted” feature. This is now your primary audit tool.
The Big Picture: Why This Matters
This tool is the foundation for a modern, safe, and scalable platform. By refining this default setting, you’re not just cleaning a dashboard; you’re establishing a deliberate, mature governance strategy.
You are finally drawing a clear line between low-code admins (who can manage parts of the system), and pro-code builders (who can script). This separation of duties is critical for reducing technical debt, minimizing risk, and running your platform professionally.
Need Help Getting This Right? If you need help navigating this change, defining your scripting policies, or implementing this 3-step plan, we’re here to help.
