ServiceNow Client Scripts vs Business Rules: When to Use Each

When you're developing in ServiceNow, one of the first architectural decisions you'll repeatedly make is:

Should this logic go in a Client Script or a Business Rule?

Both can react to changes around a record.

Both can contain JavaScript.

Both can influence what eventually happens to the data.

But they run in completely different places and solve different problems.

A Client Script runs in the user's browser and is mainly responsible for form behaviour and user interaction.

A Business Rule runs on the ServiceNow server and is responsible for record processing, validation, automation, and server-side business logic.

Choosing the wrong one can lead to:

• duplicated logic
• poor performance
• inconsistent data
• unnecessary server calls
• scripts that only work through the UI
• security or validation gaps
• difficult-to-maintain applications

In this guide, we'll look at how Client Scripts and Business Rules differ, when each should be used, and how to decide where your logic really belongs.

The Main Difference

The simplest distinction is:

Client Script

Runs in the browser.

Business Rule

Runs on the server.

That affects almost everything else.

Client Scripts are best suited to things the user experiences while interacting with a form.

Business Rules are better suited to logic that must remain correct regardless of how a record is created or updated.

For example, a Client Script might:

• make a field mandatory
• hide a field
• respond when a value changes
• prevent a form submission
• populate another field for convenience

A Business Rule might:

• calculate a value before a record is saved
• validate server-side conditions
• update related records
• trigger logic after an insert or update
• run asynchronously after the transaction

Client Scripts Run in the Browser

Client Scripts execute on the client side.

That means they run while the user is interacting with a ServiceNow form in their browser.

They have access to client-side APIs such as:

1g_form

For example:

1function onChange(
2  control,
3  oldValue,
4  newValue,
5  isLoading,
6  isTemplate,
7) {
8  if (isLoading) {
9    return
10  }
11
12  if (newValue === '1') {
13    g_form.setMandatory(
14      'comments',
15      true,
16    )
17  } else {
18    g_form.setMandatory(
19      'comments',
20      false,
21    )
22  }
23}

This script reacts immediately while the user is working with the form.

No record needs to be saved first.

Business Rules Run on the Server

Business Rules execute on the ServiceNow server.

They operate on the record during or around database transactions.

Inside a Business Rule, you'll commonly work with objects such as:

1current

and:

1previous

For example:

1(function executeRule(
2  current,
3  previous,
4) {
5  if (
6    current.priority == 1 &&
7    current.assignment_group.nil()
8  ) {
9    current.assignment_group =
10      'YOUR_GROUP_SYS_ID'
11  }
12})(current, previous)

The important difference is that this logic is not dependent on a particular user's browser form.

It runs on the server when the record operation meets the Business Rule conditions.

Why Server-Side Logic Is Important

Imagine you need to guarantee that a record always has a particular value under certain conditions.

If you only implement that logic in a Client Script, it may work when a user manually edits the form.

But records can enter ServiceNow through many other paths:

• REST APIs
• integrations
• imports
• background scripts
• Flow Designer
• server-side scripts
• scheduled jobs
• other Business Rules

Those operations may never execute your Client Script.

That means important business logic should not rely entirely on browser-side scripting.

If a rule must protect or enforce the integrity of the data, it usually needs a server-side implementation.

The Main Types of Client Scripts

ServiceNow provides several Client Script types.

The common ones are:

• onLoad
• onChange
• onSubmit
• onCellEdit

Each solves a slightly different problem.

onLoad Client Scripts

An onLoad Client Script runs when the form loads.

It can be useful for adjusting the initial form experience.

For example:

1function onLoad() {
2  if (
3    g_form.getValue(
4      'priority',
5    ) === '1'
6  ) {
7    g_form.setMandatory(
8      'comments',
9      true,
10    )
11  }
12}

Possible uses include:

• displaying information
• adjusting field visibility
• setting initial form behaviour
• responding to values already present on the record

However, simple form-state behaviour may sometimes be better implemented with a UI Policy.

onChange Client Scripts

An onChange Client Script runs when a particular field changes.

This is one of the most common Client Script types.

For example:

