Workflow Automation CoE > Flows > Flow and Action Error Handling > Level 4: Good Practices and Summary
Overview
Now that we’ve got all the necessary pieces and tools, we’re prepared to create robust flows, subflows, and flow actions. But there’s still more that you can do to make your own future developer life easier or to be nice to those who follow in your footsteps in the future! In this chapter, we will look at some recommendations and guidance that you can implement in your teams to make debugging and root cause analysis a breeze.
Naming and Categorization
When you build reusable actions and flows, remember to give them human-readable names so they’re easier to find when building flows and subflows. Be sure also to name inputs and outputs properly, assign a default value for testing, or just the most common value that will be picked to speed up usage later.
Remember that actions and subflows can be categorized for better discoverability. This is especially useful for application spokes containing multiple actions or subflows. Similarly, a speaking description and annotation will help people choose the right action or subflow for their use case. Increased discoverability also prevents duplicate efforts since you don’t need to recreate existing logic.
And while on the topic of naming, this is probably one of the most overlooked small but useful things: you can rename action steps, which is especially useful if you’re using multiple action steps of the same type.
Annotate your (Low) Code
This tip is likely well-known, but it bears repeating: Annotate your code!
This goes for flows just the same as for scripting. However, make sure to make your annotations meaningful and don’t just repeat the action or flow name. Annotations should always ADD value. With the November Vancouver Store update for Flow Diagramming, annotations and step details are also available in diagram view (Version 24.3.2).
Scripting in Flows
Lastly, some notes on the topic of scripting. As a general rule, we recommend using inline scripting as scarcely as possible, as it’s the least discoverable way to build flows and assign or transform values.
Did you know? You can even deactivate it entirely with a system property. You can set it from the overflow menu of any flow or subflow and then Flow or Subflow preferences to toggle it on or off.
If you need to transform a data pill when assigning a value, use transform functions when possible. These can even be stacked on top of each other! These are best used to transform strings or date time fields.
One of my favorite stacks is to use Split on a comma, dot, or colon, and then under Utilities, you’ll find transform functions to get the first or last item in that resulting array. This way, you can extract a user name from an email address (the first item in an array split at the @ symbol) or get the last part of an IP; the options are endless. There are even transform functions for basic math, like getting an average or median for an array of numbers.
Scripting in Actions
When you create custom actions, the script step is very useful if you need more than the existing action steps to cover your use case. We still recommend not letting individual scripts grow too large; it’s better to break them up into logical parts. You can also leverage existing script includes, especially to surface those useful Util functions that every organization creates and make them discoverable and usable in flows and subflows.
And, of course, Now Assist Code Generation and Code Completion are available in action script steps, too!
Conclusion
In summary, you should consider these three key points when building flows and flow actions:
- Build your error handling bottom-up and catch them as early as possible
- Use the Try flow logic to catch errors and loop with do until or go back to until you get a successful execution
- Use flow error handler to notify relevant stakeholders and run subflows to remediate before re-execution
