Answered

Environment variables premium or standard

(0) Share

Report

Posted on by BenAu

Hi,

I have tried searching but have been unable to find much information regarding the licensing around the the use of environment variables.

A google search brings up https://powerusers.microsoft.com/t5/Building-Power-Apps/Environment-Variable-Licensing-in-Canvas-Apps/td-p/494211 which says they are most likely a standard inclusion.

When I add one to a solution and try use it in an app but adding the environment variable connectors, the app becomes a premium app. Is there any concrete information on the licensing of this feature?

Thanks

Ben

Categories:

Building Power Apps

All responses (12)

Answers (1)

Sort by

RusselThomas 4,014 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @BenAu ,
So first thing is, this is a 'best guess' answer - we would have to ask the product team to give an official answer, but I'm fairly certain we can guess closely what it will be.
Secondly - preview services can (and most will) change before going into general availability. There are few guarantees and plenty of disclaimers when it comes to preview services.
Lastly, "using CDS" and "using the CDS connector" are two different things. While Approvals use CDS tables, the Approvals connector is not a premium connector.
Environment Variables are a Common Data Service (now Dataverse) entity accessed by using the CDS Connector which, from my experience anyway, is premium.
Unless you're building your app in a Teams Dataverse environment (which is not premium), or you use something else to store your env variables, if you're using a Common Data Service connector to access data in the Common Data Service (Dataverse), it will make your app premium.
CDS/Dataverse common environment variables are very useful if you're using CDS, Solutions and/or some level of devOps between environments, but if all you want to use are common variables centralised somewhere, there are easier and cheaper ways to do it.
Personally, I prefer to use a simple SPO list to store common variables anyway, because a list as a data source is not locked into an environment and as such, variables can be standardised across environments or localised for specific environments by adding an environment id field - all without touching CDS/Dataverse.
Hope this helps,
RT
BenAu 59 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi Russel,

Appreciate the detailed response.

The app we are building is a canvas app with flows using SPO as the data source.

I was experimenting with env variables to make maintaining the app between a dev/staging/prod environment easier as the flows and app have some links/functions that need to change per environment.
I wanted to be able to:
Import the dev app into another environment
Set an environment variable at the solution level without having to edit the app or flows
Have hard coded functionality in the app and flows to respond to what the environment variable is set to

Pretty simple stuff.

Would love to just store data in SPO for this, but I see no way to make the app or flows aware of what environment they exist in, any ideas?

Thanks
Ben
RusselThomas 4,014 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @BenAu ,
So that's really the primary reason env variables in CDS are useful (and sometimes necessary). Self-aware apps are tricky inside the app - there are apparently plans to improve this with additional actions/functions, but what, where and when this might be possible is anyone's guess. SPO only really helps for global variables across environments - localising for environments using the id field is also only useful if you're using the Makers connector - which helps for some "admin-only" app functions, but not for general user variables.
I generally use SPO centralisation for things like email headers, adaptive card content or other commonly used components that I want to edit in one place and have all apps that use them auto-update. Tying them back to the specific environment the app finds itself in for user functions is very difficult (if not downright impossible at the moment).
The problem as I'm sure you're aware is that apps are not self aware - the environment container is a static boundary that can be accessed using "current environment" context which is dynamic - and this way each environment can carry variables accessible to solutions inside it without the solutions themselves needing to know what environment they're in.
The Makers connectors will allow you to pull app properties in-app, which include the current environment name/guid the app is running in, but the problems is this only works for app owners. Pointless for users running an app and wanting to fetch variables specific to the the app environment.
So yes, if you need user-accessible variables that are different for each environment, you're kinda stuck with environment variables. Happy to be corrected, but that's my experience.
Kind regards,
RT
Verified answer

RusselThomas 4,014 on at

Like
a
(3)

Report
Copy link