1function onChange(
2  control,
3  oldValue,
4  newValue,
5  isLoading,
6  isTemplate,
7) {
8  if (
9    isLoading ||
10    newValue === ''
11  ) {
12    return
13  }
14
15  if (newValue === '1') {
16    g_form.showFieldMsg(
17      'priority',
18      'Critical incidents require immediate attention.',
19      'info',
20    )
21  }
22}

This is useful when the form should respond immediately to user input.

Always Consider isLoading

A common onChange mistake is forgetting that the script may also run while the form is loading.

This can cause logic intended for user changes to run unnecessarily during initialization.

A common pattern is:

1if (isLoading) {
2  return
3}

Depending on the requirement, you may also want to ignore empty values.

For example:

1if (
2  isLoading ||
3  newValue === ''
4) {
5  return
6}

This keeps the script focused on meaningful user-driven changes.

onSubmit Client Scripts

An onSubmit Client Script runs when the user attempts to submit the form.

It can prevent submission by returning false.

For example:

1function onSubmit() {
2  const description =
3    g_form.getValue(
4      'description',
5    )
6
7  if (!description) {
8    g_form.addErrorMessage(
9      'Description is required before submitting this record.',
10    )
11
12    return false
13  }
14
15  return true
16}

This can provide a useful user experience by stopping an invalid submission before it reaches the server.

But if the rule is important for data integrity, it should not exist only on the client.

onCellEdit Client Scripts

An onCellEdit Client Script is used with list editing.

It reacts when a user changes a value directly in a list rather than opening the full form.

This is useful when your application allows list editing and you need client-side behaviour around those changes.

It is less commonly used than onLoad and onChange, but it is important to remember that not every user interaction happens through a standard form.

The Main Types of Business Rules

Business Rules commonly run as:

• Before
• After
• Async
• Display

Understanding the timing is important because each type has a different purpose.

Before Business Rules

A Before Business Rule runs before the database operation completes.

This is often the right place when you need to modify the current record before it is saved.

For example:

1(function executeRule(
2  current,
3  previous,
4) {
5  if (
6    current.short_description.nil()
7  ) {
8    current.short_description =
9      'No description provided'
10  }
11})(current, previous)

Because the Business Rule runs before the record is written, you can modify fields on current directly.

You generally do not need to call:

1current.update()

inside a normal Before Business Rule just to save changes made to the current record.

The platform will persist those changes as part of the existing transaction.

Avoid current.update() in Before Business Rules

Calling:

1current.update()

inside a Business Rule running on the same record can create unnecessary additional database activity and may contribute to recursion or unexpected behaviour.

If you're already in a Before Business Rule, simply modify current.

For example:

1current.priority = 1

and allow the original transaction to continue.

After Business Rules

An After Business Rule runs after the current record has been written to the database.

This is useful when something else needs to happen because the record changed.

For example:

• update a related record
• create another record
• trigger related processing
• perform logic that depends on the saved record

The important distinction is that the current record has already been written.

If you only need to change fields on the current record before it saves, a Before Business Rule is generally more appropriate.

Async Business Rules

Async Business Rules run asynchronously after the database operation.

This means the original transaction does not need to wait for all of the asynchronous processing to finish.

They can be useful for work that:

• does not need to complete immediately
• may take additional processing time
• should not slow down the user's transaction

Examples might include certain background processing or non-immediate follow-up actions.

However, asynchronous processing also means you should not assume the result is available immediately to the user who just saved the record.

Display Business Rules

Display Business Rules run when a record is loaded for display.

They are commonly used when server-side information needs to be made available to client-side scripts.

One important mechanism is:

1g_scratchpad

For example, a Display Business Rule might set:

1(function executeRule(
2  current,
3  previous,
4) {
5  g_scratchpad.canEscalate =
6    gs.hasRole(
7      'itil_admin',
8    )
9})(current, previous)

Then a Client Script can read:

1if (
2  g_scratchpad.canEscalate
3) {
4  // client-side behaviour
5}

This can avoid making another server call after the form has loaded.

Client Scripts Are About User Experience

A useful question is:

Does this requirement exist mainly because a person is interacting with the form?

If yes, a Client Script may be appropriate.

Examples include:

