ServiceNow Business Rule Interview Questions and Answers

Business rules come up in the technical round for almost every ServiceNow developer and admin position. The panel starts with the four types, moves to current and previous, then turns the questions into scenarios: where would you put this logic, and why not a client script. The closing questions are usually debugging ones, because that is where prepared answers stop working.

These 21 questions come from the RizeX Labs question bank. Scheduled jobs and debugging are here because interviewers pair them with business rules in the same round.

Business rule basics and the four types

What is a Business Rule?

A business rule is server-side JavaScript that runs when a record is queried, inserted, updated or deleted on a table. It lives in sys_script and is configured with the table it applies to, the timing (the When field), and the conditions that decide whether the script runs.

Because it runs on the server, it fires no matter how the record reached the database. A form submission, a list edit, an import set, a REST call from another system: all pass through it. That is what makes it the enforcement layer for data integrity.

Types of Business Rules?

Four types, set by the When field.

Naming the four gets a follow-up asking for a project example of each. Memorised definitions collapse on "give me a real project example", so prepare one requirement per type from work you actually did.

Types of business rules and client scripts?

Interviewers ask these together to test server against client execution.

A client script has g_form and g_user and no direct database access. A business rule has current, previous and GlideRecord and no access to the form.

When to use Before Business Rule?

Use a before rule when you want to change the record being saved, or stop it from being saved. The record is still in memory, so setting a value costs nothing and you never call current.update().

(function executeRule(current, previous /*null when async*/) {

    if (current.state == 6 && current.close_notes.nil()) {
        gs.addErrorMessage('Enter close notes before resolving the incident.');
        current.setAbortAction(true);
    }

})(current, previous);

setAbortAction(true) cancels the database operation. Pair it with gs.addErrorMessage() so the user sees why.

When to use After Business Rule?

Use an after rule when the work involves other records. The record already has a sys_id and is committed to the transaction, so related updates can safely reference it.

(function executeRule(current, previous /*null when async*/) {

    var task = new GlideRecord('change_task');
    task.addQuery('change_request', current.sys_id);
    task.addQuery('state', 'NOT IN', '3,4');
    task.query();

    while (task.next()) {
        task.state = 3;
        task.update();
    }

})(current, previous);

Do not set fields on current in an after rule. That needs current.update(), which fires the rules on that table again and risks recursion.

When to use Async Business Rule?

Use an async rule when the work is slow and the user should not wait. The platform queues it and a scheduler worker runs it after the transaction commits, so the form returns immediately. Typical cases are outbound REST calls and recalculating many related records.

(function executeRule(current, previous /*null when async*/) {

    new VendorTicketAPI().sendUpdate({
        number: current.number.toString(),
        state: current.state.toString()
    });

})(current, previous);

Two limitations to state. previous is not available in an async rule, so before-and-after comparison must happen in a before or after rule. And the rule runs outside the user's transaction, so aborting the operation is no longer possible.

Difference between after business rule and asynchronous business rule?

If the follow-on work must be finished by the time the user sees the saved form, use after. If it can complete a second later, use async and keep the form fast.

What the interviewer is actually checking

• Whether you know when each type runs, not just what it is called
• Whether you use before rules for field values and after rules for related records
• Whether you can name the cost of async: no previous, no abort, no guaranteed order

Display rules, order, current and previous

What is Display Business Rule?

A display business rule runs before a form is presented to the user, after the record is read and before the page reaches the browser. It is the only type that runs on read rather than on write. Its job is to populate g_scratchpad, which is serialised with the form and becomes readable in client scripts.

What is the use of display business rule?

The use is performance. Without it, a client script needing server data must make a GlideAjax call after the form loads, which is a second round trip the user waits for. A display rule sends the data with the form.

(function executeRule(current, g_scratchpad) {

    g_scratchpad.callerVip      = current.caller_id.vip == true;
    g_scratchpad.callerLocation = current.caller_id.location.getDisplayValue();

})(current, g_scratchpad);

function onLoad() {
    if (g_scratchpad.callerVip) {
        g_form.addInfoMessage('VIP caller: ' + g_scratchpad.callerLocation);
        g_form.setValue('priority', 1);
    }
}

