Definitely not the most exciting part of any development, especially for Low Code developers. But environment strategy is key not only in making your development easier but critical when dealing with Application Lifecycle Management.
I was very fortunate to have a fantastic Architect who had a robust strategy for our environments, I never appreciated them until we had a working meeting with Microsoft and they explained what happens without a strategy.
So I wanted to share what my ideal strategy would be.
Everyone knows there are 4 main environments
- Dev
- Sandbox
- Trial
- Prod
But there are also Default (Personal Productivity) and Dataverse for Teams.
https://learn.microsoft.com/en-us/power-platform/admin/environments-overview
When I look at the all 6 I decided there was 2 I didn't want to use:
Dev - These are only for Developer Plans and proposed just for one owner.
Dataverse For Teams - This is a little controversial, as there are benefits to DfT (Free Dataverse Storage, easier group management). But I found the negatives of poor administration, as you cant see DfT inside Power Platform Management Connectors (Check out my previous blog if you want to know more dev.to/wyattdave/power-automate-99-admin-connectors-because-1-just-wont-do). And on top of that it's difficult to create a Dev-Test-Prod setup. Though there is one use case where it might be worth using it, and that's for Power Virtual Agent exploration, as a license isn't needed while in Teams.
So that left Sandbox, Trial, Prod and Default. Default is an interesting one, as its unique, but still should be within your strategy.
Default Your Default or Personal Productivity environment is where all of your developers should start, a place to play and create personal automations. It is also key to your SharePoint setup, as using Flows triggered by list Items, and Power Apps to form for items (Replacing InfoPath), can only be created in Default. For a strategy its key this is locked down as much as possible, with no custom or non standard connectors allowed in its DLP. The level of Flow and App should also be controlled (Currently through the CoE pack flagging but hopefully in future Microsoft introduces granular control). These levels should be around the number of Flow runs and App users. As soon as they are over a threshold they should be moved to a proper environment.
So onto your 'proper' environments, the nuts and bolts of it is there are 3 areas that impact your Environments:
- Data Loss Prevention Policy (Connectors)
- Geographic Location (Lag)
- Data (What data is stored in Dataverse)
Location is normally more of an issue for Power Apps and Power Virtual Agents, as the user experience can be degraded by slow loading and interacting apps. Yet this can also be a concern for Power Automate and where the APIs/data is stored.
Fortunately data is normally covered by location and connectors. As in most cases data storage controls and legislation is impacted by location. And users of data normally aligns with same users of connectors. So our strategy should focus on segregation of connector uses and location.
My recommend approach is by Business Dept (Connectors used and Data access) and Geo (Minimalize lag and for data storage).
So I would provision my environments:
BusinesDept-Type-Geo-Status
Where type is our Sandbox / Trial / Production and Status is Dev - Test - Prod.
The next thing to think about is using the right type. A good practice is to use Trial environments for non prod. Trial environments are time boxed at 28 days, after which they are auto deleted. The reason these are good for Dev and Test are:
1.Stops them being used as prod
- To ensure all projects go through proper intake/impact assessment
2. Removes rarely used environments
- Low Code can often be built intermediately as they are often not full time developers, leaving environments not being used but taking up space
3.Clears unused/testing/exploring projects
- Developers aren't always the best at house cleaning
4. Ensures Prod control
- By enforcing new development is taken from the Prod copy stops unknown changes slipping through (e.g another developer editing dev copy without anyone knowing)
The only time I wouldn't use trial environments are for dedicated development teams, here I would recommend using Sandbox for Dev and either Trial or Sandbox for Test.
Their is one caveat to using Trial environments, and that is the need for Full or Partial automation in provisioning them. Else this would become an overhead to maintain and may slow down development projects.
Unfortunately currently setting up maintaining Data Loss Prevention (DLP) policies is a manual process, and with the continued rollout of new connectors it isn't a setup up and walk away process. So wherever possible its a good idea to share DLP if possible. That way you are updating less, but have flexibility to change an environments DLP policy easily at a later date.
So I would always have something like this:
- Default DLP (for Default Environment, highly locked down)
- Standard DLP (used by most environments and bespoke ones are cloned from)
- Innovation (most open, used for innovation, tests and trials, ideally should be used in Trial environments only)
- Bespoke (provisioned for environment with bespoke connector requirements)
Inline with minimizing DLP policies you can also decrease number of Dev environments by sharing cross location. As Finance in UK and US will most likely use same DLP, but as Dev (and sometimes Test) isn't production data they can share them. Additionally lag isn't a concern. As a default using US is recommended, as new features generally rollout there first.
As with most things there is no right answer to an environment strategy everyone's will be different. The key thing is that you have one.
Top comments (0)