Personalized Community is here!
Quickly customize your community to find the content you seek.
Spotlight Hall of Fame
Check out the Dynamics 365 community all-stars!
2023 Release Wave 1Check out the latest updates and new features of Dynamics 365 released from April 2023 through September 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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.
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.
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.
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.
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.
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?
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…
CanCreateView = true
CanCreateForm = true
IsCustomizable = false
So we can create/edit views for personal views, but the system views are locked.
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:
Don’t worry, I don’t only complain… I give you the solutions! Read on!
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:
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.
This could be fixed in two ways:
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:
Some things are easy to validate by types – Number, JSON, Yes/No, and of course Text.
Currently, other more complex types like Data source and Secret, need a bit more intelligence. It might need to connect to Azure etc. That may be hard. But why not easily add the simple validations?
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.
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…
Just flip it to a multi-line attribute, helps us a lot.
Query to get the Solution and Publisher to the EVD. Now showing, might be used for filtering too.
Layout for the query above.
Query to get the EVD with the EVV, if it’s added.
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.
The post A few requests for Environment Variables appeared first on JonasR.app - the Trenches.
Business Applications communities