What is the difference between a business rule and script include?

[vsashwin364]

Hi I am a newcommer to ServiceNow - exploring the platform. I know both are server-side script, but what makes them different.

[Lakshmi888888]

Hi  @vsashwin364 ,

On a high level,

A Business Rule is a trigger-based server-side script that runs automatically during database operations, whereas a Script Include is a reusable library of code that only runs when explicitly called. Both operate on the server side, but they serve different purposes in ServiceNow.

Execution and Trigger

• Business Rule:
  • Runs automatically.
  • Triggers during database CRUD actions (Insert, Update, Delete, Query, or Display) on a specific table.
  • Configured using form settings (Before, After, Async, Display) and conditional filters.

• Script Include:
  • Runs only on demand.
  • Executes when called by other server-side scripts (like Business Rules or Workflow scripts) or via client-callable GlideAjax.
  • Does not watch tables or trigger automatically. 

Purpose and Reusability

• Business Rule:
  • Handles record-specific database logic.
  • Enforces data integrity, auto-assigns values, or initiates background actions for a specific record lifecycle. 

• Script Include:
  • Promotes code reuse and modularity.
  • Stores centralized functions or classes so you do not repeat the same block of code across multiple rules or applications

[yashkamde]

Hello @vsashwin364 ,

Business Rule	Script Include
Executes automatically based on database operations (Insert, Update, Delete, Query, Display).	Executes only when called from another script (Business Rule, Scripted REST API, Flow Action, UI Action, etc.).
Event-driven.	Function/Class-based and reusable.
Mainly used to enforce business logic, validate data, or automate actions on records.	Mainly used to write reusable logic that can be shared across multiple scripts.
Tied to a specific table.	Not tied to any table (unless designed that way).
Runs Before, After, Async, or Display.	No execution timing—it runs whenever another script invokes it.
Reduces manual intervention by triggering automatically.	Reduces code duplication by centralizing common logic.
Cannot be directly called from another script like a function.	Can be called from server-side scripts and, if Client Callable, from client scripts via GlideAjax.

Example :
Business Rule :

// Suppose whenever an Incident is created with Priority = 1, you want to automatically assign it to the Major Incident team.
// Before Insert Business Rule

if (current.priority == 1) {
    current.assignment_group = 'Major Incident Team Sys ID';
}

Script Include :

// Now if the same logic is required in multiple places (Business Rule, Scripted REST API, Flow Designer Action, etc.)

var IncidentUtils = Class.create();
IncidentUtils.prototype = {
    initialize: function() {},

    assignMajorIncident: function(current) {
        if (current.priority == 1) {
            current.assignment_group = 'Major Incident Team Sys ID';
        }
    },

    type: 'IncidentUtils'
};

call this in BR any anywhere server side for reusability :

var utils = new IncidentUtils();
utils.assignMajorIncident(current);

If my response helped mark as helpful and accept the solution.

[Ankur Bawiskar]

@vsashwin364 

answer to this question can be easily found on any AI tool or Google or ServiceNow Docs

what did you find and what are your doubts?

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tanushree Maiti]

Hi @vsashwin364 

Aspect	Business Rule	Script Include
Purpose	Executes business logic automatically when a database operation occurs	Stores reusable functions or classes that can be called from other scripts
Execution	Triggered automatically by record events (Insert, Update, Delete, Query, Display)	Runs only when explicitly invoked
Type	Event-driven server-side script	Reusable server-side code library
Trigger Mechanism	Database activity on a specific table	Call from Business Rule, Scripted REST API, Flow Action, UI Action, Background Script, etc.
Table	Associated with a specific table	Not tied to a table
Reusability	Limited. Logic is usually specific to one table/process	High. Same code can be reused across multiple applications and tables
Performance	Can impact performance if many rules execute unnecessarily	Better for reusable logic because code loads only when called
Typical Use Cases	Data validation, field population, triggering events, enforcing business policies	Utility methods, common calculations, reusable integrations, shared data processing
Configuration Options	Before, After, Async, Display; Conditions; Order; Insert/Update/Delete/Query	Name, API Name, Client Callable, Accessible From
Maintenance	Can lead to duplicated logic if similar code exists in multiple rules	Centralized logic, easier maintenance
Best Practice	Keep focused on triggering and validation logic	Place complex/reusable logic here and call it from Business Rules
Example	When Incident Priority = 1, automatically notify manager	Function IncidentUtils.getManager() used by multiple Business Rules