To script or not to script?

For new administrators, it can be difficult to know when to script. For coders, it can be easy to look to script before you need to, with so many opportunities to write script in ServiceNow. However, it is much better to not write script wherever possible.

If you can configure instead of scripting, it should be your first thought. This allows the tool to be used in the way it was intended and will leave you much more prepared when upgrading your instance. Not only that; one of the main reasons for using configurations over customizing is for maintenance. Configurations are easily maintained by different admins, while customization's require some basic knowledge of scripts and the logic behind them, so they tend to be harder to maintain and troubleshoot. Remember, once you start to customize, maintaining that customiszation is your responsibility. 

If you find yourself unable to achieve your goals with configuration alone, then you should look to script. Even though configuration is your best option, scripting accounts for a lot of advanced functionality on most instances. Almost all mature instances will have some level of scripting done to them, but the instances that function better are the ones where scripting was performed when appropriate.

For example, if you are looking to show, hide, or make mandatory or read-only a field, then this could be done as a client script or a UI policy. If you simply needed to perform one of the actions based on a value in a field, then in this instance, a UI policy is the better choice, as it can achieve the goal without using a script. However, if you needed to perform the action based on whether the logged-in user has a particular role, then you will need to use a script. Scripting can be done in a UI policy, but I usually opt for a client script in this scenario.