Client Scripts

Validate Form Input with an onSubmit Client Script

Form validation stops users from submitting incomplete or invalid records and guides them to fix problems before they become data quality issues. This guide shows you how to build validation that blocks submission and shows clear error messages.

Why client-side validation matters

Without validation, users submit forms with missing required information, invalid data combinations, or values that break downstream processes. By the time server-side validation catches these issues, the user experience is poor — they've already clicked submit and now have to figure out what went wrong. Platform admins spend time cleaning up bad data, and business users lose confidence in the system when their submissions fail silently or with cryptic messages.

How onSubmit validation works

OnSubmit client scripts run when a user tries to save a form, before the data goes to the server. Return false from the script function and ServiceNow cancels the submission. Use g_form.addErrorMessage() to show page-level errors that apply to the whole record, or g_form.showFieldMsg() to highlight specific fields that need attention. The script runs in the user's browser, so it's fast and provides immediate feedback without a server round trip.

Building robust validation

Start with basic field checks — required values, format validation, and simple business rules. Add cross-field validation for data that depends on other fields, like date ranges or conditional requirements. For production use, include clear error messages that tell users exactly what to fix, and remember that onSubmit scripts don't fire when records are created or updated via server-side GlideRecord operations — you'll need server-side validation too for complete coverage.

Before you start

  • admin role or elevated privileges to create client scripts
Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Step by step

1

Navigate to Client Scripts

Go to System Definition > Client Scripts. Click New to create a new client script record. The Client Scripts module is where all form-based JavaScript lives — this includes onChange, onLoad, onCellEdit, and onSubmit scripts.

2

Configure the script basics

Set Name to something descriptive like 'Validate Incident Fields'. Choose your Table from the dropdown — this determines which forms the script runs on. Set Type to 'onSubmit'. Leave UI Type as 'Desktop' unless you specifically need mobile-only validation.

TIP

Use naming conventions that include the table and validation purpose — you'll thank yourself when debugging later.

3

Write the validation function

In the Script field, write a function that checks your conditions and returns false to block submission. Start with 'function onSubmit() {' and end with '}'. Inside the function, use g_form.getValue() to check field values. If validation fails, show an error message and return false.

4

Add error messaging

Use g_form.addErrorMessage('Your error text here') for general validation errors that apply to the whole form. For field-specific errors, use g_form.showFieldMsg('field_name', 'Error message', 'error'). The third parameter 'error' makes the message appear in red — use 'info' for informational messages.

TIP

Clear the previous field messages with g_form.hideFieldMsg('field_name') before showing new ones to avoid stacking multiple error messages.

5

Set the condition

In the Condition field, specify when this script should be active. Use conditions like 'state=1' to only validate new records, or leave blank to run on all form submissions. The condition uses the same syntax as list filters — field names, operators, and values.

6

Test the validation

Save the client script and open a form for your target table. Try to submit the form with invalid data — you should see your error messages and the form should not save. Test both valid and invalid scenarios to make sure the script behaves correctly in all cases.

7

Handle the success case

Make sure your validation function returns true (or doesn't return anything) when validation passes. If you always return false, the form will never save. Structure your script so it only returns false when validation actually fails.

Best practices

  • Always return false explicitly when validation fails — don't rely on implicit returns or the form will still submit.

  • Use g_form.showFieldMsg() for field-specific errors instead of generic page messages — users need to know exactly which fields to fix.

  • Remember that onSubmit scripts don't fire for server-side GlideRecord operations, so duplicate critical validation in Business Rules or before query Business Rules.

  • Keep validation logic simple and fast — complex database queries in client scripts create a poor user experience.

  • Test edge cases like empty fields, null values, and users with different roles who might see different field configurations.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue