As a development lead, I have had the pleasure of reviewing many a flow, usually created by developers who are either new to Flow designer or have recently migrated from using Workflow Editor.
Here are the top 6 mistakes that I see.
- Using ‘Get Catalog Variable’ action too early
This is the number one most common mistake that I see people make when creating flows for Catalog items. I’m yet to come across anyone transitioning from using Workflow Editor to Flow designer for Request item workflows who hasn’t made this mistake, myself included.
The ‘Get Catalog Variable’ action gets the variable’s value when the action is executed. It is a common sight for a Service Catalog flow to begin with a ‘Get Catalog Variable’ to get variables populated by the user of the form to determine approvals and the logical order of tasks.
It is not helpful for getting the value of variables that are completed by fulfilment teams later to determine further logic in the flow. When the action is used before the variable is populated, the variable will return empty, since it wouldn’t have been populated at that point in time. The ‘Get Catalog Variable’ action must be used just in time, that is just before you need the value. - Not using annotations enough
Many actions in ServiceNow don’t describe much about what the action is actually doing. For example, ‘Create Catalog Task’ doesn’t give us any context about the task, only that a Catalog task record has been created.
Do your future self (and other developers) a favour and take the time to write simple annotations to explain your flow actions. Just like a coder comments code that requires further explanation, you should consider doing the same – whether you are a no-coder, low-coder or pro-coder. Just see the difference that a couple of annotations to ‘Create Catalog Task’ and ‘Requested Item Notification’ can make.
- Using Subflows too little, too late
There are so many good reasons to create Subflows, but they do not get used enough.
A good programmer writes code in functions not only for reuse but also for unit testing. The same principle can and should be applied to creating Flows. Creating a subflow allows you to easily test smaller components of your overall flow, with the added bonus of being able to reuse it in other flows.
Before Flow designer existed, when advising developers on using Workflow editor, I used always told them to aim for “workflow on a page”. The same principle can be applied to Flow designer – try and make your flows readable, end to end, without having to scroll down. Use Subflows to reduce the screen real estate required for a user to understand your flow.
Going back to Workflow editor again – all workflows could be called by all workflows, but a flow cannot call any other flow, making them less versatile. That is unless we change the way, we think. The only real difference between a Flow and a Subflow is that Flow has a trigger. So think of the Flow as being the trigger, and your actions just being one or more Subflow. Shifting your mindset to using Subflows will add versatility to your flows.
And if you leave it too late – Flows have a default max limit of 50 actions. - Not moving code to custom actions
While Flow designer lets us automate business processes without code, sometimes we need to write a line of code here or there to perform logic that is not supported in existing actions. It is often tempting to use the inline code editor to write a sneaky line of code to accomplish your goal.
Create an action with your code instead. This will allow citizen developers to reuse your code without needing to write code. It also promotes re-use and brings your solution to the surface when picking an action.
Confused as to when you should create a custom action vs a Subflow?
If you need to write any code, create an Action.
If you need to refactor/re-use some of your existing actions, create a sub-flow. - Leaving full logging on
Flow logging is controlled by the System property com.snc.process_flow.reporting.level (or by navigating to All > Process Automation > Flow Administration > Properties) and is disabled in production by default on the new implementations. You’ll know it’s disabled if you see this message:
Don’t be too hasty to re-enable this property; according to the article Flow Execution Details When Flow Reporting (com.snc.process_flow.reporting) is turned OFF/ON by ServiceNow, caution is advised. From the article:
“Our suggestion is to keep the global reporting property off in production.“
“Flow reporting requires us to keep a lot of data about flow executions in memory and then in the database after flows goes to waiting or completes. Our intention is to reduce performance issues related to flow reporting. When memory issues happen they are very serious and will likely lead to P1 customer cases.“
There might be some instances where you want users to be able to view flow contexts as part of workflows to understand the current and next action. In this circumstance, you could cautiously consider enabling flow logging for that particular item in flow settings.
Enabling flow reporting is recommended in development. Make sure you have a data preserver in place to retain this property value after cloning from production. - Using the Send Email Action
There are much better alternatives than using this ghastly action. The Send Email Action lets you specify a record, sender details and an HTML body. All things you can otherwise do using a Notification record, without the additional controls and features (such as templates and email layouts). But did you know there is an Action to send a Notification?
The Send Notification Action allows you to specify a record and trigger a notification. You can select any notification for the table of the specified notification that has a ‘send when’ of Triggered.
Alternatively, you can use the Create Record action to create an event on the sysevent table to trigger a notification fired by an event.
If you can’t choose the sysevent table, you’ll need to add it to the sn_flow_designer.allowed_system_tables System Property.
Thanks to Mark Roethof for contributing this idea.
For a list of best practices please refer to the NOWsupport best practice series post on Flow Designer
2 comments
Few more I can think of that can be done are
1. Adding stages… stages give a very good insight into how the where the flow is currently during execution.
2. Implement error logging
3. Avoid FD objects in script, when you do that if any new step is added in flow then you need manually go and those references to FD objects in scripts as ServiceNow doesnt automatically fix it.
4. Avoid using very complex / long running scripts (even if its via action) as that will leave lot of flow event handlers unresponsive and in active transactions, which cant be cleaned up easily.
Great tips, thanks