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.

Developers, working with the Environments Variables in the Maker Portal.

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.

During the import, the EV without any default value are asked for the user to add the values.
If not added during the import, you see it if you look really hard, a small yellow notification at the bottom of the Home page in the Maker Portal.

Read more:

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.

Only primary name and created on columns can be seen, for both EVD and EVV.

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.

Why?

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.

Problems today

These are the problems that need to be fixed. Gladly all of these, or maybe a few of these:

  1. I can’t really use the views that Microsoft created.
  2. I can’t create a specific view for my product.
  3. I can’t join the Solution or Publisher in OOB.
  4. I can’t create a view showing all settings and all values if they are added.
  5. I can’t validate the values in the Model-Driven Apps.
  6. I can’t use Quick Create Forms to enter the values.
  7. I can’t find the settings to change the values.
  8. 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:

See code here.

For EVV, show EVD Display Name, EVD Type, EVD Default Value, and Value, see here:

See code 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.

Seeing the context – that helps a lot. But the joins to Publisher and Solution are ‘too far away’ from the root table (EVD), that’s why Model-Driven views can’t show it. Would be nice to fix that too… See code here.

3. Make Solution a proper relationship

This could be fixed in two ways:

  1. Make the Uniqueid to a proper Lookup from SolutionComponent to the EVD.
  2. Actually use the solutionid. When I create a setting, the solutionid is always set to the Active solution. Why? I don’t know…
Joining from EVD to the SolutionComponent table is impossible. Not a Lookup, just a ‘stupid Guid‘… See code here.

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:

1:1-relationships from EVD to EVV. Unfortunately, the Value (last column) is showing the column name incorrect, the views in Model-Driven apps are wrong here. See code here.

5. Validate values by type expected

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?

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…

Managed Solution, and their local Values are not available here.
Default Solution, Environment Variables – Current Value is available!

I suggest:

  1. Make this available from the source solution, save the local values outside of the solution.
  2. 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

Query:

Layout:

Default view for EVV

Query:

Layout:

2. Join Solution and Publisher

Query to get the Solution and Publisher to the EVD. Now showing, might be used for filtering too.

Layout for the query above.

4. Values with Definitions

​Query to get the EVD with the EVV, if it’s added.

Layout for the query above.

Created my queries and layouts

Yes – I did create this by a still unreleased version of FetchXML Builder – stay tuned!

Preview of newest release – coming up soon (?) – Click to see enlarge!

Dangerous?

Are these features I suggest dangerous?

If it is available in the Model-Driven Apps, will everyone be able to change these?

Nope.

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.