The fundamental difference: synchronous vs asynchronous
This is the root of every other difference between Business Rules and Flow Designer. Understanding it makes every other decision straightforward.
A Business Rule runs synchronously inside the database transaction that triggered it. When a user saves an incident, the database transaction pauses, all matching Business Rules run in sequence, and only when all of them complete does the transaction commit and the save complete. The user's browser waits through all of this before the page confirms the save.
A Flow Designer flow runs asynchronously — by default, outside and after the triggering database transaction. The user saves the incident, the transaction commits immediately, the save confirms in the browser, and then the flow starts running in the background. The user does not wait for the flow to complete.
This difference drives almost every other consideration:
| Characteristic | Business Rule | Flow Designer |
|---|---|---|
| Execution timing | During the save transaction | After the save completes |
| User waits? | Yes — until all rules complete | No — save confirms immediately |
| Can modify the record being saved? | Yes (Before rules) | No — record already saved |
| Can abort the save? | Yes — setAbortAction(true) | No equivalent |
| External API calls | Risky — can timeout, slow saves | Safe — runs independently |
| Long-running operations | Will timeout if too long | Supported — runs in background |
| Error handling | try/catch in script | Built-in Try/Catch steps |
| Visibility into execution | System log only | Execution Details — step-by-step |
| Maintainability | Requires JavaScript knowledge | Readable by non-developers |
When Business Rules are the right tool
Business Rules have one unique capability that Flow Designer cannot replicate: running synchronously before a record is saved, in the same transaction, with the ability to modify or abort that save. There are three specific scenarios where this matters.
1. Auto-populating fields before save
A Before Business Rule can set values on current that are saved as part of the triggering transaction. The user submits a form, the Business Rule fires, calculates values, sets them on the record, and those values are in the database when the transaction commits — all before the user's browser sees the save confirm.
(function executeRule(current, previous) {
// Auto-calculate resolution time when incident is resolved
if (current.state == '6' && previous.state != '6') {
var opened = new GlideDateTime(current.getValue('opened_at'));
var resolved = new GlideDateTime();
var duration = GlideDateTime.subtract(opened, resolved);
current.setValue('time_to_resolve', duration.getDurationValue());
}
})(current, previous);Flow Designer cannot do this. By the time a Flow runs, the record is already committed. If a flow sets the same field, it results in a second database write after the initial save — technically it works but it is architecturally incorrect for fields that should be part of the original save transaction.
2. Preventing a save with setAbortAction()
A Before Business Rule can call current.setAbortAction(true) to cancel the entire save operation. The record is not written to the database. The user sees an error message. No data is persisted.
(function executeRule(current, previous) {
// Prevent resolving an incident without a resolution code
if (current.state == '6' && !current.getValue('close_code')) {
current.setAbortAction(true);
gs.addErrorMessage('Resolution code is required before resolving this incident.');
}
})(current, previous);Flow Designer has no equivalent. Flows run after the save — the record is already in the database by the time a flow could check the condition. Server-side save prevention requires a Business Rule.
Note: Client Scripts (onSubmit returning false) can prevent form submissions from the browser, but they can be bypassed by REST API calls. Business Rules cannot be bypassed — they run regardless of how the record is being saved.
3. Very lightweight synchronous logic with no side effects
For extremely simple, fast calculations that must happen in the save transaction — calculating a checksum, formatting a field value, deriving a priority from urgency and impact — a Before Business Rule is the most efficient option. No background processing, no async overhead, just a calculation that happens inline.
(function executeRule(current, previous) {
// Derive priority from urgency and impact
var urgency = parseInt(current.getValue('urgency'));
var impact = parseInt(current.getValue('impact'));
var priority = Math.min(urgency, impact);
current.setValue('priority', priority.toString());
})(current, previous);For this use case, a Before Business Rule is not just acceptable — it is the right choice architecturally. Flow Designer would add unnecessary asynchronous overhead.
When Flow Designer is the right tool
Flow Designer is the right default for the overwhelming majority of ServiceNow automation. The technical reasons:
External API calls
Making a REST call inside a Business Rule is a significant risk. If the external service is slow or unavailable, the user's save operation times out. If the API call takes 10 seconds, every save of that record takes 10 additional seconds from the user's perspective. Flow Designer runs the API call in the background — the user's save completes immediately and the integration happens asynchronously.
Approval chains and multi-step processes
Business Rules execute once and complete. Flow Designer supports long-running processes with wait conditions — a flow can pause for hours waiting for an approval, then continue when the approval is received. There is no equivalent in Business Rules.
Notification and communication
Sending emails, Slack messages, Teams notifications, or SMS should almost always be done in a flow rather than a Business Rule. Notifications triggered from Business Rules add latency to every save operation. Flows handle them in the background with no user impact.
Cross-table automation
When automation involves creating or updating records on multiple tables, Flow Designer is cleaner. A Business Rule that creates three related records, sends a notification, and calls an external API is doing too much in a single synchronous execution. The same logic in a flow is readable, debuggable, and does not slow saves.
IntegrationHub spokes
ServiceNow's IntegrationHub spokes (Jira, Slack, ServiceNow, SAP, etc.) are available as Flow Designer actions. They handle authentication, retry logic, and error responses automatically. Equivalent integrations built in Business Rules require significant custom code. If you are integrating with an external system that has a spoke, use Flow Designer.
Visibility and maintainability
Flow Designer's Execution Details provides a step-by-step record of every execution — what inputs each step received, what outputs it produced, and what happened at each decision point. Debugging a Business Rule requires hunting through the System Log. For production automation, the debugging experience alone is a strong argument for Flow Designer.
What about After Business Rules?
After Business Rules run after the transaction commits but are still synchronous — the user waits. They can query and update other records, but they do not hold the save transaction open (the triggering record is already saved). They exist in a middle ground: they cannot abort the save or modify the triggering record's saved values, but they run in the same thread as the save.
For most use cases that After Business Rules currently handle — updating related records, creating linked records, sending notifications — Flow Designer is the better replacement. The main remaining use case for After Business Rules is logic that must run immediately after the save and before any other process has a chance to read the newly-saved record. This is an edge case; most teams should default to Flow Designer even for After Business Rule replacements.
What about Async Business Rules?
Async Business Rules run after the save transaction, in a separate thread — similar to Flow Designer. They were the original way to run background automation in ServiceNow before Flow Designer existed. For new development, use Flow Designer instead. Async Business Rules lack the visual execution details, built-in error handling, and maintainability of Flow Designer. They exist for backward compatibility.
The migration question — what to do with existing Business Rules
You do not need to migrate existing Business Rules immediately. Functioning automation in production should be migrated only when:
- The Business Rule needs to be changed or extended anyway
- The Business Rule is causing performance issues (slow saves, timeouts)
- The logic is complex enough that the Flow Designer debugging tools would be valuable
When you do migrate, the pattern is: Before Business Rules that modify the record stay as Business Rules (they cannot be replicated in Flow Designer); everything else becomes a Flow Designer flow.
Legacy Workflow — migrate everything
Legacy Workflow (the circular workflow editor, not Flow Designer) is deprecated. ServiceNow has discontinued investment in it and it will eventually be removed. All new automation should be in Flow Designer. Existing Workflow automations should be migrated to Flow Designer — prioritise active, business-critical workflows first.
The decision framework
Apply these questions in order:
- Does this need to run before the record is saved and modify what gets saved? → Before Business Rule
- Does this need to abort the save under any condition? → Before Business Rule with setAbortAction()
- Does this involve an external API call? → Flow Designer (never block a save on external API latency)
- Does this involve waiting for an approval or external event? → Flow Designer (Business Rules cannot pause)
- Does this need to be readable by a non-developer? → Flow Designer
- Everything else → Flow Designer (default)
The answer is Business Rule in cases 1 and 2 only. Every other scenario defaults to Flow Designer.
Related guides:
- Business Rule types — Before, After, Async, Display explained
- Flow Designer triggers — configuring when flows fire
- Flow Designer error handling — building resilient flows
- Flow Designer best practices — building maintainable flows
- Script Includes — reusable logic called from both Business Rules and flows