Best practices for using the Flow Designer

[Dawn Jurek]

At ServiceNow, we’re driving innovation by empowering you to automate your organization’s processes. With the Flow Designer, new in Kingston, even non-developers can easily build and test flows to automate approvals, tasks, notifications and record changes. In this installment of our NOWSupport best practices series, we cover some best practices to help you jumpstart your development in the Flow Designer. To learn more about getting started with creating your own flows and actions, first check out these videos from our NOWSupport YouTube channel:

And now for the best practices:

Leave base system actions and flows intact to get future updates

One of the advantages to using the Flow Designer is that it provides a library of reusable actions and flows to leverage for your own development.

To use a base system action or flow, open it, click Copy, enter a new name, and customize the copy of the original. This way, you’ll receive the changes that ServiceNow publishes to the original flows and actions in the future.

Always build an action or flow within a scope – but not the Global scope

Before you begin creating a flow, create a custom, or scoped, application for the content to reside in. You can do this in the Studio IDE by navigating to System Applications > Studio…

…or the Develop tab in the Applications page:

Generally speaking, a scope is like a namespace for your application. Everything in your application falls under this namespace. It separates your classes, tables, and UI components from everyone else's; it gives you control over their names, how they can be accessed or extended by others, and keeps your code from accidentally polluting the global namespace. 

Also, creating your Flow Designer content within a custom application allows you to publish it to the application repository, making it available to all other instances in your organization, or you can publish it to the ServiceNow Store, making it available to everyone.

Create simple, small components with simple names

When developing components in the Flow Designer, think simple, small, and reusable. Why? It’s easier to troubleshoot issues when each component in a flow is small, and you can reuse these components in multiple flows. Here’s our component-specific tips:

Flows

• Break big flows into smaller reusable chunks using subflows, which are a new feature of Flow Designer in the London release.

Actions

• When developing actions, keep them simple (just a few steps). If your action is more than a few steps, consider creating a separate action for each logical piece.
• Create reusable actions with simple, human readable names to hide the complexity of record lookups, record details (fields), the ServiceNow data model, and complex scripts.
• When actions get complex, create subflows, which allow you to string together actions into more complex reusable processes.

Script steps in actions

• When using script steps in actions, each function should be in its own step.
• Script steps should be only 20 lines or less. If the script is larger, consider breaking in into multiple logical steps.

Use IntegrationHub to handle authentication

Rather than passing user names and passwords through flows and actions, leverage IntegrationHub to handle credentials and authentication. IntegrationHub enables execution of third-party APIs as a part of a flow when a specific event occurs. (Note that IntegrationHub requires a separate subscription.)

Understand the difference between the Run Trigger options 

When you’re building the trigger for a flow to run when a record is Updated, or Created or Updated, you need to select a Run Trigger option: Always or Once. By default, this value is set to Once.

 

This may seem straightforward, but with the Created or Updated trigger this can get tricky depending on the conditions you set in the trigger. Keep in mind that when you’re testing the flow in the Flow Designer interface, the trigger is ignored, which leads to our next best practice:

Understand how the Test button works in the Flow Designer interface

You can test your flows directly in the Flow Designer, via the Test button. When you click it, the flow runs, no matter what, meaning that the trigger is ignored and the test begins executing the actions. So, if there’s an issue with the trigger, you won’t know until you’re testing it outside of the Flow Designer interface.

This leads into our next best practice for development in general:

Never develop or test on a production instance

In a previous post, we discussed why you shouldn’t develop on your production instance. The same is true for testing – the Test function in the Flow Designer provides a handy interface for troubleshooting, but you need to perform tests on a test instance, never on a production instance. Why? Actions that create something, such as a new record, will not roll back after a test run in the Flow Designer. The item will remain in the instance as an artifact of the test. Also, other record changes and integration calls performed in the Flow Designer are real. So, after troubleshooting your flows within the Flow Designer, promote them to a test instance for testing with viable data.

If you haven’t already, take advantage of the Automated Test Framework (ATF) to automate your testing. To learn more, see our post Best practices for using ATF.

If you move actions around, double-check the data references

Flow Designer allows you to move actions up and down within the flow, so that you don’t have to reconfigure an action if you realize it’s in the wrong place. But if you do this, verify that any data referenced in the step is still pointing to the correct source.

Here’s an example from 03:30 – 04:25 in our Flow Designer | Editing and Testing an Existing Flow video:

And finally, our last tip comes straight from our product documentation:

Don’t create conflicting logic with business rules and workflows

While learning Flow Designer, make sure that you understand how existing Now Platform automation processes such as business rules and workflows change records to avoid creating conflicting logic. See the Architecture Overview to understand how Flow Designer works within the Now Platform. If you are replacing an existing automation process, you may need to deactivate it before replacing it with Flow Designer flows and actions.

For more information:

Flow Designer (product documentation)

Application scope (product documentation)

Create a custom application (product documentation)

Automated Test Framework (product documentation)

Background and Philosophy of Scoped Applications

Scoped Applications - Introduction

Application Development - Best Practice #1 - Work in a scope

Exploring Flow Designer and IntegrationHub - Live Coding Happy Hour for 2017-11-17 (video on ServiceNow Dev Program YouTube channel)

---

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you’d like us to cover in this series, please let us know in the comments below. To access all of the blog posts in this series, see our NOWSupport best practices series list.