[object Object]

The instance had 1,400 active business rules. Half of them had no documented owner. A new business rule added on task for a small custom case caused a measurable slowdown across every incident, every change, and every catalog request — because task is the parent and the rule fired on all child tables. Business rules are the single most-abused configuration surface on the platform; the patterns below keep them performant, reviewable, and removable.

The Four Types, in One Paragraph

Before rules modify the record before it is written to the database. After rules do work after the save (notifications, related-record updates) and run in the same transaction. Async rules run in the background after the transaction commits — non-blocking, lower priority, eventually consistent. Display rules run when the record loads in the form, useful for computing display-only values. Pick by what you need and when, not by what is convenient.

Type decision tree:
  modify the record being saved -> before
  do related work that must commit with the record -> after
  do related work that can wait a few seconds -> async
  compute display value, no save -> display

Performance Traps

A business rule on task with no condition is a production risk — it fires on every incident, change, problem, request, request item, and catalog item update. Scope rules tightly with conditions on the table, on field values, and on the operation type (insert, update, delete). The rule’s filter runs before the script; a permissive filter wastes engine time on rows that the script then no-ops on. Use the tightest filter that expresses the real condition.

// Good: tight filter, narrow scope
// Condition: gr_table = 'incident' AND priority = 1 AND state.changesTo(2)
(function executeRule(current, previous) {
  pageOnCallForP1(current);
})(current, previous);

Async Is Underused

If the work can wait a few seconds, make the rule async. It unblocks the user transaction and pushes load off the synchronous save path. Notifications, integrations to external systems, derived-field updates on related records — all fine async candidates. Synchronous rules that call REST endpoints or compute expensive aggregations are the most common cause of slow form save times. The user does not care if the notification fires now or in 10 seconds; they care that the form responded fast.

Use Script Includes for Logic

Business rules should be thin — the logic belongs in a Script Include. Keeps the logic reusable across rules, testable in isolation via Script Background or ATF, and reviewable as a coherent unit. A 400-line business rule is a smell; refactor into a Script Include with a clear API. The business rule then becomes the trigger, not the implementation.

// Business rule: trigger only
(function executeRule(current, previous) {
  new x_acme_inventory.LowStockReorder().checkAndReorder(current);
})(current, previous);

Governance: Who Owns What

Maintain a business rules inventory per application scope with named owners and documented purposes. Orphan rules (no owner, no documented purpose) accumulate over years. Review quarterly; retire rules that have not fired in 90 days (use the sys_history_line and audit data to determine fire frequency). Do not delete — set inactive with a deactivation date and a 90-day grace period in case the rule is needed for a rare scenario.

Common Failure Modes

Rules that call external REST endpoints synchronously without timeouts — every save blocks on the network and the user sees the form hang. Set explicit timeouts and prefer async. Rules that update other records via GlideRecord without setWorkflow(false) — cascading rule fires multiply work invisibly. Rules that depend on the order of execution among multiple rules — explicit order field values are not always reliable; refactor to a single rule with internal sequencing.

What Changed in 2026

The platform’s instance scan suite includes business rule pattern detectors that flag common anti-patterns (no condition, calling external REST sync, broad table scope). Run the scan quarterly and treat findings as triage candidates. Older releases require manual review.

Cost Considerations

Business rules execution time is platform compute that is not visible on a dashboard until it becomes a slowdown. Rules that fire on hot tables (task, sys_user, cmdb_ci) compound across thousands of saves per day. Profile heavy rules via the slow query log and the transaction log; the worst offenders are usually obvious once measured.

Implementation Sequence

When adding a business rule, ask first if a Flow Designer flow expresses the same logic. Flows are easier to review and maintain for cross-entity orchestration. Use business rules for record-level invariants (validation, defaulting, computed fields) and let flows handle the multi-record work. Refactoring an existing instance’s business rules into the right tool is a multi-quarter project; iterate by scope and prioritize the hot tables.

What to do this week: query sys_script for rules on task (the parent) with no condition; that count is your highest-leverage performance audit list.

[object Object]
Share