In June of 2020 Microsoft released global variables for PVA.
This allows you to store variables that can be used between different topics. It’s a very handy feature, especially if you’re like me and you tend to create a lot of topics to make your chatbot more manageable, rather than trying to stick everything into one giant, sprawling topic tree.
However, there is one major drawback and if you’re used to working with variables in other programming languages it’s going to drive you nuts. The global variables can only be called in one location. This is especially frustrating when your topic has conditional branches. Let me give you an example.
Imagine you have a chatbot that asks the user to enter her favorite flavor of gluten-free, low fat, organic, sugarless snow cone. Then a flow kicks off to check a list of flavors and if it isn’t found in the list it asks the user to enter a different flavor. After 3 tries, it connects the user to an agent. If it’s successful, it moves onto another topic that confirms the request, a topic which uses the flavor she entered as a variable.
Notice that in my above example the bot.flavor variable that we want to call in the confirm topic has two names. It starts out as bot.flavor, but if the question needs to be asked again, it gets stored as bot.flavor1. This is because a global variable cannot be called from two different places. Now in the confirm topic, where the variable needs to be called, there are two different global variables to choose from!
You can see the issue here. The new topic doesn’t know which branch the user was on in the flavor name topic before finally entering a name that the flow found a match for. So it doesn’t know which of the global variables to select. This would be easily remedied if you could just store bot.flavor in any of the branches, but that is not currently supported in PVA.
Enter environment variables. Environment variables are stored in Dataverse and can be called from Power Automate to store a value in one topic, regardless of what point in the dialogue tree it comes from. Then a subsequent topic can call a different flow to summon the value in the environment variable. So before leaving one topic you store the environment variables you want and at the start of another topic you call the environment variable back again for use in that topic. Confused yet? Let’s walk through it.
First we will create an environment variable called flavor. Open a solution in the Power Apps Maker Portal. Select New -> Environment variable:
Call your environment variable flavor, choose data type Text and set the current value to x (or anything you want, setting a current value will make the environment variable definition relationship… you will see what I mean). Hit save.
Back in PVA, in your first topic, create a new flow just before you move to the next topic.
This flow will have inputs to store the environment variable, but no outputs, because it won’t be used until the next topic. Call your flow SET flavor bridging environment variable. Create an input called flavor with a value of string_input.
We will get the flavor name that the user enters in chat (the input) and store it in our environment variable. First, let’s get our environment variable definitions. Add a Dataverse List Records action and select Environment Variable Definitions for the table name.
Go back to the maker portal and find your environment variable definitions table. You will probably have to change your filter in the top right to All.
Click on the Data tab and record the schema name for your flavor variable.
Back in your flow, set the Filter Query for your List Records action to schemaname eq ‘cr31e_flavor’, or whatever your schema name is. Set Top Count to 1.
Add another List Records action. For this action select the Environment Variable Values table. Set the Filter Query to:
_environmentvariabledefinitionid_value eq @{first(body(‘List_records’)?[‘Value’])?[‘environmentvariabledefinitionid’]}
If you changed the name of your first List Records action be sure to use the correct name in your formula. Set Top Count to 1.
Now that we’ve located our environment variable, let’s add an update record action to update it with the value of our input. Select Environment Variable Values as the table for the update record and for Item ID enter:
@{first(body(‘List_records_2’)?[‘Value’])?[‘environmentvariablevalueid’]}
For the Value column, use the dynamic content to enter your flavor input.
That’s all you need for the SET value flow. There are no outputs at this point. Add this flow to your topic just before moving on to the next topic. In the next topic, right at the start, we want a flow to call this environment variable and store it for use in the topic. So at the start of the topic, create a new flow.
Name this flow GET flavor bridging environment variable. It won’t have any inputs from the PVA, it will simply summon the value that’s stored in Dataverse. So skip inputs and add a List Records action. Once again list Environment Variable Definitions with a Filter Query of:
schemaname eq ‘cr31e_flavor’
Or whatever your schema name is. Set Top Count to 1.
Add another List Records action, this time listing the Environment Variable Values table. For the Filter Query use:
_environmentvariabledefinitionid_value eq @{first(body(‘List_records’)?[‘Value’])?[‘environmentvariabledefinitionid’]}
Now that our flow has summoned the value for our environment variable, we just need to store it in an output to send it back to PVA. For the expand action at the bottom of your flow, click Add an output. Select text, call your output flavor and for the value enter the expression:
first(body(‘List_records_2’)?[‘Value’])?[‘value’]
Again, if your List Records actions have been renamed, be sure to change the name in the expression.
Save your flow and return to your topic. Call this GET environment variable flow at the start of the topic. If you have global variables with the same name as the output variable, it might add a number to the end. But since this is a brand new topic variable, you can rename it to whatever you want.
Now you can use this in your topic.
Make sure to add the SET variable action at the end of every branch in your first topic and use the correct variable. For example, if the first flavor selected works it stores the flavor variable as the environment variable, if the second branch is used it stores flavor1 as the environment variable, etc.
Now, no matter how many times the user needs to re-enter a flavor name, it will always be able to be used in the following topics. This makes it a truly global variable that can be re-used throughout the branches of your topic!