• show a message when a value changes
• clear a dependent field
• make a field mandatory for the user
• hide something based on another field
• prevent an obviously invalid manual submission
• populate a value to make data entry easier

These behaviours improve the user's interaction with the form.

Business Rules Are About Server-Side Truth

Now ask:

Must this rule remain correct even if no user opens the form?

If yes, server-side logic is usually required.

Examples include:

• enforce record values
• calculate fields before save
• validate critical conditions
• update related records
• maintain data consistency
• apply business logic from integrations
• react to database changes regardless of source

This is a major architectural distinction.

Don't Use Client Scripts as Security

Client-side logic is not a security boundary.

A Client Script can control what the UI shows or allows a user to do through that interface.

But real access protection should use mechanisms designed for security, such as Access Control Lists.

For example, hiding a field with:

1g_form.setVisible(
2  'sensitive_field',
3  false,
4)

does not mean the user is securely prevented from accessing that field's data through other mechanisms.

UI behaviour and security are different responsibilities.

Don't Use Business Rules Just to Change the Form

The opposite mistake is using a Business Rule for something that is purely presentation.

Suppose the requirement is:

Hide the Comments field when State is Closed.

That is form behaviour.

A UI Policy may be a better solution than either a Client Script or Business Rule.

Using a Business Rule simply to control what the form looks like can introduce unnecessary server-side complexity.

Sometimes the Answer Is Neither

One of the most important ServiceNow development habits is realizing that the choice is not always:

Client Script or Business Rule?

ServiceNow provides other tools designed for specific responsibilities.

Depending on the requirement, consider:

• UI Policies
• Data Policies
• Script Includes
• GlideAjax
• Flow Designer
• Access Controls
• Notifications
• Declarative configuration

Good ServiceNow development is not about using scripts everywhere.

It is about choosing the right platform capability.

Use UI Policies for Simple Form Behaviour

Suppose the requirement is:

When Category is Hardware, make the Serial Number field mandatory.

You could write an onChange Client Script.

But if the requirement is simply:

• mandatory
• visible
• read-only

a UI Policy may express that behaviour more clearly and with less custom scripting.

Client Scripts become more valuable when the client-side requirement requires logic beyond what a UI Policy handles cleanly.

Use Data Policies for Data-Level Enforcement

A UI Policy focuses on form behaviour.

A Data Policy can be useful when you need to enforce certain data requirements beyond only one browser form experience.

Depending on the configuration and use case, Data Policies can help enforce requirements across data-entry channels more consistently.

This is another reason to avoid automatically reaching for Client Scripts.

Use Script Includes for Reusable Server Logic

If several server-side scripts need the same logic, don't copy the function into multiple Business Rules.

Move reusable logic into a Script Include.

For example:

1var IncidentUtils =
2  Class.create()
3
4IncidentUtils.prototype = {
5  initialize: function() {},
6
7  isCritical:
8    function(incident) {
9      return (
10        incident.priority == 1
11      )
12    },
13
14  type: 'IncidentUtils',
15}

Then server-side callers can reuse that logic.

This keeps Business Rules smaller and prevents duplicated business logic.

Use GlideAjax When the Client Needs Server Data

A Client Script cannot directly access every piece of server-side information efficiently or safely.

When client-side behaviour needs server-side processing, GlideAjax is a common pattern.

The flow is:

Client Script
sends a request

→ Client-callable Script Include
runs server-side logic

→ response
returns to the browser

This keeps server-only logic on the server while still allowing the form to react dynamically.

Avoid Unnecessary Server Calls From Client Scripts

Every additional client-to-server request adds latency and work.

If the required information is already available on the form, use it.

If information can be prepared during form load using an appropriate mechanism such as g_scratchpad, that may be better than repeatedly requesting it afterward.

If a server call is genuinely required, use an appropriate asynchronous pattern.

The goal is responsive forms without unnecessary network traffic.

Client-Side GlideRecord Should Be Used Carefully

Developers coming from server-side scripting may be tempted to use GlideRecord-style data access from client-side code wherever possible.

In general, client-side data retrieval should be approached carefully.

Server-side logic through mechanisms such as GlideAjax often gives you better control over:

• what data is retrieved
• security
• performance
• reusable logic