Link copied!
Hi @BenAu ,
This conversation was got me curious - it's not something I've really ever had to do, so I decided to spend a few minutes actually looking at this and I think I've found a solution.
Initial testing seems to indicate you can get Power Automate to help the app know what environment it's in, simply by triggering the flow - without using any maker or CDS connectors.
If you create a PowerApps triggered flow as part of your solution, you can pull out the headers from the PowerApp trigger - from there you can suck out the app id, the environment id and more.
Create a PowerApps triggered flow
Add a compose step but just set it to something arbitrary - "hello world" is fine. Save the flow, connect your app to it, then trigger it from your app.
Open the flow run, expand the PowerApps trigger and select "show Raw outputs" - copy everything you see there. Note key fields like "x-ms-client-tenant-id", "x-ms-client-environment-id" and other potentially useful fields like user id and name - but for now just copy the whole lot.
Now, you can decide how best to do this bit, but for illustration purposes;
Remove the compose step, replace it with a Parse JSON step
In the Content field of the Parse JSON, add the expression triggerOutputs()
Paste everything you copied into the sample schema for the JSON step.
You can now see and access the data quite nicely in the JSON construct for your next step.
Create a "respond to PowerApps" step and pass back the environment ID (and anything else you need).

Your app should be able to use this to lookup environment specific variables, and the flow it uses should package with your solution and move through environments with it.
Let me know how it goes! ‌‌
Kind regards,
RT
BenAu 59 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi Russel,

Not sure what I am doing wrong 🙂

I can see the app and tenant ID's when looking at the output of the PowerApps trigger as per you post above.

I can add the output the to generate sample parse json action, what I can't do is pass the output of the trigger to the content of the parse json action.

Within the parse json I see:

If I select the Ask in PowerApps content, it automatically changes it to the ParseJson content so its referencing itself and not the output of the trigger causing it to error.

My flow:

Thanks
Ben
RusselThomas 4,014 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @BenAu ,
Apologies, forgot to add that bit - will edit the post for future users.
We don't need to ask PA anything as we're just using the trigger outputs.
First, delete and recreate your PowerApps trigger if you've added any PA inputs. Then, in the Parse JSON content field, use the following expression;
triggerOutputs()
In PA, you can add the flow to a button and just set it's OnSelect: property to something like
Set(gvarPAOutputs, flowrunName())
Let me know how it goes,
RT
BenAu 59 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi Russel,

So I can get this working on our dev environment. The flow simply runs in the app on start which will allow me to hardcode links based on the environment value.

My issues are now with moving the solution into other environments 😞

I have added the powerapps triggered flow to my solution, when I export the solution and import it into our staging environment I can see the flow has came across fine but within the connections inside the canvas app the linked flow is now white indicating the connection is no longer connected to the flow.

Have I missed a step here or will it just be that we have to re-connect the instant flows when moving a solution around?

Thanks
Ben
RusselThomas 4,014 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @BenAu ,
In my experience, connections inside apps always have to be "recreated" or reconnected in new environments because the connection is set to whatever GUID the connection instance was for the old environment.
Sometimes the solution import process tries to reconnect flow connections for you automatically, based on their names, but I've never seen it do app connections automatically... Open to correction, but I would expect you need to reconnect with each environment move...
Kind regards,
RT
BenAu 59 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi Russel,

Finally got the time to respond.

Have managed to implement this and bring our app into production and would like to write what I did in case others come across this.

Our application is part of a solution across three environments, we have a single data source being SharePoint which is used by all three environments at the moment.

Within the canvas app we are identifying the environment the app runs in as per your above instructions. This value is then used within the app to set some hard coded links etc.

The app also uses the value when saving records back to SharePoint which now has a column called Environment within its lists. So depending on what environment you run the app in the data being saved will actually record that environment.

This environment value is then used for any flows that trigger on values in SharePoint. On each environment we modify the trigger conditions of the flow to only trigger if the environment value in the SharePoint data is the correct environment that flow exists in. This means if a flow exists in all three environments it will not run when data is added to SharePoint unless the data meets the environment condition added to the trigger.

Next steps will be to get the flows to identify what environment they are in themselves but a quick check of the SharePoint trigger conditions doesn't appear to show any environment information.

The process of moving changes between environments does have manual steps but its manageable.

Appreciate the prior assistance.
Ben
RusselThomas 4,014 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @BenAu ,
That's great news, glad it's working for you and thanks for sharing! 👍

Kind regards,
RT