You can configure the Branch by condition step to evaluate data stored in variables and branch a messaging bot conversation based on that data.
This article includes the following sections:
Branch by condition step basics
When you add a new Branch by condition step to your answer flow, the following settings are included:
- Name that identifies the step on the canvas.
- Two default branches that must be configured before the answer
flow can be published:
- If this: If the branch's conditions are met, the conversation follows the branch's steps
- Else: If the conversation doesn't match the conditions of any other branch, the conversation follows this branch's steps
Branch by condition can have up to six branches, including the Else branch. The Else branch is required and cannot be removed from the step. You can add up to four additional branches, to a maximum of six branches.
To add an additional branch, click Add branch and configure the following settings for each branch:
- Name that describes the condition for the branch. This name appears as the branch name on the canvas.
- Condition that includes the following elements:
- Variable: The data that will be evaluated to see if the condition is met.
- Operator: How the data from the variable and value are compared. Includes is, is not, contains, and does not contain.
- Value: Value expected for the condition specified by the operator.
See Condition elements for more information.
You can combine conditions for a branch using the AND/OR drop-down. For example, the following branch checks whether a user is located in Australia or the United States.
A conversation can only follow one branch. Branches are evaluated in the order they are included in the step. End users that meet the criteria of more than one branch will be sent down the first branch with matched criteria, from top to bottom in the step's configuration panel or left to right on the canvas. Branches can be reordered by dragging the condition panes on the canvas.
Condition elements
About variables
In a condition, a variable's value is compared to a static value. Variables are added to the condition using a drop-down menu.
For more information about variable types and creating variables, see Using variables to personalize bot answers.About operators
The operator determines how the variable's data is compared to the value. Operators are added to a condition using a drop-down menu.
The following operators are available. All operator matching is case-insensitive.
- Is: Match if value in a variable is exactly equal to a specific value.
- Is not: Match if the value in a variable is not exactly equal to a specific value.
- Contains: Match value in the variable that contains certain text in any position, partial match, e.g. sub-string.
- Does not contain: Match the value in the variable and does not contain certain text in any position.
About values
A value is static data that's compared to a variable.
It represents the expected data for a variable. For example, in a condition that
checks whether a customer's membership_status
is "platinum",
"platinum" is the value.
The input field used to specify a condition's value varies based on the variable. For the Authenticated status variable, you specify the condition's value using a boolean drop-down field. For other variables, you specify the condition's value using a text input field.
membership_status
drop-down field accepts a "Platinum
level" value with a related "platinum_level" tag. To check whether the customer
has a platinum membership status, use "platinum_level" as the value in the
condition.Nested conditions
A nested condition is a condition that contains two or more conditions inside it. You can use nested conditions to build complex logic that relies on multiple conditions. They are especially useful when combining conditions using both AND and OR.
- The user has a “platinum” membership status AND
- The user is located in one of the following countries:
- Australia OR
- The United States
You can only nest conditions up to three levels deep. Each level, including the top level, can contain up to six conditions.
11 Comments
Hi Aimee Spanier, we are testing this in our sandbox, but the branch conditions are not working as expected. For some reason, it always goes to the Else branch even though the conditions for one of the other branches should have been met.
Hi Aimee Spanier, i have the same problem.
For the reason i don't know, it always go back in the else's branch.
How can i fix this.
thanks
I was running into the same issue as the users above, and I believe I've found the problem.
If you are making an IF/ELSE condition based on a dropdown selection, you must enter the field selection's Tag as the "IF" condition, not the selection Value (agent/customer-facing name).
You can find the field Tag / key in Admin > Objects & Rules > Tickets > Fields. Use the key listed for your selection from the Tags column, not the Value column.
For example, we have a field named "Order Issues" and one of the dropdown options says "File a warranty claim". The Tag / key for that selection is listed as claim_file.
Therefore, my IF statement in Flow Builder needs to say claim_file — not "File a warranty claim".
Hope this helps!
Hey Harper Dane, thanks for that tip!
After changing the value to the tag, it works as expected.
Hi Aimee Spanier, is there any possibility to remove the branch limit?
Is there any reason to limit it to just 6 branches?
Is there an option to create variables based on the Present Options function? It seems rather limiting to only allow this information to come from API calls or whatever custom fields you already have on a ticket.
Hey Walter,
Can you share your use-case where you need more than 6 branches? I'm wondering if nested conditions could help with your use case.
Hey Rachael,
Would the collect information step help with your use case where you can collect information from the end user via a form dropdown? This data can then be used with Branch by condition.
Hi Lisa Tam,
Thanks for your response. I've considered using nested conditions, but our review team does not feel it is a good experience for the customers in this specific scenario. Without giving away too much information, the options we need to provide to the customer exceed 6. And using nested conditions would result in making it almost like we are interrogating a customer. :)
Lisa Tam Hello, any visibility into when variables will include authenticated user information?
E.g. if we want to separate flows for authenticated and nonauthenticated users or use external_id/email to get more user info via API?
Good question by Anton, I think this would be a major improvement. 😉
Please sign in to leave a comment.