Do not pull large amounts of data into the browser simply because the client needs one small answer.

Client Scripts Should Be Small

A Client Script should usually perform focused client-side behaviour.

If an onChange script grows to hundreds of lines and performs:

• several server calls
• complex business calculations
• multiple database lookups
• large amounts of form manipulation

that is a sign the responsibility may need to be redesigned.

Large client scripts can make forms harder to maintain and slower to use.

Business Rules Should Be Focused Too

The same principle applies on the server.

Avoid one enormous Business Rule that:

• validates data
• updates related records
• sends notifications
• calls integrations
• calculates metrics
• performs auditing
• creates tasks

A Business Rule should have a clear responsibility.

Complex reusable logic can move into Script Includes or another appropriate service layer.

Use Business Rule Conditions

Do not make a Business Rule run on every update if it only matters under specific circumstances.

Use:

• table conditions
• field change checks
• appropriate execution conditions

For example:

1if (
2  current.priority.changesTo(1)
3) {
4  // critical-priority logic
5}

This is much more focused than running expensive logic for every update regardless of what changed.

current and previous

Business Rules commonly provide:

1current

and:

1previous

current represents the current version of the record.

previous represents the prior version where available.

That allows logic such as:

1if (
2  current.state.changes()
3) {
4  // state changed
5}

or comparisons between old and new values.

This is one of the major strengths of server-side Business Rules.

changes(), changesTo(), and changesFrom()

ServiceNow provides useful field-change methods.

For example:

1current.state.changes()

checks whether the field changed.

1current.state.changesTo(6)

checks whether it changed to a particular value.

1current.state.changesFrom(2)

checks whether it changed from a particular value.

These can help keep update Business Rules focused on meaningful changes.

Preventing a Server-Side Operation

Sometimes the server must reject a record operation.

A Business Rule can use:

1current.setAbortAction(
2  true,
3)

along with a message such as:

1gs.addErrorMessage(
2  'This record cannot be updated in its current state.',
3)

This is much stronger than relying only on an onSubmit Client Script because the validation happens server-side.

Even if another mechanism attempts the update, the server-side rule can still protect the data.

Client Validation and Server Validation Can Work Together

Sometimes the best user experience uses both layers.

Imagine a rule says:

A closure code must be selected before an incident can be resolved.

A Client Script or UI Policy might immediately tell the user that the field is required.

That provides fast feedback.

A server-side rule may also enforce the requirement to protect data coming from other channels.

This gives us:

Client side

Good user experience.

Server side

Reliable data integrity.

The two layers solve different parts of the same requirement.

Avoid Duplicating Complex Logic

Using both layers does not mean copying a hundred-line calculation into both a Client Script and Business Rule.

That creates maintenance problems.

Instead, think about what each layer really needs.

The client may only need enough logic to guide the user.

The server remains the authority for the final business rule.

If reusable server-side calculation is needed, centralize it in a Script Include.

Example: Making a Field Mandatory

Requirement:

Comments should be mandatory when Priority is Critical.

If this is primarily a form-experience requirement, a UI Policy may be ideal.

If more complex client logic is needed, an onChange Client Script could do:

1function onChange(
2  control,
3  oldValue,
4  newValue,
5  isLoading,
6  isTemplate,
7) {
8  if (isLoading) {
9    return
10  }
11
12  g_form.setMandatory(
13    'comments',
14    newValue === '1',
15  )
16}

But if the requirement is also a strict data rule regardless of update source, server-side validation should also be considered.

Example: Calculating a Server-Side Value

Requirement:

When an incident is saved, calculate a custom classification from several record values.

That is usually a server-side concern.

A Before Business Rule could calculate:

1(function executeRule(
2  current,
3  previous,
4) {
5  if (
6    current.impact == 1 &&
7    current.urgency == 1
8  ) {
9    current.u_classification =
10      'critical'
11  }
12})(current, previous)

This calculation works regardless of whether the update came from a normal user form or another server-side source.

Example: Updating a Related Record

Requirement:

After this record is created, update information on a related parent record.

That is not browser presentation.

An After Business Rule may be appropriate because the current record has already been written and the follow-up work affects another record.

