A realistic analysis of Flow Designer

In the Kingston release (I think – it’s hard to find the exact history), ServiceNow debuted “Flow Designer”, ostensibly a newer and better way of creating automated workflows. The idea being that the Workflow engine was coming to the end of its useful life, and the platform needed an upgraded way to automate processes and give more power to non-developers and non-ServiceNow admins. Ostensibly fulfilling the marketing pitch of “Citizen Developer”.

I’ve begun working with Flow Designer and completed the primary micro-certification. After both studying Flows and using them in the real-world, I’m struggling to “get onboard” with either the marketing or the reality of using them. Despite my rapidly advancing age, I try to keep an open mind about these things and, when I get frustrated, stop to think, “Am I approaching this from the wrong angle? Am I missing something obvious? Am I too set in my ways?” However, after this experience and these considerations, I have several observational concerns about Flow Designer:

The Flow UI does not align with how humans visualize processes

Flow Designer is a linear, top-down graphical model. Step 2 follows (falls under) Step 1, Step 3 follows (falls under) Step 2, and so on. While I think this is fine for very basic logic flows, rarely do business problems get solved with very simple rules with a handful of steps. Rather, when humans gather to map out business flows and determine what and how many paths are needed to arrive at the solution, or at least the conclusion, they draw them on the whiteboard like this:

At least they have in my experience. In other words, they draw flowcharts, which can and often do incorporate lots of divergent paths. These are both hard to visualize and to build in Flows. In fact, it’s almost laid out in pseudo-code fashion.

This is how an actual flow appears:

I’ve seen flows in the real world where an else comes 30-40 steps after its corresponding if, making it quite difficult to visualize as a lot of scrolling is required to see the complete block. And although I’ve heard this is coming, you can’t easily do branches or rollbacks. You simply have to keep adding and nesting steps.

I was recently working on an integrated request application where we were having lots of issues with the Flow because it was almost 140 steps, making it hard to visualize and troubleshoot the end-to-end. I suggested we try a Workflow alternative, and not only were we able to reduce it to less than 30 activities, but when the customer saw it using “Show Workflow”, they immediately said “Oh, this is much easier. I can understand this.”

Flow Designer takes longer to develop and deploy

In my experience, developing the same solution in Flow Designer takes longer than in Workflow Editor, and not by a small amount. When I’ve been working with project teams that are attempting to build solutions in ServiceNow using Flows, and I estimate time to complete using my 12+ years of ServiceNow experience, I’m always underestimating the level of effort, because I’m basing it on how long it would take using a Workflow. Here are a couple of more specific examples:

• When I was trying to “do the right thing” and learn Flow Designer, I went through the micro-certification course. One of the learning activities was to create an approval. After finishing 20 minutes later, I thought, “this is supposed to be easy?” Here’s ServiceNow’s documentation on it: Flow Approval. I realize it has flexibility, but if you want a simple approval, why all the hassle? Conversely, in Workflow, you add an Approval activity, add the approver(s) to it, and draw the lines out of Approve and Reject. This can be done a few minutes or less.
• In a recent project, there was an integration to Service Request and Hardware Asset Management that used a Flow to manage the lifecycle of the request. The Flow was over 130 steps. After nearly a year of trying to resolve all issues and go-live, and after HI Cases to figure out why the flow wasn’t working, we scrapped it in favor of a Workflow. The Workflow was less than 30 activities and was deployed in less than 4 weeks.

Part of the marketing pitch is that Flows can be built as small, standalone chunks of work that can be called from other Flows, allowing for quick build of these standalone chunks of work. I see problems with this idea:

1. Having the knowledge and intelligence to logically break the Flows into the correct smaller Flows is quite difficult, particularly for folks who do not come from or have a design background.
2. Managing lots of Flows and being able to piece them together into a workable Top-level Flow with Subflows is also challenging. It’s like dumping a series of Lego™ sets on the floor without the instruction sheets and trying to piece together coherent models. It’s technically possible, but unlikely and frustrating to-boot.
3. If you are able to build the Flow, testing and debugging is harder because you have to drill into subflows to see where the issue may occur. I’ve also found that it’s not super easy to see what data is passing back and forth between the subflows and the calling Flow.

Given these, I haven’t found that non-developers can easily design and build these the correct way, if at all. As I mentioned in one of my examples, I get pulled into troubleshoot a Flow that’s well over 100 steps, because the original developer couldn’t logically factor it into manageable subflows.

Flow Designer is a code-replacement tool that requires code to make work

If you think about what a Flow is, and how it is built, it is essentially a complicated code-replacement tool. Think about data pills – these are graphical dot-walks, and workflow variables. All this is wonderful if you can actually have non-developers creating viable Flows, which is the advertised benefit. I have yet to see this actually happen in reality, for the reasons I’ve mentioned thus far. Here’s another reason: In my experience, when Flow steps don’t work as expected, and there’s not an obvious reason why, the solution is usually to open up the script editor in the Flow step and write the equivalent script to what the flow should be doing without script. This negates the ability for non-developers to create them, or at least to make them production-ready. My experience has been teams using Flows can have less senior folks put together a framework, but require senior developers to actually get them in working order.

Conclusion

My straw polling amongst my peers and teammates is that no one finds Flows easier to use than Workflows, and many either shrug and say, “Well this is what ServiceNow is telling me to do”, or, “This is what I learned in training”. My educated guess is that Flow Designer was introduced to ServiceNow by an executive with enough clout to push it through as a viable Workflow replacement. I’d also guess it was purchased rather than built. After attempting to work with it for the better part of two years, my conclusion is: “Why?”. Why am I compelled to use this product? Why was Workflow scrapped instead of being upgraded?

I’m fairly certain that putting some development heft behind Workflow could have made it more powerful and more flexible, rather than leaving it as is for a more complicated, less useful tool. Until someone who knows tells me that there’s a technical reason Workflows had to be scrapped, or a technical reason I shouldn’t use them (rather than “marketing” reasons), my conclusion is that for the foreseeable future, unless there’s a pre-built Flow that does exactly what I need, I will continue to build in Workflows until I can’t.

Develop based on what you know, not what you’re sold