Variables
When building workflows in Flow XO, you will often want to work with data that is collected or created during the course of a conversation. There are two main features in Flow XO that can help you store and reuse data - user attributes, and variables. User attributes are associated with the current user that is interacting with your flow, and reading and writing data to user attributes will carry over to any other flow that runs for that same user. You can read about working with user attributes in this article. Variables, on the other hand, are bits of data that are stored with and impact only the current flow in which they are defined. They are also much more flexible and easy to work with than user attributes, so for most cases where you need to work with potentially changing data within a workflow, you should use a variable. You can also combine variables and user attributes in powerful ways which we will demonstrate in this article.
Storing Data in Variables
Because variables are only stored with the currently running workflow, you have to store some data in them before they can be used. We provide three different ways to do this:
- Using a "Set Variables" task as an action in your flow
- Storing the result of an Ask a Question task as a variable
- Storing the result of a Wait for a Response task as a variable
The most common method of getting data into a variable is as the result of an Ask a Question (or Wait for a Response) task. In this scenario, you ask your user a question, such as their email, and then when they respond, their answer can be automatically stored in a variable of your choosing.
Now, any time you need to refer to the users email later in your flow, you can just use the "email" variable from the dropdown list in any other action, such as a "Send a Message":
If you don't want to pick from the dropdown list, you can always refer to a variable in any textbox in the flow builder using the format {{variablename}}. So, in this case, to refer to the users email, you can simply type {{email}} and it will be replaced with the value of the email variable, which in our example was collected as part of asking a question.
However, you may not always want to get your variable data from a direct question to a user. Sometimes you may want to get the data from another place, like the result of an integration, or data that was passed into the flow as metadata or a user attribute. In that case, you can use the Set Variables task:
Now, any time you need to refer to the users first name, you can simply type {{name}}
Incrementing Variables as Counters
In certain circumstances, you may want to use a variable as a counter, usually in combination with "Labels" to make a loop. To increment a variable, you can use the "Increment Variable" task
The Increment Variable task simply takes a variable name and the amount you want to increment or decrement by. To decrement (reduce) a counter variable, just use a negative value, like "-1".
Variables and Default Values
One powerful pattern that can make your life a lot easier when working with flows is to use variables to set default values that might (or might not) get updated later as part off the conversation.
For example, let's say you want to address a user by their first name if your bot knows what it is, but if not, you'll just call them "Friend". This can often be the case if you have a bot that runs on multiple platforms such as your website as well as Facebook Messenger. Facebook knows their first name, but your website does not.
In that case, when you start your flow, you can set a "name" variable with a default of "Friend", but if you happen to have a first name as part of the incoming data from the chat platform, you can use that instead. It would look like this:
The interesting thing about this example is that you are setting the same variable twice using the same "Set Variables" task. The way the set variables task works is that each time the same variable name appears in the list, the value of that variable will get overwritten but only if there is a non-blank value to set. So in the example above, the "name" variable will ALWAYS get set to "Friend", but if there is a "first name" coming in from the message trigger, then it will overwrite the "name" variable with the new value. If not, and there is no first name available from the messaging platform (as is the case for web bots), then "name" will not get changed from "Friend". That way, you can safely write message like "Hello, {{name}}!" and the bot might write "Hello, Friend!" or "Hello, Nathan!" depending on whether or not you already know their name.
Combining Variables and User Attributes
Another extremely useful pattern using variables is to combine them with User Attributes. User Attributes that you set are always sent as data to every flow. So once you set a user attribute, the next time that flow (or any other flow) runs for the same user, that attribute will get sent along as data you can use. But of course the first time you encounter the user, the attribute will not be set yet. In that case, you will need to set it for the first time - often by using an Ask a Question task to get the data from the user.
As an example, let's assume that you have chatbot that works differently for different users depending on whether or not they are "teachers" or "students". At first, you usually won't know if a new user is a teacher or a student, so you need to ask them. Once you do, you should never have to ask them again, either in the current flow or any other flow. Here's how this might work:
- In the beginning of your flow, use a "Set Variables" task to set the "role" variable to the current value of the "user_role" user attribute.
- If the variable is empty after you do that, you know you need to gather their role. So you use an Ask a Question task to ask them their role, and you configure the "Ask a Question" task to put the answer into the "role" variable name.
- Next, you set the user attribute "user_role" to the value of the "role" variable. This will save it for the next time this flow or any other flow is run, and you won't have to ask them for it again.
- Any time after that you use the "role" variable, it will be correct - either it will have come from the user attribute set in a previous flow, or it will come from the answer to the Ask a Question, either way from this point forward your flow doesn't care, you can just use the "{{role}}" variable anywhere you need it.
You can install this sample flow into your account try it out: https://flowxo.com/share/ants-universal-8268
Let's take a closer look at some of these steps.
1. Get the user role from the user's attributes, if it's present. In this step, we set the value of the "role" variable to the "user_role" user attribute, which may or may not already be set.
2. Ask the user to provide their role if the {{role}} variable is empty. We'll do this using a simple filter, so that this question will only get asked if the {{role}} variable is empty (meaning it wasn't in the user's attributes yet).
Note that we must store the answer back into the "role" variable, because we'll be using it again later
Make sure to add a filter so this step doesn't run if it doesn't need to:
3. Set the "user_role" user attribute so that next time a flow runs, we'll already know their role. You might think this step should have a filter too, so that it only runs if we had to ask the user for their role the first time. But because the "{{role}}" variable will have the correct value in either case, new or returning user, we can't skip the filter entirely.
4. Finally we can use the {{role}} variable in a message, to filter other actions, or to send in an integration - anything we like, confident it will have the correct value
That's really all you need to know to use variables in your flows. They will simplify your flows a great deal. Next we'll briefly discuss an advanced topic most of you won't ever need, so feel free to skip it if you like.
Conflict Resolution and Variable Update Order
As mentioned earlier, when using the "Set Variables" task to set variable values, you can repeat the same variable name multiple times. The last item in the list with a non-empty value will get written to the variable, and any empty values will be ignored. This is very helpful for setting defaults, even multiple levels of defaults, for example if you want to get the value of a variable from a metadata field, unless it's present in a user attribute, but use a default value if it's not available in any of those places. That would like like this:
But what if you WANT to overwrite a variable value with a blank value? Or, alternatively, you only want a variable to be set if it already empty, and otherwise it should keep its original value.
In these advanced scenarios, you can use the "Conflict Resolution" setting to change the Set Variables behavior to the one you prefer. For example, this will clear the "role" variable (delete it)
There are three options for the Conflict Resolution setting:
- Merge (default) - always overwrite a variable with the latest non-empty value. Variables are always set in order from top to bottom.
- Overwrite - always overwrite a variable with the value to specify. If that value is blank the variable will get removed.
- Skip - ONLY set a variable with the provided value if it was blank BEFORE. So if the "role" was previously "student" and you try to set it with "teacher" using "skip" - it will stay "student". If "role" was blank before, then it will get set with "teacher"
And that's it! Happy flowing!