Business rules Vs Flows
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-14-2024 09:42 AM
Wanted to know if anyone has any opinion on why we would use flows/subflows/actions instead of business rules going forward?
In my opinion there are scenarios where flows are useful - like catalog items, scheduled flows, integration related ones etc
But for things like when a field is updated do this logic - do you prefer a BR or flow? I don't like flow in this scenario since I find flows clunky to manage. No debug capability to stepping through code, no code search.
In a recent meeting with ServiceNow they recommend to use flow for scenarios where BRs were used in the past. I don't agree with it. I wanted to get some perspective from other developers. Thanks for your time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-14-2024 12:34 PM
Hi MS12,
I see flows are a new feature and seems to be intended to replace the older Workflow feature.
I've seen that some folks report logic limitations, that are supported in server-side scripts. You list reasons you don't like Flows for all cases, I would then continue to use business rules, script includes, ... where I have access to the javascript APIs in the platform.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2024 04:55 AM
Hi MS12,
Though the the low code aspect seems attractive, flow designers can't determine the previous and current value of a field, like business rules. Flow designer is not a replacement for business rules, as Bert_c1 said it is intended for replacement of legacy workflows. Although there are some features that I like about flow designer like the dynamic flows, decision table,etc. I feel the usage of flows or BRs really depends on the use case and the complexity of the task. It is also a matter of preference like say if you have a very straightforward logic and like scripting, you would naturally prefer BRs over flow designer.
So for me, I'd use BRs for straightforward server-side logic and flow designer where I have to deal with multiple actions, conditions, and branching logic.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-09-2024 12:42 PM
Thank you for your input. Very valid points.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2024 05:18 AM - edited 12-09-2024 02:33 PM
"
@MS12 wrote:
... No debug capability to stepping through code, no code search....
Flow Designers debugging capabilities are FAR more thorough and FAR more accessible than those provided by business rules. I'll die on this hill. The fact you can see every value of every variable input and output in a given flow execution without dealing with logpoints, breakpoints, or manual logging statements is the difference between driving a race car and a tricycle.
There are a few cases where Business Rules are still absolutely superior though:
1) ON BEFORE
Flow designer isn't yet capable of this.
2) SUPER HIGH VOLUME
Since I believe there's licensing implications on number of flows run, I usually rely on business rules when I'm dealing with something extremely high volume: like business logic on Incident update. That might trigger thousands of times a day, vs dozens.
EDIT: I've been corrected on this. No rate limiting for flow designer, but some licensing may be in place for Integration Hub.
