Development · Lesson

Client vs server scripting

Quick answer

Most of ServiceNow is configured, not coded, but when configuration runs out, you script. The first and most important thing to master is where code runs, because client-side and server-side scripting have completely different APIs, powers and pitfalls. Get the location model right and everything else follows.

Key takeaways

Client vs server, the fundamental divide
Client-side script types
The g_form API (client)
Prefer no-code first
Common mistakes

Most of ServiceNow is configured, not coded, but when configuration runs out, you script. The first and most important thing to master is where code runs, because client-side and server-side scripting have completely different APIs, powers and pitfalls. Get the location model right and everything else follows.

Client vs server, the fundamental divide

Client-side

Runs in the browser, on a form. Reacts to the user. APIs: g_form, g_user, g_scratchpad. Types: Client Scripts, UI Policies.

Server-side

Runs on the instance. APIs: GlideRecord, current, previous, gs. Types: Business Rules, Script Includes, jobs.

Client-side script types

onLoad

Runs when the form opens, set defaults, show/hide.

onChange

Runs when a specific field changes.

onSubmit

Validation before save, return false to block.

onCellEdit

Inline list editing.

// onChange: warn when priority becomes P1
function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading || newValue === '') return;
  if (newValue == '1')
    g_form.addInfoMessage('P1, notify the on-call lead');
}

The g_form API (client)

g_form.getValue(f)

Read a field value from the form.

g_form.setValue(f,v)

Set a field (and its display value for references).

g_form.setMandatory(f,b)

Make a field required.

g_form.setReadOnly(f,b)

Lock a field.

g_form.setDisplay/​setVisible

Show/hide a field.

g_form.addErrorMessage(m)

Show a message banner.

Golden rule: never query the database synchronously from a client script. A synchronous GlideRecord or getReference call freezes the browser while it waits on the server. Use an async GlideAjax call to a Script Include instead, or move the logic server-side.

Prefer no-code first

Before writing a client script, ask whether a UI policy does it (mandatory/read-only/visible by condition), it's declarative, faster, and survives upgrades better. Reserve client scripts for logic policies can't express.

Common mistakes

Putting heavy logic client-side and freezing the form.
Using g_form on the server or GlideRecord on the client.
Synchronous GlideAjax/getReference instead of the async callback form.
Scripting what a UI policy or flow could do no-code.

Want to learn this properly?

Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.

See the course Ask a question

Check your understanding

onChange and onLoad scripts run...
- A. Client-side in the browser
- B. On the database
- C. Nowhere
Show answer
A. Client-side in the browser
They react to form events in the browser.
GlideRecord is used mainly on the...
- A. Server side
- B. Client side
- C. Printer
Show answer
A. Server side
Server-side scripts use GlideRecord.
To get server data from client code you use...
- A. GlideAjax
- B. CSS
- C. A report
Show answer
A. GlideAjax
GlideAjax calls a client-callable Script Include.

Frequently asked questions

What does the term Client vs server scripting refer to in ServiceNow?

What is worth remembering about Client vs server scripting in practice?

Before writing a client script, ask whether a UI policy does it (mandatory/read-only/visible by condition), it's declarative, faster, and survives upgrades better.

What tends to go wrong with Client vs server scripting?

Putting heavy logic client-side and freezing the form. Using g_form on the server or GlideRecord on the client. Synchronous GlideAjax / getReference instead of the async callback form.