Client-Side Debugging Techniques in ServiceNow
Client-Side Debugging Techniques in ServiceNow
Why Is Client-Side Debugging Important?
ServiceNow is a platform that relies heavily on both server-side and client-side scripting. Client-side scripts — including Client Scripts, UI Policies, UI Actions (with client-side code), and Catalog Client Scripts — execute directly in the user's browser. When these scripts malfunction, users experience broken forms, unresponsive fields, incorrect behavior, or console errors. Understanding how to debug client-side issues is essential for any ServiceNow developer, and it is a key topic on the ServiceNow Certified Application Developer (CAD) exam.
Without proper debugging skills, developers waste significant time guessing at problems rather than systematically diagnosing them. Client-side debugging allows you to:
- Quickly identify the root cause of form behavior issues
- Validate that Client Scripts and UI Policies are executing as expected
- Inspect data being passed between the client and server (e.g., GlideAjax calls)
- Improve application quality and user experience
What Is Client-Side Debugging?
Client-side debugging refers to the process of identifying, isolating, and resolving issues in scripts and logic that run within the user's web browser. In ServiceNow, this primarily involves debugging:
1. Client Scripts (onChange, onLoad, onSubmit, onCellEdit)
2. UI Policies and their associated scripts
3. UI Actions that contain client-side code
4. Catalog Client Scripts in Service Catalog items
5. GlideAjax calls (the client-side portion)
6. UI Pages and UI Macros using Jelly or Angular
How Does Client-Side Debugging Work in ServiceNow?
There are several key tools and techniques for debugging client-side code in ServiceNow:
1. Browser Developer Tools (F12 Console)
The most fundamental debugging tool is the browser's built-in developer console (accessible via F12 in Chrome, Firefox, or Edge). Key features include:
- Console Tab: View errors, warnings, and output from console.log() statements or jslog() statements placed in your scripts.
- Sources Tab: Set breakpoints in JavaScript files to pause execution and step through code line by line.
- Network Tab: Monitor AJAX calls (especially GlideAjax requests) to see request/response payloads, HTTP status codes, and timing.
- Elements Tab: Inspect DOM elements to verify that fields are being shown, hidden, or made mandatory as expected.
2. jslog() Function
ServiceNow provides the jslog() function for client-side scripts. When JavaScript logging is enabled, messages from jslog() appear in the browser console. This is the ServiceNow-recommended way to add debug output to client scripts.
To enable JavaScript logging, navigate to the System Diagnostics > JavaScript Log and Field Watcher module, or append &sysparm_jslog=true to the URL, or use the JavaScript Log and Field Watcher from the banner frame.
3. g_form.addInfoMessage() and g_form.addErrorMessage()
These GlideForm methods can be used temporarily during development to display messages on the form, confirming that a script is running and showing variable values. While not a formal debugging tool, this technique is practical for quick validation.
4. try/catch Blocks
Wrapping client-side code in try/catch blocks helps capture and log errors gracefully rather than having scripts fail silently.
Example:
try {
var val = g_form.getValue('priority');
jslog('Priority value: ' + val);
} catch(e) {
jslog('Error in client script: ' + e.message);
}
5. JavaScript Debug (Field Watcher)
ServiceNow includes a Field Watcher utility that allows developers to monitor real-time changes to fields on a form. It shows when field values change, which scripts are modifying them, and what the old and new values are. This is extremely helpful for tracking down unexpected field behavior.
6. Debugging GlideAjax Calls
When debugging GlideAjax, use the Network tab in browser developer tools to inspect the XMLHttpRequest. Verify:
- The correct Script Include is being called
- Parameters are being passed correctly via addParam()
- The response XML/JSON contains expected data
- The callback function processes the response correctly
7. Disabling Client Scripts Temporarily
To isolate whether a client script is causing an issue, you can disable all client scripts by adding &sysparm_client_script=false to the URL. This is useful for determining if a problem is client-side or server-side.
8. JavaScript Executor
The Scripts - Background module is for server-side scripts only. For ad hoc client-side testing, developers can use the browser console directly to execute GlideForm API commands like g_form.getValue('field_name') or g_form.setValue('field_name', 'value').
Key Differences: Client-Side vs. Server-Side Debugging
- Client-side debugging uses browser tools, jslog(), and the browser console
- Server-side debugging uses gs.log(), gs.info(), gs.debug(), the Script Debugger, and System Logs
- The ServiceNow Script Debugger (with breakpoints in the platform) is for server-side scripts only — this is a common exam trick question
- jslog() is for client-side; gs.log() is for server-side
Common Client-Side Debugging Scenarios
- A Client Script is not firing → Check script type (onChange vs onLoad), verify conditions, check if the script is active, and ensure the correct table is targeted
- A field is not being set → Use jslog() to verify the script runs, check the field name (use the actual column name, not label), and inspect for JavaScript errors in the console
- GlideAjax returns unexpected results → Check the Script Include (must extend AbstractAjaxProcessor and be client-callable), verify parameter names, and inspect the Network tab
- UI Policy conflicts with Client Scripts → Understand execution order: UI Policies run after Client Scripts of the same type, and can override them
Exam Tips: Answering Questions on Client-Side Debugging Techniques
1. Know the difference between client-side and server-side debugging tools. The exam frequently tests whether you know that jslog() is client-side and gs.log() is server-side. The Script Debugger is server-side only.
2. Remember jslog() is the preferred ServiceNow method for client-side debug logging. While console.log() works, ServiceNow documentation and exam questions favor jslog().
3. Understand the JavaScript Log and Field Watcher. Know how to enable it and what it does. Questions may ask about the best way to monitor field changes on a form.
4. Know the URL parameters for debugging:
- &sysparm_jslog=true → enables JavaScript logging
- &sysparm_client_script=false → disables client scripts for troubleshooting
5. Browser Developer Tools are essential knowledge. Expect questions about using the Console tab for errors, the Network tab for AJAX calls, and the Sources tab for breakpoints.
6. Execution order matters. Know that onLoad Client Scripts run before UI Policy scripts on form load, and that UI Policies can override Client Script changes. This is a common debugging topic.
7. GlideAjax debugging is a popular exam topic. Remember that the Script Include must be set to Client Callable = true and must extend AbstractAjaxProcessor. If a GlideAjax call fails, these are the first things to check.
8. When the exam asks about the BEST approach to debug a client-side issue, the answer typically involves using browser developer tools (F12 console) and jslog() — not server-side tools like System Logs or the Script Debugger.
9. Eliminate wrong answers by category. If an answer mentions gs.log(), gs.info(), Script Debugger breakpoints, or System Logs for a client-side debugging question, it is almost certainly incorrect.
10. Practice scenario-based questions. The CAD exam often presents a scenario where something is broken and asks you to identify the best debugging approach. Think systematically: Is it a client-side or server-side issue? What tool is appropriate? What would you check first?
Summary
Client-side debugging in ServiceNow revolves around using browser developer tools, the jslog() function, the Field Watcher, and understanding the client-side API (GlideForm, GlideAjax, GlideUser). For the CAD exam, focus on distinguishing client-side from server-side debugging tools, knowing the correct URL parameters, understanding execution order, and selecting the most appropriate debugging technique for a given scenario.