The short answer
Use Flow Designer by default. Use a Business Rule when you specifically need synchronous execution that affects the record being saved in the same database transaction.
That is the rule. Everything below is the reasoning.
What Flow Designer gives you that Business Rules do not
Flow Designer runs asynchronously by default — it does not block the user's save action. The user clicks Save, the record is committed to the database, and the flow runs in the background. This means:
- The user interface stays responsive — no waiting for the automation to complete
- Long-running operations (external API calls, approval chains, multi-step processes) do not time out
- Built-in error handling with the Error Handler spoke — you can catch failures gracefully
- Execution Details provides a complete log of every step, every input, every output — far better than hunting through the System Log
- Visual, readable, and maintainable by people who are not developers
- IntegrationHub spokes handle authentication, retry logic, and error handling for external integrations automatically
For the vast majority of automation — notifications, approvals, external API calls, multi-step workflows — Flow Designer is the right choice.
When a Business Rule is still the right tool
Business Rules run synchronously in the same database transaction as the triggering event. This is their defining characteristic — and it is both their strength and their limitation.
Use a Business Rule when:
- You need to auto-populate a field before the record is saved. For example: set the resolution code based on the category before the record is committed. A Before Business Rule can do this. Flow Designer cannot — by the time it runs, the record is already saved.
- You need to prevent the save entirely based on a condition. A Before Business Rule can call
current.setAbortAction(true)to stop the record from saving. There is no equivalent in Flow Designer. - You need to validate data at the server level before saving. UI Policies can be bypassed by the REST API. Before Business Rules cannot.
- You need very lightweight logic that must complete in microseconds. For simple field calculations that must happen before the save, a Before Business Rule has less overhead than a flow.
The practical decision tree
Ask yourself these questions in order:
- Does this need to run before the record is saved and affect what gets saved? → Business Rule (Before)
- Does this need to abort the save under any condition? → Business Rule (Before)
- Does this involve multiple steps, external systems, approvals, or notifications? → Flow Designer
- Everything else → Flow Designer
The maintenance argument
There is a second reason to prefer Flow Designer beyond technical capability: maintainability. A Business Rule is a JavaScript file that requires a developer to read, understand, and modify. A Flow Designer flow can be read and understood by a ServiceNow admin, a business analyst, or a process owner — not just a developer.
When you leave a project, the team that maintains your work will thank you for flows over scripts. This is a real consideration in production environments.
What about legacy Workflow?
Legacy Workflow is being deprecated. Do not build new automation in Workflow. If you have existing Workflow automations, plan to migrate them to Flow Designer. ServiceNow's future investment is in Flow Designer — not Workflow.
The rule one more time
Flow Designer is the default. Business Rules are for synchronous pre-save logic and save prevention. Everything else — notifications, integrations, approvals, multi-step automation — goes in Flow Designer. This is the answer interviewers are looking for, and the pattern that holds up in production.