ServiceNow Performance & Slow Forms?

[Matthew_13]

I’m a bit against the wall about when to use Flow Designer versus Business Rules in ServiceNow.

As Flow Designer keeps getting more features....., I find myself wondering whether it should be the default choice for automation now, or if Business Rules are still the better option in certain situations. I’ve used both, but sometimes it’s not clear which one is the right approach you know.

I’m curious about these 4:

1. When does Flow Designer make more sense than a Business Rule?

2. Are there cases where Business Rules are still the recommended or required solution?

3. How do they compare in terms of performance and long-term maintenance?

4. Is Flow Designer meant to replace Business Rules eventually, or are they designed to work together?

I’d really appreciate hearing how you decided between the two in your projects and any best practices you’ve learned along the way.

Thanks Community!!

[OlaN · Accepted solution]

Hi,

I would say that one of the main factors in your decision should be scale.
Flows are quick and easy to use and configure, and can handle most cases just as well as a business rule.

That said, there is a considerable overhead in using Flows, so if you're looking to automate on a very large table with very many operations happening and many users manipulating records (that would trigger Flows) then I would say that you should stick to business rules to streamline performance.

And of course another factor is that Flows can only react to when operations already happened, so business rules that run before record commit still have a place because that's the only way to automate before the record gets saved. All Flows runs after (async).

[OlaN · Accepted solution]

Hi,

I would say that one of the main factors in your decision should be scale.
Flows are quick and easy to use and configure, and can handle most cases just as well as a business rule.

That said, there is a considerable overhead in using Flows, so if you're looking to automate on a very large table with very many operations happening and many users manipulating records (that would trigger Flows) then I would say that you should stick to business rules to streamline performance.

And of course another factor is that Flows can only react to when operations already happened, so business rules that run before record commit still have a place because that's the only way to automate before the record gets saved. All Flows runs after (async).

[Matthew_13 · Accepted solution]

Thanks for sharing this!

I completely agree scale is a huge factor when deciding between flows and Business Rules. Flows are super user-friendly and great for most automation, but for high-volume tables or scenarios where performance is critical, Business Rules are often the safer choice.

Also, your point about timing is key: pre-commit automation still requires Business Rules, since Flows only run after the record is saved. It’s a good reminder that both tools have their place depending on the use case.

Thanks for sharing my friend!

[OlaN]

Hey Matthew,

Thanks again for your feedback, and I saw that you did the same thing here as in your other thread.

You've marked your own reply as correct... a mistake perhaps? 😀 

Please mark my previous reply as correct if you feel like I've answered your question. Thank you.