Search for a command to run...
How to Choose the Right Tool Over Flow Designer
I am a technical architect and ServiceNow enthousiast. Since then I have been obsessed with development and later on application design & architecture. Today I'm using my skills to design solutions for IT companies within the ServiceNow industry whilst in my free time, spent the majority of my time creating applications for all kind of things unrelated to ServiceNow.
No comments yet. Be the first to comment.
What is the ArchX program? The ServiceNow ArchX program, a 4-week cohort-based program built by ServiceNow for early-career architects. The program aims to teach students how to excell in the world of
Today I successfully passed the ServiceNow Certified Implementation Specialist exam for Customer Service Management. In this article, I will be sharing my personal experience with the preparation, the training material provided by ServiceNow, and my ...
For developers, adopting coding habits is crucial to increasing productivity and enhancing the maintainability of their implementation solutions. This article will cover 5 must-know skills every ServiceNow developer should master. 1️⃣ D.R.Y (Don’t ...
Learn the Best Situations for Scoping and What Needs to Be Scoped
Understanding ServiceNow's Conditional Table Query Range ACLs
I am often associated with someone who "hates" flow designer. To be quite honest, no, I don’t hate flow designer. I do believe that flow designer was a great addition to the ServiceNow platform, if not the best in the past few years.
So, what is it that bothers me about flow designer? To understand that, let's first dive into why flow designer really made a difference.
Flow designer offers a very intuitive design, allowing even the most non-technical people to build simple flows. The drag-and-drop mechanics and the visual aspects in flow make the process of setting up flows very quick.
The drag-and-drop pill mechanics are easy to understand and make the process of automating your workflow like a walk in the park. The return types are neatly displayed next to the data pills, making it very clear which data pills should be used.
One of the main benefits of Flow Designer is, without a doubt, the “spokes.” Spokes are essentially the building blocks for integrating your workflow with third-party systems. Building integrations from scratch is very time-consuming and can only be done with extensive technical knowledge about both ServiceNow and the third-party application you are trying to integrate with. Thanks to the spokes, it’s just a matter of dragging and dropping the blocks in your flow and using the results to integrate them with your workflows.
Another great addition to Flow designer is the “executions” tab. This view literally represents a history of all your executions and allows you to easily monitor the data flows, making it an essential tool to troubleshoot misconfigured flows.
As mentioned earlier, all the things above have made a difference in how quickly we automate workflows, which is great. But ServiceNow has created a vision where every form of automation is always done through Flow Designer.
I remember an old video when Flow Designer was introduced by the well-known Chuck Tomassi, where he mentioned, “Script gurus, this is for you … stop writing code and use Flow Designer.”
Yes, Flow Designer is a great tool, and it does make automation extremely simple. But I don’t see Flow Designer as a replacement for everything. Back in the days when Flow Designer didn’t exist yet, we knew exactly where to look if something went wrong.
As a reverse engineering enthusiast, I gave multiple sessions on how to properly reverse engineer by applying a logical way of thinking and reverse-thinking the process.
Let me clarify that sentence using an example:
When submitting a new incident, the company field is automatically populated after the record is created.
So the logical thinking process would be: It runs on the Incident table, it happens after the record is created, and it automatically populates the company field.
Breaking it down:
| What is happening? | Company field is updated |
| Where is it happening? | On incident table, server |
| When is it happening? | Company field is updated |
So, applying the logical thinking process, we know where to look:
A business rule on the Incident table (insert true), with a script or action to update the company field (script contains company).
This simple technique was, in many cases, an effective approach to troubleshoot and reverse engineer errors. Now that flow designer has been introduced, this can also be hidden in a flow.
UI actions execute a piece of code when clicked on, except they can now also trigger a flow.
Just as covered in the series “SOLID Principles”, I do believe that applying the Single Responsibility principle does not only apply to code but also to the platform.
Business rules execute logic during CRUD operations of a record, UI actions execute code when interacting with clickable UI components, Assignment rules control the assignment, etc.
Having different artifacts, all serving their own purpose, is what keeps the platform maintainable. Having everything crammed into a single solution that covers all quickly shows its caveats.
Yes, definitely. However, finding the correct execution is what makes it challenging. Currently, the flow designer doesn't allow filtering by things like table, conditions, or actions, which makes it very difficult to locate specific tasks.
Flow designer serves a great purpose for automating a set of activities as part of a process, such as integrations. If you have a list of activities that need to occur in sequential order, a flow is what I would use.
But if the goal is to update a field after a record is updated, that is not a flow for me, but a business rule.
Although the flow designer is a great tool for automation, it's important to understand its limitations and the drawbacks of overusing it. If you decide to use it (and you should), ensure you have proper governance around the creation and maintenance of your flows.