I’ve been asked to talk at a ServiceNow User Group about Flow Designer so I’ve had a bit of a think about what sort of Flow Designer topics might be interesting.
Something I try to do every time I create a system is look at ways to make it extensible from the get-go. With any sort of solution you’ll often be asked to meet a particular business need or process, but you can almost guarantee that most processes you might create are going to either change or have variations or “what if” scenarios.
One of the principles I try to keep in mind with Flow Designer is “Subflows first” – meaning that when I think about a “thing” I might need to do, I will try to build the smallest part of the logic first and THEN wrap it in a trigger. Quite often when I use Flow Designer my actual Flows are very very lightweight – in many cases the Flows will just be a trigger that passes the attributes of the trigger (the record object for example) immediately to a Subflow. I try not to overload my flows with too much logic and let my Subflows do the work.
Another principle I stick to is whenever there’s any sort of decision I try to make it data driven. One of my favourite features of ServiceNow is the Decision Table/Decision Builder system. It’s a great way of making sure that any “if / else” logic is stored in a decision table that can be modified easily in data rather than by modifying the structure of the flow. When you use Decision Tables in concert with another little-known feature of Flow Designer called Dynamic Subflows you get this really powerful combination where you can create a Flow system that is very flexible and future proofed against increasingly complex process behaviours.
For example I might have a process that is initially based on the fact that I have three different customers, and each has a slightly different process. In a simplistic world I might have written a Flow that has a hard-coded IF block that triggers one of 3 different subflows depending on the customer selected. In future when I get a fourth customer, maybe I’d add the fourth Subflow, and modify my flow trigger to have fourth option.
However as this starts to scale it gets more complex. Lets say I have a dozen customers and half of them have unique processes, but the rest are happy to use similar processes to other teams. At this point my If block in the flow is going to become more complex – customer A, B and C all use subflow X, Customer D uses Subflow Y, Customers E and F use Subflow Z, etc.
This is where Dynamic Subflows come in – this is a flow action that allows you to call a subflow pattern and pass a data pill that contains the name of the specific Subflow from that subflow pattern you want to call. So instead of having an If block outcome for each Subflow call that has the Subflow called specifically you can instead have a single action that calls a subflow that your flow logic has determined by name.
You can see how this might be benficial if you can use some form of logic to determine what subflow name you wanted to call. How can we get names dynamically? Well, that’s where Decision Tables come in! A decision table is basically a collection of conditions based on a set of inputs that will give you an output. For example you might send your “company” value to a Decision Table that you’ve set up, and you would have one or more decisions that have conditions based on the company input. The output can be any record in the system (for example a Subflow record….). Thereforem My condition might be “Company = Company A” and it might have an output of “Subflow X”. My conditions can even be complex – “Company = Company A OR Company B OR Company C” and the output might still be Subflow X”.
Decision Table logic all takes place outside Flow Designer – this complex decision logic can be completely removed from my flow and the logic ends up being just 2 actions instead of dozens of actions. By sending the output of the Decision (e.g. the Subflow record) then my Dynamic Subflow action can simply receive the name of the chosen Subflow and it will execute whatever logic is required based on the common inputs from my main Flow.
In order to demonstrate this for the SNUG I’m going to be creating a clone of the Mobile Game Marvel Snap. Marvel Snap is a good use-case for Dynamic Subflows because each card you can play has a unique behaviour that needs to be executed. These can all be defined as Subflows for each card, and the underlying flow can determine when the card logic should be called (using Decision Tables based on the fundamental execution order rules of the game), and which card rule should be executed (using Dynamic Subflows).
I’ve found an API where I can import all the cards into my instance into my Card Database, but I’ll still need to create all the Card Subflows one by one. I’m wondering whether there’s a way to use ServiceNow’s Generative AI to help interpret the card description within the context of my system, but I suspect that might not be as easily done as I suspect. We’ll see how far I can get!
I’ll be pushing all my updates to the app to my GitHub Repo where I’m calling it “Marvel SN App”, so if you’re interested you can grab a copy or maybe even suggest some improvements: https://github.com/milligna/Marvel-SN-App
0 Comments