While watching this video by the venerable Jace Benson, I was inspired by an idea presented around the 4-minute mark: a more effective way to manage instance-specific System Properties. So inspired was I, that I decided to not only adopt his suggestion, but to write a little tool to handle it for me as well! I call this tool "Local Properties". 'Local', here meaning "instance-specific"; properties which should have one value in one instance (such as your dev environment), and a different value in a different instance (such as production).

As many developers will know all too well, this is a problem that we face often: How do you use one property value in one instance and another value in another instance, without risking poisoning the data in the higher instance just by modifying the value in a lower instance (and perhaps not even realizing that it's been captured in your update set)?

In this article, we're going to discuss the idea that Jace presented to solve this problem in a robust and elegant way, as well as a free tool that I've built to handle this for you!

Your ServiceNow instance DEFINITELY has DANGEROUS CODE executing in it RIGHT NOW, causing performance issues, unexpected behavior, and hiding records from people who should be able to see them (including you)!

This isn't a fear-mongering tactic; it's a fact we all overlook - until it's too late.

In this article, we'll unveil the top five quick and efficient methods to uncover this concealed, risky, and performance-degrading code in your instance. But that's not all - we'll also shed light on other lurking risks that could be silently sabotaging your instance's performance or security - even as you read this!

“My ACL requires a given role. A user has that role, but is still failing the access check. The ACL debugger says that the ACL script is what’s failing, but my ACL is not “Advanced” and there’s no script field! What is going on??”

Even when the "Advanced" checkbox is unchecked on your ACLs or Business Rules, the code in the "Script" field is still executing and it is still impacting the behavior of the ACL/BR (and impacting system performance and security)!

In this article, we’ll discuss an issue with “Advanced” ACLs and Business Rules (or non-advanced ones that behave as though they’re advanced/scripted).
This confounding behavior can very often lead to odd, unexpected, and nearly-impossible-to-troubleshoot behavior in the ServiceNow platform.

At the bottom of the article, you’ll find a free tool to solve these problems, and provide a better experience for developers and administrators in your instance!

Imagine you start creating an ACL (or a Business Rule for that matter). You begin by checking the Advanced checkbox, and writing some code to check if certain conditions are met. If so, your code then checks if the user has some specific role.

Before you even finish writing your script, let alone optimizing it, you smack your forehead and realize that you can just use the condition builder and a simple role-check for this ACL. No script necessary!
So, you set the condition field, add a role to the ACL, and un-check the Advanced checkbox.
The “Script” field disappears from the form, and you’re back to looking at a simple ACL, configured exactly as you wanted it.
All done, right?

Bad news, chum. Un-checking that checkbox did precisely nothing, aside from hiding the Script field. That script is still going to execute every time your ACL is triggered! This can have massive, detrimental impact on system stability, security, and performance…