It’s a small thing, a very fringe feature, and these improved features requests are only for me… or… crucial for everyone…?
The Environment Variables feature became officially released a year ago, probably when I was “off the grid” last year. I sort of missed that… but it’s here now anyway.
It’s like system settings, and is now supported by the core Power Platform. We don’t have to build anything for that anymore.
Note: I might call this as “Settings” in this article – because it is used just like settings. But there is another similar feature called just “Setting”. This has fewer value type and limited to max 50 chars, but it has more features about which Preview/GA, if it’s used in Environment and/or Apps etc. I (might) get back to Settings in a future post!
The Environment Variables feature has been growing over a long time, we got the preview back in 2019, and slowly, slowly now being available as General Availability.
A lot of people in this technology area seem to like this. I do it too; more excellent to have this out of the box, instead of our own solutions we need. See writers like Forward Forever, SharePains, Imperium Dynamics, etc., and even my colleague Benedikt.
Because of this new feature, I have now stopped to use our own table (entity)
crmk_variable or the older
cinteros_setting – I shall now use the Environment Variables instead!
It’s damn hard to write it, and equally hard to pronounce it.
Maybe I should just continue with a short name: EV.
Environment Variables (EV)
The EV is actually two tables – EV Definition (EVD) and EV Value (EVV).
EVD has the settings – the definitions and what type, a good name for it, and may have a default value.
EVV has the locally installed solution settings values.
Why have two tables? Because maybe, perhaps, in the fullness of time, the Values may be personal, or by Business Units, or splitting in other ways. In the future. Well well, today the relationship between EVD and EVV is 1:1. Well not technically from the database perspective, it is
EVD-1:M-EVV, but with the core plugins, it’s used as a 1:1. Live with it.
We live with it
So how do we use the “EVs”? Well, other folks have written about this, so I won’t. Just a bit.
We store the settings in these two EV-tables. The tables are like any other table in Dataverse, just like we have done it since ages. I’ve done it since I started in 2009, for some I’m old in this area, for others I’m still a noobie. So the Views and Forms are there; if you add them to the navigation in the sitemap.
These tables are created by Microsoft to be used and edited inside the Power Platform Maker Portal. Not initially intended to use in a “normal” area, the Model-Driven App.
The developers who create the solutions also create setting definitions (EVD) of the settings we need. The developers (using this word in a general meaning) use these settings in code, Power Automate, rules, integrations, etc. This is done in the EVD.
The administrators at the customer, they use our solutions and imported them. When the admin opens the Maker Portal, it is notified if any settings are not locally values added. When you add your local settings, they are added to the EVV table.
What I want to have…
Using the Maker Portal is a bit too hard, too messy to find them, from “normal” user or “super user” in some cases.
I want it to be possible to use the normal tables we have, in a Model-Driven App that we know.
It should be easier for super users to change the setting’s values, it should be possible to see and edit it in the Model-Driven Apps. I want that.
Elevated users don’t do things in the Maker Portal. #myfact
I know, some settings are only set once and for all, and will never be needed again to be seen. But some need to be able to change now and then and should be found easier.
Us at CRMK are partially an ISV and create producs, in that case the changes of settings is even more valid, since the imports are done behind the scenes, and all users of all levels are using it in the Model-Driven Apps or perhaps Canvas Apps.
This is where Model-Driven Apps is the solution.
Dynamics 365 is dead.
Of course, it’s not dead. But the views and forms for these tables are stiff and we can’t move or change them.
We’re supposed to use this in the way Microsoft told us – in the Maker Portal. That’s why we never need to change the views or forms. Fine. So far…
Until now, these views are – sorry to say so – not possible to modify in any way. Only the general default layouts, with a “Name” and the “Created On” columns. Why? They probably didn’t think about using these tables in the apps.
The forms? A bit better, but way not enough.
Create table – with properly appearance
If you create a table, make sure you modify the views, not only the default view – all of them. Are they useful?
Make sure the form is valid and relevant with columns in there, some required, some might be readonly.
And get an icon. Really. Before publishing the solution.
I know, this is crash course class A-1. We all know it.
But please, just do it. Ok?
We can’t revive them
As we develop our products (or custom tailors’ solutions), we can’t fix what we’re missing in these views and forms.
Checking the metadata for these tables, we see that
CanCreateView = true and
CanCreateForm = true, which is great, but
IsCustomizable = false, that’s too bad…
So we can create/edit views for personal views, but the system views are locked.
Need custom views
I totally understand that
IsCustomizable = false. Of course, the table schema should never be changed, the feature is from the core from Microsoft.
But we need another metadata option, to be able to make system views from us as developers, even if the schemas are locked.
Then I could filter the EVD/EVV for “our settings”, to filter for only the settings we want to be able to change easily.
These are the problems that need to be fixed. Gladly all of these, or maybe a few of these:
- I can’t really use the views that Microsoft created.
- I can’t create a specific view for my product.
- I can’t join the Solution or Publisher in OOB.
- I can’t create a view showing all settings and all values if they are added.
- I can’t validate the values in the Model-Driven Apps.
- I can’t use Quick Create Forms to enter the values.
- I can’t find the settings to change the values.
- I can’t see the long descriptions.
Don’t worry, I don’t only complain… I give you the solutions! Read on!
1. Fix out-of-the-box views
Name and Created on, that’s not good enough. Just fix it. Now. Please 🙏
For EVD, show at least Display Name, Type, and Default Value. Something like this:
For EVV, show EVD Display Name, EVD Type, EVD Default Value, and Value, see here:
2. A view for only my product
If I can create custom views, I can add filter by prefix, id, solution, publisher, or only show their solutions and publisher.
I really need custom views.
3. Make Solution a proper relationship
This could be fixed in two ways:
- Make the
Uniqueidto a proper
SolutionComponentto the EVD.
- Actually use the
solutionid. When I create a setting, the
solutionidis always set to the Active solution. Why? I don’t know…
4. Using the 1:1-relationships
I would also want to show the 1:1 relation to EVV, then you can see both all definitions and the local values for those that are added. Something like this:
5. Validate values by type expected
Some things are easy to validate by types – Number, JSON, Yes/No, and of course Text.
6. Use Quick Create Form
From the Setting (EVD) it should be really easy to create the Value (EVV).
If the bullet 4 is implemented, we see all Definitions and we can easily find what you have missed, to add new Values directly from the Definition.
7. Find to change the EV Values
Using the Maker Portal as the MS says us to, it is really hard to find any edit the values. Why?
Well, it is quite easy to find them – open the solution in which they are imported. But you can’t edit them…
- Make this available from the source solution, save the local values outside of the solution.
- Make all EVs available on the Home page in the Maker Portal.
8. All Description aren’t shown
Just flip it to a multi-line attribute, helps us a lot.
Codes for the views
1. Default views
Default view for EVD
<fetch version='1.0' output-format='xml-platform' mapping='logical' distinct='false'> <entity name='environmentvariabledefinition'> <attribute name='environmentvariabledefinitionid' /> <attribute name='schemaname' /> <attribute name='defaultvalue' /> <attribute name='description' /> <attribute name='displayname' /> <attribute name='type' /> <order attribute='schemaname' descending='false' /> <filter type='and'> <condition attribute='statecode' operator='eq' value='0' /> </filter> </entity> </fetch>
<grid name="resultset" jump="schemaname" select="1" icon="1" preview="1" object="380" > <row name="result" id="environmentvariabledefinitionid" > <cell name="displayname" width="100" /> <cell name="schemaname" width="300" /> <cell name="type" width="100" /> <cell name="defaultvalue" width="100" /> <cell name="description" width="100" /> </row> </grid>
Default view for EVV
<fetch version='1.0' output-format='xml-platform' mapping='logical' distinct='false'> <entity name='environmentvariablevalue'> <attribute name='environmentvariablevalueid' /> <attribute name='value' /> <filter type='and'> <condition attribute='statecode' operator='eq' value='0' /> </filter> <link-entity name='environmentvariabledefinition' from='environmentvariabledefinitionid' to='environmentvariabledefinitionid' alias='EVD'> <attribute name='defaultvalue' /> <attribute name='displayname' /> <attribute name='type' /> <order attribute='displayname' /> </link-entity> </entity> </fetch>
<grid name="resultset" jump="value" select="1" icon="1" preview="1" object="381" > <row name="result" id="environmentvariablevalueid" > <cell name="EVD.displayname" width="100" /> <cell name="EVD.type" width="100" /> <cell name="EVD.defaultvalue" width="100" /> <cell name="value" width="300" /> </row> </grid>
2. Join Solution and Publisher
Query to get the Solution and Publisher to the EVD. Now showing, might be used for filtering too.
<fetch version='1.0' output-format='xml-platform' mapping='logical' distinct='false'> <entity name='environmentvariabledefinition'> <attribute name='defaultvalue' /> <attribute name='displayname' /> <attribute name='type' /> <filter type='and'> <condition attribute='statecode' operator='eq' value='0' /> </filter> <link-entity name='solutioncomponent' from='objectid' to='environmentvariabledefinitionid' alias='SC'> <link-entity name='solution' from='solutionid' to='solutionid' alias='Solution'> <attribute name='friendlyname' /> <filter> <condition attribute='uniquename' operator='ne' value='Default' /> </filter> <link-entity name='publisher' from='publisherid' to='publisherid' alias='Publisher'> <attribute name='friendlyname' /> <order attribute='friendlyname' /> </link-entity> </link-entity> </link-entity> </entity> </fetch>
Layout for the query above.
<grid name="resultset" jump="schemaname" select="1" icon="1" preview="1" object="380" > <row name="result" id="environmentvariabledefinitionid" > <cell name="Publisher.friendlyname" width="100" /> <cell name="Solution.friendlyname" width="100" /> <cell name="displayname" width="100" /> <cell name="type" width="100" /> <cell name="defaultvalue" width="100" /> </row> </grid>
4. Values with Definitions
Query to get the EVD with the EVV, if it’s added.
<fetch version="1.0" output-format="xml-platform" mapping="logical"> <entity name="environmentvariabledefinition"> <attribute name="defaultvalue" /> <attribute name="displayname" /> <attribute name="type" /> <link-entity name="environmentvariablevalue" from="environmentvariabledefinitionid" to="environmentvariabledefinitionid" link-type="outer" alias="EVV"> <attribute name="value" /> </link-entity> </entity> </fetch>
Layout for the query above.
<grid name="resultset" object="380" jump="schemaname" select="1" icon="1" preview="1"> <row name="result" id="environmentvariabledefinitionid"> <cell name="displayname" width="200" /> <cell name="type" width="100" /> <cell name="defaultvalue" width="100" /> <cell name="EVV.value" width="400" /> </row> </grid>
Created my queries and layouts
Yes – I did create this by a still unreleased version of FetchXML Builder – stay tuned!
Are these features I suggest dangerous?
If it is available in the Model-Driven Apps, will everyone be able to change these?
Of course, we use the roles, and we can make sure it only shows if the user has read and/or edit to these tables.
Trust the system.