The question comes up in every design review: should this logic live in a Business Rule or in a flow? It usually gets settled by personal preference, or by an internal rule along the lines of "we don't write scripts anymore". Both lead to the same place, a platform where half the automation sits in the wrong tool.
The useful criterion is neither developer comfort nor low-code doctrine. It is where the logic sits relative to the database transaction. A Business Rule lives inside it. A flow, by default, lives outside. Everything else follows from that.
This article lays out how both tools actually behave, then gives a decision table by use case that you can bring to a design review.
The question is not low-code versus script
Flow Designer contains scripts, in custom actions and in inline conditions. A well-written Business Rule may hold no logic beyond a call to a Script Include. The visual versus code framing therefore describes nothing useful.
What really separates the two tools comes down to three questions:
Must the logic run before the write hits the database, or can it wait?
Does the user have to wait for the processing to finish?
Does the processing need to pause, wait for an approval or wait for a condition?
A Business Rule answers the first two well and the third not at all. A flow answers the third, the second in certain configurations, and not the first.
Business Rules: four execution moments
A Business Rule is a server-side script triggered by a database operation: insert, update, delete, query. The When field defines four very different behaviours, and choosing that field matters more than the content of the script.
Before. The script runs inside the same transaction, before the write. This is the only moment where you can change the value that will be stored, by assigning current.field directly, with no call to update(). It is also the only place where you can abort the operation.
// Before Business Rule on incident, insert and update
(function executeRule(current, previous) {
if (current.impact == 1 && current.urgency == 1) {
current.priority = 1;
}
// no current.update(): the write has not happened yet
})(current, previous);After. The script runs inside the same transaction, after the write. The user waits for it to finish before regaining control. It is the right place to act on other records, never to modify the current one, which would trigger an extra write and a risk of recursion.
Async. On submit, the platform creates a scheduled job, materialised as a record in sys_trigger, executed in the background once the transaction is done. The user regains control immediately. Worth knowing: the previous object is not available in an async Business Rule. Any logic based on a field's previous value is therefore impossible there.
Display. The script runs before the form is rendered, and prepares server-side data for the client through g_scratchpad.
Two settings deserve as much attention as the script itself. The Order field determines execution sequence, and two rules sharing the same order have no guaranteed sequence between them. The Condition field should carry the narrowest possible filter: a condition written there avoids loading and running the script at all, which an if at the top of the script does not.
Flow Designer: outside the transaction by default
A flow triggered on record creation or update does not run inside the user transaction. It goes to the background, like a scheduled job. There is always a delay between the database operation and the actual start of the flow.
That characteristic is both an advantage and a trap. An advantage, because the processing time is not billed to the user and does not count against the interactive transaction time limit. A trap, because the data the flow reads is the data that exists when it starts, not the data that existed when it was triggered.
The textbook case is the comment. A flow triggered on comment added and running in the background reads the field when it starts. If a second comment arrived in the meantime, the flow processes the wrong text.
Two trigger settings change this behaviour:
Run Trigger defines whether the flow runs once, or on each distinct change meeting the condition.
Under advanced options, Where to run the flow switches between background, which is the default, and foreground. The flow then joins the user transaction, with access to the trigger record as it stands at that moment, and with the matching cost on response time.
A flow does bring something no Business Rule can do: waiting. Waiting for an approval, waiting for a condition, waiting for a timer, then resuming where it left off. A Business Rule runs in one block and ends.
One last point of caution: every execution produces a persisted flow context. A For Each loop over several hundred or several thousand records builds a heavy context and costs real resources. At that volume, the good practice is to hand the processing to a scripted action inside the flow rather than to the native loop.
The deciding factor
Ask the questions in this order and the answer almost always falls out on its own.
Must the logic influence the stored value? If yes, before Business Rule. No other answer exists.
Must the logic prevent the record from being saved? If yes, before Business Rule, with
setAbortAction.Does the logic need a field's previous value? If yes, before or after Business Rule, never async, never a background flow.
Does the logic need to wait for something or someone? If yes, flow, no hesitation.
Otherwise, flow.
That last point is deliberately broad. Once the first three cases are ruled out, a flow is almost always preferable: it reads without reading code, its executions are traced and replayable, and it does not weigh on the user transaction.
The decision table
Case by case, here is what we apply in design reviews.
Compute a field before the record is saved. Before Business Rule. The value has to exist before the write.
Reject a record based on a business rule. Before Business Rule. A flow cannot cancel an operation that has already been committed.
React to a specific value change, old to new. Before or after Business Rule, to have
previousavailable.Update related records. Flow, or async Business Rule if the logic is short and already in place.
Send a complex conditional notification. Flow.
Get an approval, then continue. Flow. This is the use case that rules Business Rules out entirely.
Call an external system. Flow with IntegrationHub, never a synchronous Business Rule: an external call inside a user transaction exposes you to a response time you do not control.
Process a large batch. Scheduled flow with a scripted action for the loop, or a classic scheduled job.
Prepare data for the form. Display Business Rule. No flow covers this need.
Filter what a user can see in a list. Query Business Rule, and nothing else.
Read a comment or work note at the exact moment it is added. Foreground flow, or an after Business Rule that passes the value to a flow.
Four costly mistakes
A before Business Rule doing background work. A REST call, a loop over a hundred records, document generation: all of it adds to save time, on every save, for every user. This is the leading cause of slow forms.
An after Business Rule updating the current record. It triggers a second write, which re-runs the rules, and sometimes a loop. The right answer is almost always to move the logic to before.
A flow triggered on a high-volume table with no restrictive condition. Every execution creates a context. On a table taking thousands of writes a day, the bill arrives as general slowness that is hard to trace back to its cause.
A Business Rule to flow to Business Rule chain. Technically possible, unreadable in production. When an incident happens, nobody can tell which link changed what. If you must chain, document the entry point in the description of each object.
Making the two work together
The two tools do not exclude each other. The most useful pattern captures the data in a Business Rule, at the moment it is reliable, then hands the long processing to a flow.
// After Business Rule: capture the value, let the flow do the rest
(function executeRule(current, previous) {
var inputs = {};
inputs['record'] = current;
inputs['comment'] = current.comments.getJournalEntry(1);
sn_fd.FlowAPI.getRunner()
.subflow('global.comment_processing')
.inBackground()
.withInputs(inputs)
.run();
})(current, previous);inForeground() runs the flow inside the transaction and waits for it. inBackground() returns control immediately. Choosing between them is exactly the trade-off described above, simply moved into code.
What about legacy Workflows?
A useful clarification, because this one circulates in a distorted form. At the time of writing, the ServiceNow product team states that there is no deprecation plan for the legacy Workflow engine. However, since the Zurich family, new instances no longer ship legacy workflows out of the box, and the standing recommendation is to build all new automation in Flow Designer.
The practical consequence: nothing forces you into an urgent migration, but anything built today in the old editor is debt. Check this against the documentation for your own version before committing to a migration project.
Where to start
If you inherit an instance and want to know where you stand, three queries are enough to frame the subject.
List active Business Rules by table, sorted by count, and look at the main transactional tables first.
Isolate before Business Rules whose script runs past thirty or so lines or contains an external call. These are the priority candidates for a move to a flow.
Check Business Rules with no condition, which therefore run on every write to their table.
Sorting then happens with the table above. The general rule fits in one sentence: anything that must change or block the write stays a before Business Rule, anything that comes after belongs in a flow.