Before Business Rules let you validate data and set field values server-side before anything hits the database. You'll build one that catches bad data, calculates fields automatically, and handles both new records and updates properly.
Why before rules beat client-side validation
Client Scripts and UI Policies can validate data and set fields, but users can bypass them by importing data, using web services, or disabling JavaScript. Before Business Rules run server-side every time a record gets saved — no exceptions. Platform admins rely on these for data integrity that actually holds up, and developers use them for calculations that need to happen regardless of how the data arrives. Without server-side validation, your data quality depends entirely on users doing the right thing in forms.
How before rules execute and access data
Before Business Rules fire after the user submits but before ServiceNow commits the record to the database. You have access to 'current' (the record being saved with new values) and 'previous' (the record's old values from the database). The key behaviors: you can modify current.field_name to change what gets saved, use current.setAbortAction(true) to cancel the save entirely, and call current.isNewRecord() to detect inserts versus updates. On inserts, previous exists but all its fields are empty since there's no prior database record.
Building robust validation and calculations
Start with basic field validation and simple calculations. Add business logic that checks related records or enforces data relationships. Production-quality before rules handle edge cases like bulk imports, have specific conditions to avoid firing unnecessarily, and use proper error handling. Advanced implementations validate complex business rules across multiple tables, calculate sophisticated field values from related records, and provide clear error messages that help users fix problems.
Before you start
- •admin role or business_rule.create ACL access
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
Create the Business Rule record
Navigate to System Definition > Business Rules and click New. Set Name to something descriptive like 'Validate Incident Priority' or 'Calculate Total Cost'. Choose your Table — this determines which records the rule affects. Leave Active checked.
Use a naming convention that includes the table name for rules that might get cloned to other tables.
Configure when the rule fires
Check 'Before' in the When section. Set Insert to true if you want this to run on new records, Update to true for changes to existing records, or both. Most validation rules need both checked. Set a Filter Condition if the rule should only fire on specific records — use this to avoid unnecessary execution.
Always set the narrowest condition possible — rules that fire on every record update slow down your instance.
Add field-specific triggers
In the Advanced tab, set Filter Conditions if you want the rule to fire only when specific fields change. Use the condition builder to specify field values or ranges. For Update rules, check 'Field name changes' in the When tab to fire only when that field is modified, not on every update.
Write the validation logic
In the Script field, write your JavaScript. Use 'if (current.field_name == "value")' to check field values. For validation, use 'current.setAbortAction(true)' to prevent the save and 'gs.addErrorMessage("Your error text")' to show the user what went wrong. The error message appears at the top of the form.
Test your abort conditions carefully — users get frustrated when saves fail without clear error messages.
Set field values programmatically
Use 'current.field_name = "new value"' to set fields before the record saves. For reference fields, set the sys_id: 'current.assignment_group = "group_sys_id_here"'. Use current.isNewRecord() to detect inserts and set different values for new versus updated records.
Handle previous values correctly
Access old field values with 'previous.field_name' to compare what changed. Remember that on insert operations, previous fields are empty even though the previous object exists. Always check 'if (!current.isNewRecord())' before relying on previous values for comparisons.
Test and activate the rule
Set Order to 100 (default) unless you need this rule to run before or after other rules on the same table. Click Submit to save. Test with both new records and updates to existing records. Verify your validation messages appear correctly and field calculations work as expected.
Best practices
Always use current.setAbortAction(true) with gs.addErrorMessage() — aborting without a message leaves users confused about why their save failed.
Check current.isNewRecord() before accessing previous values in logic that handles both inserts and updates — previous fields are empty on new records.
Set specific Filter Conditions rather than checking conditions in code — this prevents the rule from executing unnecessarily and improves performance.
Use early returns in your script to avoid deep nesting — 'if (!condition) return;' keeps the main logic readable.
Never query the same table you're writing the rule for inside a before rule — it can cause infinite loops and performance problems.
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