How to Add Conditionals to Your Data Flow
In the previous tutorial, "How to Process and Transform Data", you learned how to take input information, manipulate it, and store it in your data flow's memory. In this tutorial you'll learn how to tell your process to make data flow decisions based on the information in your process data.
- The CHECK DATA action
- How to utilize IF / THEN / ELSE data flows
Let's Check our Data
Often your processes will require the ability to perform an action only if certain requirements are met. That is where the "Check Data" action comes in. This action allows the process to perform subsequent actions depending on if the data in the process matches the supplied criteria. The check data will always execute subsequent IF actions when the data matches the criteria. It will always run subsequent ELSE actions when the data does not meet the conditions.
With that quick explanation out of the way, let's add our first Check Data action.
First, you should find the place in your data flow where you need for your process to make a decision. If you want to follow along exactly with this tutorial you can add a Listen To Request action to your project with the following properties set.
Custom Endpoint Alias = /example-check-data Method = GET
After you've found where you need to add decision logic to your flow, click on the insertion node to add a new process to the flow. Then select "Check Data" from the Action dropdown. You'll be presented with the Check Data conditions menu as seen below.
Next, let's add a condition to this Check Data action. Click on the blue plus symbol icon in the section labeled "Add conditions that must be met to perform this action".
You'll see that each condition you add to the Check Data will have the four following properties:
Find Key In...
This field tells the Check Data action where in the process flow it should look for the Input Key. Unless you have a specific use case, it's probably fine to leave this value as "Anywhere".
- Anywhere | Look every place in the process data for the input key.
- Request Query | ONLY look in the query data for the input key.
- Request Body | ONLY look in the post body data for the input key.
- Header | ONLY look in the request header data for the input key.
This is the name of the key where you want to check the value.
This is the logical operator that determines how the process will compare the value of the input against the supplied condition value. The following describes how these operators will compare the data.
- Equals | The found key value must be the same as the condition value
- Does Not Equal | The found key value must be different from the condition value
- Less Than | The found key value must evaluate to a number and must be less than the condition value which also evaluates to a number
- Greater Than | The found key value must evaluate to a number and must be greater than the condition value which also evaluates to a number
- Contains | The found key value must evaluate to a string and have the condition value within it's contents.
- Does Not Contain | The found key value must not contain the condition value within it's contents.
- Exists | The key must be found in the process data.
- Does Not Exist | The key must be missing from the process data
- Is An Object | The found key value must be able to conform to an object definition. Specifically, it must be a record that may contain it's own properties.
- Is A Date | The found key value must be able to conform to an object or string definition that can be coerced into a valid Date object.
- Is an Array | The found key value must be able to conform to a list definition. Specifically, it must be a record that may contain an ordered and indexed series of data or sub-records
This is the value that will be compared against the value found at the input key.
Let's go ahead and set our values for our first condition. Set the condition fields to the following values...
Find Key In... = Anywhere Input Key = sport Compare As = Equals Value = soccer
It should look like this...
Then click Save Changes to commit the action to your flow. The flow should now show the diamond shaped Check Data action.
IF, ELSE, THEN WHAT?
Now, if you run this, not much will happen. It will check the data, but since there are no subsequent THEN or ELSE branches nothing else will run. So let's add an IF and an ELSE action.
Click on the insertion node after the Check Data action and add a "Respond with Success" action with the following values set...
Operator = THEN Action = Respond with Success Message = Futbol is life!
Next click on the insert after node after the Check Data action and add another "Respond with Success" action with the following values set...
Operator = ELSE Action = Respond with Success Message = It's not soccer...
Now your flow should look like this. Make sure that you set the second Respond with Success to have the ELSE operator. Branches with the ELSE operator will be colored red.
By now, I'm sure you are probably getting a feel for how this process will work. When we send a GET request to /example-check-data the process will look for the key "sport" and check to see if it equals "soccer".
So if you go to the following URL in your browser...
It will respond with...
Futbol is life!
If you set the value of "sport" to anything else or omit it from the request entirely, you should see the response...
It's not soccer...
Now that you understand this simple example, feel free to experiment with the operators to see what other kinds of conditions you can create.
Some things to note...
- Every condition in the Check Data action must be met in order to send the data flow to the THEN actions. So if you add three conditions, all three conditions must pass otherwise it will go to the ELSE branch.
- You can add multiple THEN or ELSE actions after a Check Data which will allow you to run multiple branches in parallel.
- You can add a Transform Data action before the Check Data action to prepare your data before you evaluate it. This way you can accomplish more complicated conditional logic within your data flow.