Keep g_scratchpad small. Everything in it is added to the page payload for every user who opens that form.

What is order of execution of Business Rules?

Within one type on one table, the Order field decides sequence. A lower number runs first and the default is 100. Rules sharing an order run in an unspecified sequence, so never depend on that.

Across types, a form save runs in this order:

1. Client scripts and UI policies, in the browser
2. Data policies, on the server
3. Before business rules, in Order sequence
4. The write to the database
5. After business rules, in Order sequence
6. The transaction commits, then async rules are queued
7. Workflows, flows and notifications proceed

Display rules sit outside this. They run on form load, before all of it. When a custom rule must run ahead of an out of the box rule, give it an order below 100, and say so, because the panel wants to hear you have sequenced two rules against each other.

What is current and previous?

current is a GlideRecord object holding the record as it stands in this operation, including the changes just submitted. previous is the same record as stored in the database before the operation started. Comparing them detects a specific change rather than any change.

(function executeRule(current, previous /*null when async*/) {

    if (current.assignment_group != previous.assignment_group) {
        current.work_notes = 'Reassigned from ' +
            previous.assignment_group.getDisplayValue();
    }

})(current, previous);

previous is only meaningful on an update, because an insert has no earlier version, so guard with current.operation() when the rule runs on both. It is not available in async rules, and current.field.changes() is usually cleaner than comparing objects by hand.

Business Rule predefined parameters?

gs is the one candidates underuse. gs.hasRole(), gs.addErrorMessage(), gs.eventQueue() and gs.info() all come from it.

What the interviewer is actually checking

• Whether you know g_scratchpad and why it beats a GlideAjax call on load
• Whether you can place all four types on a save timeline
• Whether you guard previous against inserts and async rules

Business rules in practice

How to define fields of incident table from business rules?

Set the field on current inside a before rule. Do not call update(), because the platform writes the record after the before rules finish.

(function executeRule(current, previous /*null when async*/) {

    if (current.impact == 1 && current.urgency == 1) {
        current.setValue('priority', 1);
    }

    current.setValue('company', current.caller_id.company);  // dot-walk

})(current, previous);

Use setValue() and getValue() in scoped applications, where direct field assignment is discouraged. To update a record without disturbing the audit trail, current.autoSysFields(false) keeps the existing sys_updated_by and sys_updated_on, and current.setWorkflow(false) stops business rules and notifications firing on that update.

What is the syntax to call email notifications in business rules?

A business rule does not send email directly. It fires an event, and a notification configured with "Event is fired" picks it up.

gs.eventQueue('incident.resolved', current, current.assigned_to, current.caller_id);

The arguments are the event name, the GlideRecord the event is about, and two optional string parameters read in the notification as event.parm1 and event.parm2. The name must exist in the Event Registry (sysevent_register), and the event lands in sysevent for the scheduler to process.

Candidates get caught here because they know the syntax but not the execution. Name the three records: the registry entry, the rule that queues the event, and the notification that consumes it.

What would be the difference between a validation performed by a business rule versus validations performed by client scripts?

A client script validates in the browser before anything reaches the server. It gives instant feedback and costs no server time, but it can be bypassed. A business rule validates on the server and cannot be.

A business rule wins whenever the data must be correct regardless of how it arrives. An import set loading 5,000 incidents runs no client scripts, and neither does an integration posting to the Table API.

The strongest answer names both: a client script for the message the user sees, and a before business rule doing the same check as the actual guarantee.

What the interviewer is actually checking

• Whether you set fields in a before rule instead of calling update()
• Whether you know setWorkflow(false) and autoSysFields(false) and when each applies
• Whether you can trace an email from gs.eventQueue() to the notification record

Scheduled jobs

What is a Scheduled Job?

A scheduled job is a record telling the platform to run something at a set time or on a repeating schedule with no user triggering it. Scheduled jobs are stored in sysauto and executed by the instance scheduler. They cover requirements no record event can trigger, such as closing resolved incidents after seven days.

Types of Scheduled Jobs?

sysauto is a base table and the types extend it.

• Scheduled Script Execution runs a server-side script on the schedule
• Scheduled Report generates a report and emails it to users or groups
• Scheduled Data Import runs an import set from a configured data source
• Application jobs such as Automated Test Runs also appear under Scheduled Jobs

