When working with the Power Platform, one recommended practice is to use solutions for packaging all the components — Power Apps, flows, Dataverse entities and option sets, and more. Solutions make it easy to move these components between environments. This is important for application lifecycle management.
Environment variables are part of solutions that are used to identify information which is used in these components that differ between environments, such as the tenant name, SharePoint site, accounts, and much more. There are six distinct types of environment variables that one can use in their solution:
- Decimal number used to store whole or fractional numbers.
- JSON stores properly-structured JSON objects
- Text used for free-form text
- Yes/No are boolean values
- Data source provide credentials to a specific connection (such as SharePoint, SQL, etc.)
- Secret lets you access credentials stored in Azure Key Vault
When building apps and flows, a common way to manage list options is by using an external data store, such as a SharePoint list or choice field column, Dataverse column, SQL, and more. However, there are instances in which it is not desirable to have such a dependency if the sole purpose is to populate a list.
Imagine the scenario of building an flow that needs to have a list of fruits. The list of fruits may differ, depending on which environment you install the solution on. Typically, there are two options to achieve this:
- Use a separate data source and deploy it to the environment. While possible, it adds another layer of maintenance and deployment complexity.
- Hard-code the list and edit in each environment. This requires the solution to be unmanaged. There are many reasons why this is not recommended. Simply put, don’t do that.
So what other options are there? Remember the JSON object I mentioned above? You can construct lists and use them in your apps and flows.
For example, for the fruits, I created the following structure:
{
"data": [
"Abiu",
"Acaí",
"Acerola",
"Ackee",
"African cucumber",
"Apple",
"Apricot",
"Avocado",
"Banana",
"Black sapote",
"Blueberry",
"Boysenberry",
...
"Yuzu"
]
}
Make sure to include the list items in a JSON structure. Otherwise, Power Automate will not recognize it as valid JSON. It is also possible to include lists of objects. This is useful in cases, where you want to have list items with different ID’s. Here’s a short example for the list above
{"data":[
{"id":1, "fruit":"Abiu"},
{"id":2, "fruit":"Açaí"},
{"id":3, "fruit":"Acerola"},
{"id":4, "fruit":"Ackee"},
{"id":5, "fruit":"African cucumber"},
{"id":6, "fruit":"Apple"},
{"id":7, "fruit":"Apricot"},
{"id":8, "fruit":"Avocado"},
{"id":9, "fruit":"Banana"},
{"id":10, "fruit":"Bilberry"},
{"id":11, "fruit":"Blackberry"},
{"id":12, "fruit":"Blackcurrant"},
{"id":13, "fruit":"Black sapote"},
{"id":14, "fruit":"Blueberry"},
{"id":15, "fruit":"Boysenberry"},
...
{"id":128, "fruit":"Yuzu"}]}
That’s pretty much it. Now you can construct your own lists outside your solution components without having to edit them or depending on other data sources when moving between environments.
Originally published on Medium
Haniel Croitoru 