Video summary

ServiceNow Business Rules

Main summary

Key takeaways

Educational

Main ideas / lessons conveyed

  • Business Rules in ServiceNow are a server-side customization. They run on the backend (no client-side involvement).
  • When business rules run: They trigger based on what happens to a record in a table—when a record is displayed, inserted, updated, deleted, queried, or when background processing is needed.
  • Where business rules are stored: The list of business rules is in the ServiceNow table sys_script.
  • Business rules have two dimensions for configuration:
    1. Type / trigger moment (before/after/async/display)
    2. Operation (insert/update/delete/query)

Types of Business Rules (trigger moment)

  1. Before Business Rules

    • Run before an operation happens (before insert/update/delete/query).
    • Used to enforce rules that can prevent or alter what gets saved.

  2. After Business Rules

    • Run after the operation is completed (after insert/update/delete/query).
    • Used to display messages or make follow-up updates after data is saved.

  3. Async Business Rules

    • Similar to after, but they execute in the background.
    • Used for tasks like sending notifications/events without blocking the user.

  4. Display Business Rules

    • Run when a form is being displayed/opened.
    • Used to show messages on the UI when viewing records.

How “operations” relate to business rules

Business rules can be configured for these operations:

  • Insert
  • Update
  • Delete
  • Query

When configuring a business rule, you choose:

  • When to run (Before/After/Async/Display)
  • For which operation (insert/update/delete/query, where applicable)

Methodology / step-by-step instructions shown (with examples)

A) Before Business Rule Example (Prevent invalid submission)

Goal: Prevent creating an Incident when:

  • Category = Network
  • Subcategory = Wireless (Wi‑Fi equivalent)
  • Assignment Group is NOT Network

Steps described:

  1. Go to Configure → Business Rules
  2. Click New
  3. Create a business rule:
    • Type: Before
    • When: Before insert
    • Condition (logic):
      • Category is Network
      • Subcategory is Wireless
      • Assignment group is not Network
  4. Action:
    • Do not submit the record
    • Show an error message to the user (message is configurable)
  5. Save and test:
    • Try saving an Incident with Category Network + Subcategory Wireless + assignment group other than Network → error “invalid insert”
    • Try again assigning to the Network group → save succeeds

B) Before Business Rule Example (Auto-update state on work notes change)

Goal: When updating an Incident:

  • If Work Notes changes, set State = In Progress

Steps described:

  1. Create a New Business Rule
  2. Type: Before
  3. When: Before update
  4. Condition: Work notes changes / work notes updated
  5. Action: Update Incident State to In Progress
  6. Save
  7. Test by editing an existing Incident:
    • Modify Work Notes
    • Confirm State changes to In Progress

C) After Business Rule Example (Show message after incident creation)

Goal: After inserting a new Incident, display:

  • “Your incident is created” (conceptually: message upon record creation)

Steps described:

  1. Create New Business Rule
  2. Type: After
  3. When: After insert
  4. Condition: (none mentioned; it runs on insert)
  5. Action: Add/display a message to the user
  6. Save
  7. Test by creating a new Incident → message appears after save

D) After Business Rule Example (Auto-fill description when state becomes On Hold)

Goal: When an Incident’s State becomes On Hold, automatically set:

  • Description = “Waiting for users reply” (example text)

Steps described:

  1. Create New Business Rule
  2. Type: After
  3. When: After update
  4. Condition: Incident state changes to On Hold
  5. Action: Set the description text
  6. Important configuration detail mentioned:
    • Go to Advanced tab
    • Use scripting configuration (described as a “single line of coding”)
    • The video mentions setting:
      • workflow = false
      • current update (as part of the example)
  7. Save
  8. Test:
    • Edit an existing Incident
    • Change state to On Hold
    • Add/modify relevant fields
    • Confirm Description is populated automatically

E) Async Business Rule Example (Background notification idea)

Goal (example concept):

  • If an Incident is created as P1, trigger an event that results in notification delivery in the background.

How it’s explained:

  • Async insert/update/delete/query can be configured.
  • Example mechanism:
    • After a P1 Incident insert → generate an event
    • Event → create notifications for caller/group
  • The instructor notes they won’t implement it due to heavy coding requirements in the admin-focused series.

F) Display Business Rule Example (Show message when form opens)

Goal: Show a message whenever the Incident form is displayed/opened, e.g.:

  • “Welcome to the incident form”

Steps described:

  1. Create New Business Rule
  2. Type: Display
  3. When: display on form load (no insert/update/delete/query selected)
  4. Action: show message on the form
  5. Save
  6. Test:
    • Open an Incident form → message appears
    • Open from list view → message appears again

Key concepts reinforced

  • Before vs After matters for whether the business rule can block the operation and when messages/updates occur.
  • Async is for background processing (often notifications/events).
  • Display is for UI-time behavior when a form is opened.
  • Business rules can be configured via simple conditions (emphasized for admin exam readiness), while more complex logic uses scripting (later in developer-focused series).

Speakers / sources featured

  • Pritam (video narrator/host; “my name is pritam…”)
  • ServiceNow (product/documentation context; system tables like sys_script)

Original video