If you’re a ServiceNow Admin, you’re very familiar with the idea of using gs.log().
It’s an extremely common scripting practice to see what the output of a value is. We use this every day in the platform and it’s incredibly helpful.
If you’re new to custom applications and working in different scope, there are a few things you’ll have to know, that will save you a ton of time when building out your applications.
If you’re in a scoped application and you’re writing a script as you normally would, consider the solution that we propose below. It’s also important to realize that when ServiceNow reaches gs.log() in a scoped application, the script will stop running and all of your work will be halted until you solve this error.
ServiceNow treats logging in custom applications differently than logging in the Global application scope. The following applies to server side JavaScript, so think Business Rules, Scheduled Jobs and Background Scripts.
Logging in Custom Applications
If you’re building a custom application, ServiceNow will not let you use gs.log() for debugging your scripts. It will throw an error in the backend and your JavaScript will stop running when the line is hit.
Instead, you have to use gs.info() or gs.debug() in a scoped application.
gs.info() and gs.debug() can be used in exactly the same manner as gs.log().
If you use gs.log() in a server side script, like this in a scoped application, you will get the following error:
Note: (This will throw an error in a custom app, don’t do this in a scoped application)
When the Business Rule is hit, when trying to render gs.log() in a scoped application, you will get this error in your system logs.
com.glide.script.fencing.MethodNotAllowedException: Function log is not allowed in scope x_232947_snowball. Use gs.debug() or gs.info() instead
Caused by error in sys_ui_action.42da42d00a0a0b340066377beb6dd099.script at line 1==> 1: (function executeRule(current, previous /*null when async*/) {
2:
3: // Print the current number
4: gs.log(current.number);
To fix this problem, if you use gs.info(current.number) in a scoped application, ServiceNow will properly render your script and you’ll then be able to see the output in the Application Log Module.
The below script will work in a scoped application. ServiceNow will successfully render the script and it will be output in the Application Logs in ServiceNow.
We’re just using gs.info(current.number) as a simple example, your use case will likely be more complex.
Remember this is not the same place where you’d normally look for a log. You specifically need to look for System Logs > Application Logs
Then the output of the number will look like this, and we get no errors:
What issues have you had with logging in a custom application scope?
Are there other tips you have for ServiceNow Admins when logging?
We’d love to hear below.
