Business rules let you automatically set field values when records are created or updated, eliminating manual data entry and ensuring consistency. You'll build a rule that populates fields based on other field values the moment someone saves a record.
Why manual field population breaks down
Without auto-population, users either leave fields blank or fill them inconsistently — and both create problems downstream. Support agents forget to set priority based on impact and urgency. Procurement requests don't get assigned to the right approver based on department. Change requests miss required documentation fields. The people affected are the downstream process owners who depend on complete, consistent data, and the admins who spend time cleaning up incomplete records after the fact.
How business rule field population works
A business rule is server-side JavaScript that runs when records are saved, and 'before' rules are your tool for setting field values. The rule fires before the record hits the database, checks conditions you specify, then sets values using current.field_name = value syntax. You can populate text fields, numbers, dates, or references — the key is understanding when to use direct assignment versus setValue() versus setReferenceValue(). Most developers start with simple text field assignments, then add reference field population and conditional logic.
Making field population production-ready
Basic auto-population works, but production-quality rules include null checks to avoid script errors, specific conditions to prevent unnecessary firing, and proper reference field handling. Advanced implementations add multiple field cascading (department sets location, location sets manager), user override detection so manual changes don't get overwritten, and performance optimization by checking if the target field already has the correct value before setting it.
Before you start
- •admin role or business_rule_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
Create the business rule record
Navigate to System Definition > Business Rules and click New. Set the Name to something descriptive like 'Auto-populate Priority from Impact and Urgency'. Choose your target Table — this is the table where records will get auto-populated fields. The Name appears in debug logs, so make it specific enough to recognize later.
Configure when the rule fires
Check 'Insert' if you want fields populated when records are created, 'Update' if you want them populated when records are modified, or both. Leave 'Delete', 'Query', and 'Display' unchecked — they don't apply to field population. Set When to 'before' because you're modifying the record that's being saved, not creating related records.
Set the trigger condition
In the Condition field, specify when this rule should fire using dot-notation. For example: current.impact.changes() || current.urgency.changes() will only trigger when those specific fields change, not on every record update. This prevents unnecessary execution and improves performance. Leave the Filter Conditions section empty unless you need complex logic that's hard to express in dot-notation.
Write the field population script
In the Script field, use current.field_name = value for most field types. For text fields: current.short_description = 'Auto-generated description'. For reference fields, use current.field_name.setReferenceValue(sys_id) to set by sys_id, or current.field_name.setValue(display_value) to set by display value. Add null checks like if (current.impact && current.urgency) before your logic to prevent script errors.
Test the rule behavior
Set Advanced to true and check 'Rest Script' if you want this rule to fire when records are created or updated via REST API calls — most field population rules should have this checked. Save the rule, then test by creating or updating a record that meets your conditions. Check that the target fields get populated and verify the rule doesn't fire when it shouldn't.
Add order and final details
Set Order to a value like 100 to control when this rule runs relative to other business rules on the same table — lower numbers run first. If your rule depends on other rules setting values first, use a higher order number. Check 'Active' to enable the rule and save the record.
Best practices
Always use .changes() in your condition to prevent the rule from firing on every update — current.impact.changes() is much more efficient than just checking current.impact.
Use current.field_name.setReferenceValue(sys_id) for reference fields when you have the sys_id, and setValue(display_value) only when you need ServiceNow to look up the sys_id from a display value.
Add null checks before accessing field values in your script — if (current.category && current.subcategory) prevents script errors when fields are empty.
Don't use current.update() inside a before business rule — the record save is already in progress and calling update() creates infinite loops.
Set a specific Order value rather than leaving it at 100 — if multiple rules modify the same record, order determines which values win.
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