In your .NET projects, you've used middleware, action filters, and database triggers to intercept requests at…

Setting the Stage

Business Rules are server-side scripts that execute when a record is inserted, updated, deleted, or queried. They are the closest equivalent to a combination of ASP.NET middleware, Entity Framework interceptors, and SQL triggers — depending on the type.

The Execution Pipeline

// ASP.NET Request Pipeline (what you know)
// Request → Middleware → Controller → Action Filter → DB → Response
//
// ServiceNow Record Pipeline (the equivalent)
// Form Submit → Client Script (onSubmit) →
//   → Business Rule (before) → DATABASE WRITE →
//   → Business Rule (after) →
//   → Business Rule (async) [queued, runs later]
//   → Display Business Rule (on form load only)

Mapping to .NET Concepts

• Before Business Rule = ActionExecutingContext in an Action Filter, or an EF SaveChanges interceptor. Runs before the database write. You can modify the record, validate, or abort. Like calling context.Result = new BadRequestResult() to short-circuit.
• After Business Rule = Post-action filter or an AfterSaveChanges hook. The record is already saved. Use for cascade updates, notifications, or audit logging — things you'd do in a DbContext.SavedChanges event.
• Async Business Rule = A message queued to a background worker, like publishing to an Azure Service Bus or Hangfire job. The user's transaction completes immediately; processing happens later on ServiceNow's scheduler.
• Display Business Rule = Like a ViewComponent or OnGet() handler in Razor Pages. Runs when a form loads to populate calculated fields or set defaults.

// Before BR: Validate before save (like EF interceptor)
(function executeRule(current, previous) {
  // 'current' = the record about to be saved
  // 'previous' = the record's state before changes
  if (current.priority.changesTo(1) && !current.assignment_group) {
    current.setAbortAction(true); // Like throwing ValidationException
    gs.addErrorMessage('P1 incidents require an assignment group');
  }
})(current, previous);

Senior Considerations

• Performance awareness: Before/After BRs are synchronous — they block the user's save like sync middleware. Keep them under 200ms. Heavy work goes to Async BRs.
• No dependency injection: Unlike .NET where you'd inject services into filters, Business Rules access shared logic through Script Includes (ServiceNow's equivalent of utility classes/services).
• The 'previous' object: This is gold for .NET devs — it's like EF's ChangeTracker. You can compare current.state vs previous.state to detect exactly what changed, similar to checking entity.State in EF.