Depending on the complexity and process requirements, Flow Designer or another server-side mechanism may also be worth considering.

Example: Showing a Client-Side Warning

Requirement:

Warn the user immediately when they select a particular assignment group.

That is a client-side interaction.

An onChange Client Script could display:

1g_form.showFieldMsg(
2  'assignment_group',
3  'This group is reserved for escalated requests.',
4  'warning',
5)

A Business Rule would not provide the same immediate form interaction.

Example: Preventing Invalid Data

Requirement:

Records must never be closed unless a required approval exists.

This sounds like a server-side business rule.

Why?

Because the requirement says:

must never

That should not depend on one particular UI.

A Client Script may still improve the user experience, but the authoritative rule should be enforced on the server.

Performance Differences

Client Scripts affect the browser experience.

Too many heavy Client Scripts can make forms feel slow.

Common causes include:

• excessive DOM or form manipulation
• repeated server calls
• scripts running unnecessarily on load
• complex logic in many onChange handlers

Business Rules affect server transactions.

Poorly designed Business Rules can create:

• slow inserts or updates
• excessive database queries
• recursive updates
• unnecessary related-record processing
• transaction delays

Both require performance awareness, just in different places.

Be Careful With GlideRecord in Loops

A server-side Business Rule can perform database queries using GlideRecord.

For example:

1var gr =
2  new GlideRecord(
3    'incident_task',
4  )
5
6gr.addQuery(
7  'incident',
8  current.sys_id,
9)
10
11gr.query()
12
13while (gr.next()) {
14  // process records
15}

This can be perfectly valid.

But repeatedly querying inside loops or processing large result sets during synchronous transactions can become expensive.

Always think about how frequently the Business Rule runs and how much work it performs.

Avoid Recursive Business Rules

A common mistake is updating the same record again from inside a Business Rule without understanding the resulting execution chain.

For example:

1current.update()

can cause additional Business Rules to execute.

That can lead to:

• recursion
• repeated processing
• unexpected updates
• poor performance

Before calling update() inside a Business Rule, make sure it is genuinely necessary.

Often it is not.

Consider Flow Designer for Process Automation

Not every server-side process needs to be a Business Rule.

Flow Designer can be a strong option for business processes involving:

• approvals
• task creation
• notifications
• record actions
• integrations
• multi-step automation

A Business Rule is excellent for tightly coupled record logic.

A flow may be easier to maintain for a broader business process.

The right choice depends on the responsibility.

Think About Where the Rule Belongs

A useful architectural question is:

What layer owns this requirement?

Browser experience?

Consider:

• Client Script
• UI Policy

Data integrity?

Consider:

• Business Rule
• Data Policy
• appropriate validation

Reusable server logic?

Consider:

• Script Include

Client needs server information?

Consider:

• GlideAjax
• Display Business Rule with g_scratchpad when appropriate

Security?

Use:

• Access Controls

Business process automation?

Consider:

• Flow Designer

This prevents Client Scripts and Business Rules from becoming catch-all tools.

A Practical Decision Checklist

When deciding between a Client Script and Business Rule, ask the following questions.

Does this need to happen immediately while the user edits the form?

Consider a Client Script or UI Policy.

Does this need to work even when the record is updated outside the UI?

Use server-side logic.

Is this only changing form presentation?

Prefer client-side mechanisms.

Is this protecting data integrity?

Do not rely only on a Client Script.

Does the logic modify the current record before save?

A Before Business Rule may be appropriate.

Does something need to happen after the record is saved?

Consider an After Business Rule or another server-side automation mechanism.

Can the work happen later without delaying the transaction?

An Async Business Rule may be appropriate.

Does the client require information calculated on the server?

Consider GlideAjax or a Display Business Rule depending on the requirement.

Common Mistake: Using Client Scripts for Everything

Because Client Scripts provide immediate feedback, they can become the first tool developers reach for.

This can lead to business logic being trapped in the browser.

Then an integration inserts a record and none of that logic runs.

Before implementing important behaviour in a Client Script, ask:

Does this rule still matter if nobody opens the form?

If the answer is yes, you probably need server-side enforcement too.

Common Mistake: Using Business Rules for Everything

