Dave Slusher

3 minute read

As Flow Designer gets more real world use, the feature set continues to evolve towards the needs of production customers. In the London release, one of those features is Subflows.

By its nature, Flow Designer is pleasingly fractal in nature. You build a Flow out of Actions. When you drill into Actions, the UI looks almost the same as the Action Steps build into the Action. Subflows are another layer of this fractal, allowing for reuse by building a piece of a Flow that can be reused in multiple Flows or even across the same Flow.

The use case for a Subflow is when you have a series of actions that are frequently repeated and you don’t want to set up the repeated chunks of Flows multiple times. For this example, I’ll present a case where given an Incident record and a message, it will be added to the work notes and also optionally sent out to a few notification channels.

Create a Subflow

First you create the Subflow, which is an option under the “New” button of Flow Designer.

Configure a Subflow

Set up inputs for a Subflow

Next you name it and provide the inputs and outputs just as one does for Actions and Flows. The inputs can each be set as mandatory or not. In this example, there are a few of each types. An Incident record and message are required but the remainder are optional.

If Slack webhook url is populated

Then post a message to Slack

For this example Subflow, based on the Incident record and the message input, the record will be updated to add that message to the work notes. In addition, if either the Slack webhook or Microsoft Teams webhook inputs are populated, then it will send a message to that destination.

Setting up Subflow within a Flow

Once the Subflow is created, it then becomes available for any Flow to add. For our simple example, when an Incident has a change to the short description field then it will trigger the Flow. Passing in a Slack webhook will then send it down that branch to post to Slack. In this way, the same building block can be reused in a number of different Flows.

Final results of running the Flow

Slack message in the workspace

This example is simple, but imagine a much more complex set of business logic. Rather than set up the same series of actions and logic, it can be built a single time and then reused throughout Flows. If there is a change to the logic then that will be carried over automatically to everything that uses the Subflow. Similarly to Actions and Flows, after editing the Subflow there is a step to activate. Upon activation, subsequent invocations of any Flow that uses the Subflow will pick up the new version.

As your library of business logic builds up in Flow Designer, consider which pieces may be reusable. If you begin to see patterns of Flows that are repeated, these are good candidates to be refactored into a Subflow. There is no reason to re-implement the same series of steps when it can be done a single time.

If you haven’t already explored the London features such as this one, claim your own London PDI and have a look around for yourself. Happy developing!