First ask where the logic must run
Business Rule
Server-side script triggered by record display, insert, update, delete or query conditions. Use it when logic must work beyond one form interface.
Client Script
Client-side JavaScript for onLoad, onChange, onSubmit or onCellEdit behavior when the browser must respond immediately.
UI Policy
Declarative form behavior that makes fields mandatory, visible or read-only. Prefer it over scripting when it can express the requirement.
Business Rule timing changes the outcome
- Before: validate or set values before the database operation.
- After: act after the record operation when related work depends on the change.
- Async: run later without making the user wait for non-immediate work.
- Display: prepare server data for a form, often through
g_scratchpad.
Performance: prefer client data, use g_scratchpad for data known at load time, or asynchronous GlideAjax when the client requests data later.
Scenario-based choices
Close notes become mandatory when State is Closed
Use a UI Policy for immediate form behavior. If records can close through imports, APIs or lists, add a server-side control so the rule applies outside the form.
Calculate a value for every record source
Use a Business Rule or suitable server automation. A Client Script alone will not run for imported records.
Show a tailored message after a complex field change
Use an onChange Client Script when custom browser logic goes beyond mandatory, visibility or read-only actions. Avoid unnecessary server calls.
Troubleshooting sequence
- Reproduce the correct channel: form, list, workspace, portal, import or API.
- Identify client or server execution and inspect the correct logs.
- Check table, inheritance, view, scope and UI Type.
- Check Business Rule timing/order, Client Script type and UI Policy order.
- Find conflicting controls that write the same field.
- Test bypass paths before considering integrity complete.
Common CSA mistakes
- Treating Client Scripts or UI Policies as security controls.
- Assuming form logic runs for imports, APIs and list editing.
- Writing a Client Script when a simple UI Policy is clearer.
- Using a Business Rule for immediate form feedback without considering the round trip.
- Running heavy synchronous lookups during form interaction.
- Ignoring interface compatibility and UI Type.
Fast decision rule
Server operation or cross-channel enforcement: Business Rule or appropriate server control. Custom form interaction: Client Script. Mandatory, visible or read-only form behavior: UI Policy first.
Official ServiceNow references
Frequently asked questions
What is the key difference between a Business Rule and a Client Script?
A Business Rule runs on the server for record or query operations. A Client Script runs in a supported client interface and reacts to form loading, field changes, submission or onCellEdit list editing.
When should I choose a UI Policy?
Use a UI Policy for declarative form behavior such as making fields visible, mandatory or read-only. ServiceNow recommends UI Policies where possible because they require less script and can load faster.
Can a Client Script enforce data integrity for imports and APIs?
No. Most Client Scripts and UI Policies apply to forms and can be bypassed by imports, APIs or server processes. Use an appropriate server-side control when integrity must apply across channels.
Should Business Rules handle every process automation?
No. Current ServiceNow guidance describes Business Rules as a classic scripting solution and recommends Workflow Studio for new process automation where an extensible flow is appropriate.