The Run field accepts Daily, Weekly, Monthly, Periodically, Once, On Demand and Business Calendar entry. On Demand never runs on a timer and must be triggered by a script.

Difference between Scheduled Job and Scheduled Script Execution?

Scheduled Job is the category. Scheduled Script Execution is one kind of it. Everything under System Definition > Scheduled Jobs is a scheduled job, reports and imports included. Only a Scheduled Script Execution holds a script field and runs server-side code.

var gr = new GlideRecord('incident');
gr.addQuery('state', 6);
gr.addQuery('resolved_at', '<', gs.daysAgoStart(7));
gr.setLimit(1000);
gr.query();

while (gr.next()) {
    gr.state = 7;
    gr.setWorkflow(false);
    gr.update();
}

What the interviewer is actually checking

• Whether you know sysauto is the parent table and the types extend it
• Whether you can say when a scheduled job is right instead of a business rule
• Whether you set a limit and use setWorkflow(false) on bulk updates

Debugging and troubleshooting

How do you debug Business Rules?

This is the question trainers rate highest, usually asked as "your business rule is not firing, what do you check". Candidates who can recite what a business rule is often cannot debug one. Answer it as a checklist.

1. Is the rule Active? The most common cause and the fastest to check.
2. Is the When and the operation right? A before rule with only Delete ticked never fires on an update.
3. Does the Condition match? Run the same filter on the list and confirm the record appears.
4. Is it the right table? A rule on task applies to child tables. A rule on incident does not apply to change_request.
5. Did something abort the transaction? A lower-order rule calling setAbortAction(true) stops everything after it.
6. Did the update bypass rules? Any script calling setWorkflow(false) will not fire your rule.
7. Application scope. A scoped rule cannot always act on tables in another scope.
8. Is the Update Set committed in the instance you are testing on.

Then the tools. Add gs.info('Rule fired, state=' + current.state); and read System Logs > Script Log Statements, using gs.info, gs.warn and gs.error in scoped apps where gs.log is unavailable. Turn on Session Debug > Debug Business Rule to print every rule that evaluated in the transaction, with the Details option for condition results. Use the Script Debugger for a breakpoint inside the script.

How do you debug Client Scripts?

• Open the browser developer console and check for JavaScript errors. One broken script can stop later scripts on the same form.
• Add jslog('onChange fired, value=' + newValue); and read the output in the console or the Session Debug JavaScript log.
• Turn on Session Debug > JavaScript Log and Field Watcher to see field changes as they happen.
• Check the UI Type field. A script set to Desktop does not run in Service Portal, and this catches out a lot of people.
• Confirm the table, the view, and that an onChange script names the correct field.

If you cannot say when a script runs, where it runs and what data it can reach, this answer falls apart under two follow-ups.

How do you debug ACL issues?

ACL problems show as missing fields, read-only fields, or an empty list where records should be.

• Turn on Session Debug > Debug Security Rules. The instance prints every ACL evaluated with a granted or denied result, which names the rule that blocked access.
• Impersonate the affected user. An admin passes almost everything and hides the problem.
• Access needs the table-level ACL and the field-level ACL to both pass. Granting only the field ACL changes nothing if the table ACL denies.
• Inside one ACL, the condition, the script and the roles must all evaluate true. One failing part denies the whole rule.
• Evaluation runs from most specific to least specific, so check table.field before table.* and before the parent table's rules.
• Editing ACLs needs the security_admin role, raised from the user menu for the session.

What the interviewer is actually checking

• Whether you start with configuration checks before reading code
• Whether you know Session Debug and which option answers which question
• Whether you can describe a real defect you fixed, with the table, symptom and cause

Preparing for the round

Business rule questions reward one thing: placing a script on a timeline and saying what data it can see at that moment. Take one requirement from your own work, write it four ways as a before, after, async and display rule, then explain which one you shipped and why the other three were wrong for it.

Interviewers go five levels deep on project claims. Which table, what requirement, why this approach over the alternative, what was your role. If the answer runs out at any level, the earlier answers stop counting.

The ServiceNow training programme at RizeX Labs covers scripting on a live instance, with debugging practice and mock rounds on these questions.