When you use multiple environments (and you always should do) in the Power Platform, then it is almost impossible to avoid environment variables. Each environment variable can have default and current values. What is the difference between default and current?
SharePoint Environment variables
Table of Contents
- SharePoint Environment variables
- Importing a solution
- Set environment variables
- The second import
- Pipeline deployments
There are two types of SharePoint environment variables.
- Sites
- Lists
Then we have two types of value settings
- Default value
- Current value
In this post I’ve created 2 site environment variables in a solution in my Development environment. Then for each site environment variable I created two list variabales.
The two site variables have values set through their default or current value
| Environment variable | Description |
| SharePointSite_CurrentValue | Set the site using the current value |
| SharepointSite_DefaultValue | Set the site using the default value |
Then the list variables have their value set through the default and current values as well.
| Environment variable | Description |
| SharePointList_CurrentValue_CurrentSite | Set the list with the current value with the site variable that uses the current value |
| SharePointList_CurrentValue_DefaultSite | Set the list with the current with the site variable that uses the default value |
| SharePointList_DefaultValue_CurrentSite | Set the list with the current value with the site variable that uses the current value |
| SharePointList_DefaultValue_DefaultSite | Set the list with the default value with the site variable that uses the default value |
Importing a solution
Now that the environment variables have been set we’ll import the solution in a new environment and we will see a couple of different behaviours appear.
The first thing we’ll notice is that the site variable which we set the current value for is blanked out during the import. this is expected during the initial import as there is no current value for the variable in this environment yet.
Then for the list variable which we set the the default value while the site uses the current value, we will see the guid of the Document library on my development site. The selected library cannot be resolved and therefore the GUID is shown.
The following warning will appear when anything goes wrong resolving a value into a list or library
Warning: You do not have access to the list value for this selected connection. However, this does not block other users in the target environment from using this list value if they have access.
Set environment variables
The warnings do not disappear. We can just ignore these warnings here.
The second import
Any future import or the solution will now show the GUIDs of the library where the default or current value cannot be resolved.
The current values for the site variables (as we set during the initial import) will take priority above any other values. This is how we would expect variables to work.
However if we look at the list variables it all looks a bit of a mess. The whole idea of environment variables is that values are kept. This now means that every time we do a manual import of the solutions we need to reselect all the lists and libraries for each site variable. Naming your environment list variables may help a bit.
Pipeline deployments
I didn’t want to stop this post here yet. How will these environment variables work if we do a pipeline deployment?
As you can see in the above screenshot default and current values work the same way. Now it is up to personal preference if you prefer to use default values for your lists or not.d organization.
About The Author
Microsoft MVP and Technical Director at Vantage 365
Veenstra, P (04/02/2026) Power Platform environment variables, default vs current values. https://sharepains.com/2025/12/19/power-platform-environment-variables-default-vs-current-values/
