Workflow Automation CoE > Decision Builder > Dynamic subflows with Decision Tables
Goal
In this Workflow Automation Center of Excellence article, you’ll learn how to use Decision Builder with the Dynamic Subflows flow logic.
Technology and Use Case
Decision Builder allows us to extract complex logic from our business logic. When paired with dynamic subflows, we can decide which subflow to run while our main flow is already running.
The main benefit of decision tables and the template flow we’re creating is that it makes this use case extensible. If we need other (sub)flow variations under different circumstances in the future, all we have to do is make another copy from the template flow and add a row to the decision table. In addition, utilizing a purpose-built tool to extract the complex logic about which subflow to run can streamline your main flow, making it easier to maintain and understand.
For this article, I want to send a notification through a different channel based on a user’s department.
Note: To enable the dynamic subflow flow logic, all subflows must have the same inputs and outputs. To help with this, you can create a template flow with the relevant inputs/outputs from which each subflow will be copied.
This logic pattern can also be used to facilitate other dynamic subflow use cases, for example:
- Calling different third-party endpoints (test server/production server) or using a different MID-Server based on the instance the flow is executed in (sub-prod or production instance)
- Provisioning instances on different cloud systems (AWS, Azure, Google, etc.)
- Initiating different approval processes and fulfillment flows based on request information
Instructions
To achieve our use case, we need a couple of components. Let’s look at them one by one.
- Template subflow to determine inputs and outputs
- Copies of the template subflow with specific logic and actions to be executed
- Decision table with conditions to decide which subflow should be executed
- Flow or Subflow that
- runs the “Make a decision” logic
- dynamically runs the subflow from the decision results
- gets the subflow outputs
- executes further logic and actions as needed
Here’s what the finished subflow will look like:
Step 1: Subflow template
Create a new subflow and give it a name to quickly identify it as a blueprint for subsequent subflows for the same use case (e.g., name starts with ‘TEMPLATE: ‘).
Define the inputs and outputs and add some example logic and actions. The inputs used are Subject (String), Recipient (Reference: User [sys_user]), and Message (String). The output for this simple use case is a true/false field for the success state of sending each message, but this could, of course, be more specialized for your use cases.
Publish this subflow.
Step 2: Copy the template for specific subflows
To create a copy of the template, click on the three dots in the top right corner of your Flow Designer. Click “Copy subflow” and supply a name in the open modal.
For this article and use case, I have created three subflows. One will send a message to a channel in MS Teams with a webhook. The second will send a message to a Slack channel, also via webhook. The third will send an email directly from the flow.
In each of these, we’re using the input data pills to generate a message and set the subject depending on the individual notification action options.
Based on the success state of the message action, we’ll set the value of the subflow output ‘Success’ to true.
Subflow 1: MS Teams
Subflow 2: Slack
Subflow 3: Email
Step 3: Decision table
It’s decision time! From your main ServiceNow tab, search the Navigation for “Decision Builder”; this will open in a new tab. Create a new decision table based on your use case requirements.
Note: Learn more about how to get started with Decision Builder in the Workflow Automation CoE or watch our latest Platform Academy session with Julia Perlis. For some hands-on experience, you can complete this year’s CreatorCon Lab on Now Learning.
For this example, I created a decision table with a reference input on the User table [sys_user], then built conditions based on the Department column on the User input.
As you can see here, it’s possible to have more than one result column. Since I want the message to contain some dynamic text based on the decision, I added a Reference column for the (sub)flow table [sys_hub_flow] and another of the type String.
The individual rows will be evaluated from top to bottom. When calling the decision table from Flow Designer (or script via the DecisionTableAPI), you can decide whether to stop at the first row that matches or return all rows that match.
Step 4: Combine!
Now we’ll put all our pieces together, which can happen in a flow or subflow. The main difference is either having a specific trigger or making the logic reusable in a subflow with inputs and outputs. For this example, I’m choosing a subflow with an Incident [incident] reference record as the input. From there, I can get to the ‘Caller’ (or ‘Assigned To’ or other user reference field) as the notification recipient and have access to record info like the ‘Number’ or ‘Short Description’ as needed.
First, we’ll use the flow logic “Make a decision” to determine which channel the notification will be sent to, with the ‘Caller’ as input for the decision table. In this example, we don’t want to use the branches and only run the subsequent logic for the first decision that matches. If you’re going to run this for all rows that match, you need to insert a “For each” flow logic next and iterate through the result array.
Second, we’ll use the flow logic “Dynamic Flow”. To gain access to the subflow inputs, we must choose one of the subflows that are part of this process, but the most robust way is to use the template.
Check the box to ‘wait for completion’ because we want to use the subflow outputs in the following steps.
Set the flow as the Decision step result column with the subflow reference.
The remaining dynamic flow inputs are being set with data from either the (parent) subflow inputs or dynamically from the second decision result column.
Third, we’re retrieving the subflow outputs with another flow logic component, aptly named “Get Flow Outputs”. We’re choosing our flow template again and using the Context data pill from step two.
How you proceed with your logic from here depends on your use case, I added a quick “If” statement to check for the message transmission success and can run more actions from there.
Step 5: Test
Finally, we get to test the flows we built! To test an example for each possible decision table outcome, I’ve created 3 Incidents. One with a Caller in the IT department, one in Sales, and one in the Development department, which has no dedicated row in the decision table and will be covered by the default result.
Example record:
Example flow execution:
Test results:
Conclusion
Success! Our tests executed as expected and received the right notifications in the defined communication tools. Let’s take a final look at the complete flow with the decision table, dynamic flow, and getting the flow outputs. Extracting these decisions into Decision Builder allows developers to grant the decision ownership to the process owner to add further rows for other departments as needed without touching the main flow logic again. Additional subflows can be copied from the template, ensuring they have the right inputs and outputs. This allows for this process to be endlessly extensible as needed.
Learn more about how to get started with Decision Builder in the Workflow Automation CoE or watch our latest Platform Academy session with Julia Perlis. For some hands-on experience, you can complete this year’s CreatorCon Lab on Now Learning.
