I've already written a blog, or 2, about my environment strategy, but I want to show some small changes.

I would recommend you read both V1 and V2:

• Power Platform- What’s Your Environment Strategy?
• Power Platform Environment Strategy V2

But in a nutshell, version 1 was focused on each business domain having their own stack (Dev/Test/Prod) and version 2 was a shared stack based on Geo (United States/United Kingdom/Australia etc).

They both have their pros and cons, and very much dependent on your org, and that's why I generally recommend a hybrid, start off with shared and when the domain is qualified they then can have their own stack (along with all of the responsibility and risk).

So what's v2.1, well this expands to cover the nuances of Copilot Studio, AI Builder, and Dataverse.

---

Copilot Studio

There are a few things that have impacted my strategy:

• Microsoft hasn't just bet their house on Copilot, they have bet their sole on it.
• Risks are still relatively unknown
• Increased governance from Orgs

So my strategy is to split out Copilot Studio from all my other environments, creating a almost mirrored approach.

The reasons are:

Future thinking there is high possibility Copilot grows beyond Power Platform (else it would have been Power Agent 😎) So my thinking is if Copilot breaks away and ends up with its own Admin center etc then having segregated environments makes managing that change a lot easier. Additionally once big enough it allows your org to create product teams (a Power Platform CoE and a Copilot Studio CoE as an example).

Next key benefit is from a security and governance side, consolidating everything makes it easier to:

• Monitor - environment level reporting
• License- Messages etc
• Access - Designated security groups per environment
• Security - Bespoke DLP

Because M365 Copilot licenses also allow Copilot Studio creation I lose the control I normally have, so the only way I can really control Copilot Agent creation is reactive automations. In all of the non Copilot environments I have a flow that deletes the agent, if agents were allowed in any environment that process would be almost impossible.

AI Builder

AI builder has similarities with the governance concerns that Copilot Studio (It feels like Copilot has cast a spot light on AI builder causing more governance in some orgs).

But without the future scope of growth like Copilot Studio I have split the difference, with a separate dev environment but then funnel into the normal shared test and prod.

This way we can again the below benefits:

• License- Tokens etc
• Access - Designated security groups per environment
• Security - Bespoke DLP

But don't have to scale out environments that would generally have low capacity.

Depending on your org I would also consider a unified dev that covers all geos.

Power Pages

Although not under the AI spotlight, with its external facing nature Power Pages has its very own spotlight.

To mitigate this we have a very hybrid approach, with our dev and test shared, but production by dept (or even per site).

This can seem overly cautious in something as robust as Power Pages, but having siloed environments for anything external means that if that environment is breached at least it is confined.

Again the segregated approach means we can have tighter control, but the shard dev and test saves on capacity and removes complexity

There are also additional controls:

• Only designated admins can create Site (creating spn's ideally shouldn't be a common permission)
• Limit public publishing to select system admins
• Public testing timeboxed with the site switching back to private after a testing session

Dataverse

And heres probably the most contentious of the strategy, and again very much dependent on your org.

If you are a 100% premium and Dataverse business then Dataverse tables would sit in the normal shared environments. But if you have limited resources, or handle lots of sensitive data then I recommend a segregated approach.

Its very much in line with Power Pages, with a shared dev and test, before branching out to dept environments.

This allows access to data for administration to be simplified, and given to the data owners. But here's where it gets spicy, I would split all Canvas Apps and Flows from the tables and have them in the normal Shared Environments.

This for me has the following benefits:

• Split data access from app/automation
• Easier migration/reuse of data
• Minimises table deployments

---

Oh what a tangled web we weave, Power Platform environments can get super complex not matter how hard you try. But there are few truths we cant escape

• The technologies vary massively
• The platform scales
• The platform is evolving every day
• More and more sensitive data and business critical solutions are in the platform

So its no surprise it is complicated, and every org is unique, every design bespoke, though I would say some key principles should guide your design.

• Plan - plan before you start, the platform is like a oil tanker and very difficult to change course
• KISS - keep it simple stupid, always start from simplicity
• Think Scale - where will you grow and how can you enable
• Leverage - Work into your orgs current process and systems
• Know the Risks - LowCode does not equal Low Risk, your environment strategy is you foundation for risk control

And if all goes to plan you should end up with something like this 😎

---

If you would like to get notified every new blog (I also do a few in the Power Platform Community), subscribe below