Client scripts that should only run when editing existing records will slow down form loads and cause validation errors when they fire during record creation. This guide shows you how to add the proper checks to prevent scripts from running on new records.
Why client scripts fire on new records
By default, onChange and onLoad client scripts run on every form interaction — whether you're creating a new record or editing an existing one. This causes problems when your script assumes data that only exists on saved records, like checking related list counts, validating against existing field values, or making server calls that depend on a sys_id. The people who build these scripts — admins and developers — often write them while testing on existing records, then discover they break the 'New' experience when users start creating records.
How ServiceNow determines new records
ServiceNow considers a record 'new' when there's no sys_id in the URL. The g_form.isNewRecord() API checks for this condition and returns true until the record gets its first save. For onChange scripts specifically, ServiceNow provides a simpler approach — the 'Is New Record' condition in the Condition field that handles this check automatically without requiring code. The choice between these methods depends on whether you want the logic in your script or the condition field.
Building robust new record detection
After you have basic new record detection working, the improvements worth making are: combining the new record check with other conditions to minimize script execution, using the condition field approach for simple cases to keep logic out of code, and adding null checks for fields that might be empty on new records even after the first save. Production-quality client scripts handle edge cases like cloned records (which aren't technically new but might lack expected data) and form reloads that can temporarily make saved records appear new.
Before you start
- •admin role or client_script_admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Open your existing client script
Navigate to System Definition > Client Scripts and find the script you want to modify. If you don't have one yet, create a new client script with Type set to onChange or onLoad and specify your target table.
For new onChange scripts, using the Condition field method in the next step is simpler than adding code.
Choose your new record detection method
For onChange scripts: scroll to the Condition field and add 'Is New Record' is 'false' — this prevents the script from running on new records without any code changes. For onLoad scripts or when you need the check inside your script logic: skip the Condition field and use the code method in the next step.
The Condition field approach is more maintainable because the logic is visible without opening the script.
Add the isNewRecord check to your script
If you chose the code approach, add this as the first line in your Script field: 'if (g_form.isNewRecord()) return;' This exits the function immediately when the record is new. Place any existing script logic below this line.
Use 'return;' not 'return false;' — you want to exit cleanly, not cancel form operations.
Test on both new and existing records
Save your client script, then test it by opening a new record form (script should not execute) and an existing record form (script should execute normally). Check the browser console for any JavaScript errors during both tests.
Test with different user roles — some users might see different field behaviors that affect your script.
Handle edge cases in your script logic
Review your script for any field references that might be null even on existing records. Add null checks using 'if (!g_form.getValue('field_name')) return;' where needed. Consider whether cloned records should be treated as new records for your use case.
Cloned records have a sys_id but might lack related record data your script depends on.
Best practices
Use the Condition field 'Is New Record' is 'false' for simple onChange scripts instead of adding code — it's more maintainable and visible to other developers.
Place g_form.isNewRecord() checks at the very beginning of your script function to avoid any processing overhead on new records.
Don't rely solely on checking if specific fields have values — users might clear required fields on existing records, breaking your assumptions.
Test your scripts in both regular forms and Service Portal — the new record detection behavior is the same, but form loading patterns differ.
When checking for related record data, combine new record detection with null checks — even existing records might have empty reference fields.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue