Flows are not for everything

[Michael Fry1]

For any new process flow requirements, ServiceNow recommends using Flow Designer over the legacy workflow for almost all circumstances. Well, starting with the Zurich release, we can remove “almost” from that sentence given ServiceNow will no longer be shipping new instances with Workflows.

I, myself, have been using Flow Designer for years. I disliked it in the beginning. Maybe because I was relucent to change but over the years, I find building new Flows to be quick and easy. While I encourage my teams to use Flow over other scripting methods, there are some circumstances that you can’t or shouldn’t use a Flow.

Flow Designer and Business Rules:

You should use Flow Designer instead of Business Rules unless:

• Business logic needs to run in a specific sequence with other Business Rules. For example, new business logic needs to run after one Business Rule but before another.
• Logic needs to execute immediately before or after writing to the database in the same thread.
• The logic only calls a Script Include.

When designing a flow, follow these design principles:

• Single Purpose: Each flow should have a singular goal.
• Reusability: Design with reusable sub-flows in mind (approval is a great example). New Actions should be built in a way that they are reusable as well. I realize that’s not always possible. Many times, we need to use sub-flows to avoid hitting the default limit on the number of Actions that can be added to a flow. Increasing that default might cause performance issues.
• Clarity: The language and layout of a flow should make each action’s purpose clear. One simple way to bring clarity to a flow? Annotate each step! The next developer that picks a change to this flow will deeply appreciate you doing that. I fail code reviews for missing annotations!

Bottomline: Workflows are out, and Flows are here to stay. Get used to the most common Actions and you too will be building Flows quickly and correctly.

Thanks for reading!