‹ All interview questions

Scripting

What are the different types of scripts in ServiceNow?

Beginner · ServiceNow · Mar 2026

The question

What are the different types of scripts in ServiceNow? List them, explain where each one runs, and give a one-line example of when you'd use each.

The Intent Behind This Question

This is a staple interview question because it tests whether you understand the client-server architecture. Many candidates mix up which scripts run where — and that's a red flag for interviewers.

Server-Side Scripts (run on the ServiceNow server)

  • Business Rules: Trigger automatically when a record is inserted, updated, deleted, or queried. Example: Auto-assign a P1 incident to the on-call team when it's created.
  • Script Includes: Reusable server-side JavaScript classes/functions. Called by Business Rules, other Script Includes, or from the client via GlideAjax. Example: A shared utility function that calculates SLA breach time, used by multiple Business Rules.
  • Scheduled Jobs (Scheduled Script Executions): Run on a defined schedule — daily, weekly, or at a specific time. Example: Every night at midnight, close all resolved incidents older than 7 days.
  • Fix Scripts: One-time scripts that run manually. Used for data cleanup or bulk updates. Example: Update all 5,000 legacy incidents to a new category structure after a migration.
  • Background Scripts: Ad-hoc scripts run by admins for testing or troubleshooting. Not saved or scheduled. Example: Quickly check how many open P1 incidents exist right now.

Client-Side Scripts (run in the user's browser)

  • Client Scripts: Trigger on form events — onLoad, onChange, onSubmit, onCellEdit. Example: When the 'Category' dropdown changes to 'Network', show the 'Network Device' field and make it mandatory.
  • UI Policies: Declarative (no-code) rules to make fields mandatory, read-only, or visible. Example: When Priority is 'Critical', make 'Assignment Group' mandatory — configured entirely through the UI, no code.
  • UI Actions: Custom buttons, links, or context menu items on forms or lists. Can run client-side, server-side, or both. Example: A 'Close and Notify' button that resolves the incident and sends the caller an email in one click.

The Golden Rule

// SERVER-SIDE: Has access to GlideRecord, can query/update database directly
// CLIENT-SIDE: Has access to g_form, g_user — manipulates the form in the browser
// 
// Client CANNOT use GlideRecord. To get server data from client, use GlideAjax.
// This is the #1 mistake beginners make.
💡 Interview Tip

If the interviewer asks 'Can you use GlideRecord in a Client Script?' — the answer is no. Client Scripts run in the browser; GlideRecord runs on the server. The bridge between them is GlideAjax. Getting this right shows you understand the architecture.