Flow Designer vs Business Rules

[dipak_thakor]

A good architectural principle is to understand depending on the use case, when flow designer vs business rules should be used.

What is Flow Designer?

Flow Designer is a Now Platform feature that enables rich process automation capabilities in a consolidated design environment. Flow Designer enables process owners to use natural language to automate approvals, tasks, notifications, and record operations without having to code.

What is Business Rule?

Business Rules are server-side logic that execute when database records are queried, updated, inserted, or deleted. Business Rules respond to database interactions regardless of access method: for example, users interacting with records through forms or lists, web services, or data imports (configurable).

Flow Designer Vs Business Rules

Flow designer is not a replacement for business rules, both business rules and flow designer have there use cases. Business rule require advanced scripting and knowledge skills and is harder to manage . Flow designer will run in the background and there will be a delay between the trigger and the execution of the flow. Although there is some overhead compared to a business rule, flows offer ease of maintainability and manageability (intuitive and user friendly ). My favorite thing about flows that business rules do not offer, is the ability to view execution context.

The Flow execution details allow you to view run-time information about an action or flow directly from the design environment, such as the current state, items run, and values produced.

That's Great Which One Should I Use?

ServiceNow recommends everyone to use flows over Business rules wherever possible dependent on the use case (due to their advantageous nature), flows created using flow designer are easy to manage and maintain and can be a great asset in controlling technical depth.

You should use Business Rules instead of Flow Designer when:

• The business logic only calls a script includes.
• There is a need to execute the business logic, immediately before or after writing to the database in the context of the same thread.
• The is a requirement for the business logic to run in a specific order with other business rules.