The opposite approach creates its own problems.

If every simple form behaviour becomes a Business Rule, users may need unnecessary server round trips and the UI becomes harder to control.

For simple:

• mandatory
• visible
• read-only

behaviour, UI Policies may be clearer.

For immediate form reactions, Client Scripts may be appropriate.

Server-side code should not replace good client-side configuration.

Common Mistake: Mixing Presentation and Business Logic

Imagine a script that:

1. hides a field
2. queries several tables
3. calculates a business value
4. updates another record
5. displays a message

That script probably contains several responsibilities that belong in different layers.

A cleaner design might separate:

• UI Policy or Client Script for presentation
• Script Include for reusable server logic
• Business Rule for record processing
• event or flow for follow-up automation

ServiceNow gives us several layers for a reason.

Common Mistake: Trusting the UI as the Source of Truth

A user interface is only one way of interacting with ServiceNow data.

Records can be updated through:

• APIs
• imports
• integrations
• scripts
• flows
• scheduled jobs

If your application assumes every record passed through one particular form, it can become unreliable as soon as another integration is introduced.

Important rules should be designed around the data lifecycle, not just the screen.

Common Mistake: Too Many Client Server Calls

A form with several onChange Client Scripts that all call the server can quickly become sluggish.

Before making a request, ask:

• is the information already on the form?
• can the logic be handled locally?
• could one request return everything needed?
• is the request happening more often than necessary?
• could the information be prepared during form load?

Client-server communication should be intentional.

Common Mistake: Copying the Same Logic Everywhere

If the same server-side calculation appears in:

• three Business Rules
• one scheduled job
• a Scripted REST API

it probably needs a reusable home.

A Script Include can centralize the logic.

Then each caller can use the same implementation.

This reduces inconsistencies and makes future changes safer.

A Better Layered Example

Suppose we have a complex incident escalation feature.

The architecture might look like this:

UI Policy

Controls basic field visibility and mandatory state.

Client Script

Provides immediate user interaction that cannot be expressed cleanly through a UI Policy.

GlideAjax

Requests server-derived escalation information when necessary.

Script Include

Contains reusable escalation logic.

Business Rule

Enforces authoritative record rules.

Flow Designer

Coordinates a larger approval or notification process.

ACL

Controls who can access sensitive escalation data.

Each part handles the responsibility it was designed for.

Client Script vs Business Rule Summary

Use a Client Script when the primary concern is:

• browser-side form behaviour
• immediate feedback
• reacting to user input
• improving data-entry experience

Use a Business Rule when the primary concern is:

• server-side record processing
• data consistency
• transaction logic
• business rules that must work regardless of update source

And remember:

Sometimes the best answer is neither.

ServiceNow provides many declarative and scripted tools, and choosing the right one is usually better than forcing everything into a Client Script or Business Rule.

Final Decision Pattern

A practical mental model is:

Does the user need to see or experience this immediately on the form?

Start by considering client-side tools.

Must this rule remain correct regardless of how the data is updated?

Use server-side enforcement.

Is the behaviour simple field presentation?

Consider a UI Policy.

Is the logic reusable on the server?

Consider a Script Include.

Does the browser need server-side information?

Consider GlideAjax.

Is this really an access/security requirement?

Use ACLs.

Is this a larger business process?

Consider Flow Designer.

The architecture becomes much clearer when each requirement is assigned to the correct layer.

Conclusion

Client Scripts and Business Rules both use JavaScript, but they solve fundamentally different problems.

Client Scripts run in the browser and are primarily concerned with the user's form experience.

Business Rules run on the server and are concerned with record processing and authoritative business logic.

A useful rule of thumb is:

Client Scripts improve the interaction.

Business Rules protect and process the data.

But strong ServiceNow development goes one step further.

Before writing either one, ask whether a more appropriate platform feature already exists.

UI Policies can often handle simple form behaviour.

Data Policies can help enforce data requirements.

Script Includes centralize reusable server logic.

GlideAjax connects the browser to server-side processing.

ACLs protect access.

Flow Designer handles broader automation.

The goal is not to write the most scripts.

The goal is to put each requirement in the layer where it can be reliable, performant, understandable, and easy to maintain.