I was going to come up with an intro for this post to describe how diverse Power Platform has become etc, but it seems to be a moot point, I just need to admit that, normally, I do a lot more work with the Dataverse-backed apps / flows than with any other apps/flows.
So, from that perspective, Default environment is, mostly, useless. Which, of course, is not the case in general, since it’s the only environment where every citizen developer can create apps/flows without having to request a dedicated project environment, without having to create a trial, and without having to subscribe for an individual dev environment.
Essentially, Default environment is meant to become a mess in that sense, since it’s a sandbox for everyone, and, depending on the size of the organization, there will be all those hands in that sandbox.
That’s why Microsoft has been suggesting to think of the Default environment as of a personal productivity environment, but, of course, the boundaries are somewhat vague. There is a table below which I copy pasted from this link: https://learn.microsoft.com/en-us/power-platform/guidance/adoption/manage-default-environment
The purpose of having this table here is to illustrate decision-making process you may have to follow to see if an app should be kept in the default or not, but, of course, not every citizen developer would be aware of those considerations, so a lot of this is going to fall on the admins. And, besides, some of the criteria may be organization-specific:
In either case, there is at least one type of production applications which might end up in the Default environment without anyone intentionally trying to put them there, and it’s Sharepoint form apps, since, by default, Default environment would be used for that.
Coming from the Dataverse side, you might actually ask what are those sharepoint form apps, so here is an example. Imagine you had a list in Sharepoint – you might be adding items to the list using default sharepoint form for that list:
Or you might go to that list and create a new form as a Power Apps application:
So to give that “Title” field a different label on the form, for instance (which is, probably, a lazy example, but still):
If you wanted to check right away how it’s been set up in your tenant, you could use Get-AdminPowerAppSharepointFormEnvironment cmdlet from the admin module to find out sharepoint forms environment id/name:
In my example above, “Default” is where it all goes.
You could also find out which form apps are stored there using Get-AdminPowerApp cmdlet:
Get-AdminPowerApp | Where-Object {$_.DisplayName -like ‘*forms*’}
In my case I have “Contacts on Test Group forms” app listed above, and that’s the one I just created.
I used to think “Default” is where it will always go. Apparently it’s not the case anymore, and it has not been for a while.
You can use Set-AdminPowerAppSharepointFormEnvironment cmdlet to specify the environment which should be used for Sharepoint form apps:
Set-AdminPowerAppSharepointFormEnvironment  –EnvironmentName ‘EnvironmentName’
Your existing Sharepoint form applications will not move to the new environment – they will stay in the original (likely in the Default) environment, even though, moving forward, you’ll get all new forms created in the dedicated environment instead.
Actually, moving forward, you may end up having Power Apps form applications stored in different Power Platform environments for exactly the same Sharepoint environment. Some of them will be stored in the Default, and others will be stored in the new dedicated environment.
So where does it leave us?
- We can specify the environment that will be used for Sharepoint form applications
- The sooner we do it the better, since, if there is a Sharepoint form application in the Default environment already, it will stay there
- And we cannot do the same for the Flows created from Sharepoint – they stay in the Default no matter what
For the last item above, there seem to be no way we could even identify those flows by name (as in, there is no “sharepoint” keywords anywhere in the flow name):
Well, personally, I’d be on the fence after reading this? It seems to make sense to have a dedicated environment for Sharepoint “integration” to facilitate Default environment administration. However, if we can only implement that approach for some of the integration components, we may end up having those administrative efforts increased instead.