One Does Not Simply Build in Production” – Nevermore’s Environment Strategy Unpacked

Welcome back. In our first blog, we introduced you to Nevermore Technology’s sprawling (and entirely intentional) setup—five Dynamics 365 instances, each with their own job to do, and a Power Platform strategy that’s built on ALM best practices rather than wishful thinking.

Today, we’re talking about the one thing that keeps all of this from becoming an absolute disaster: environment strategy.

First Things First: What Even Is an Environment?

In Power Platform terms, an environment is a space where your apps, flows, data, and components live. Think of it like a sandbox, except some sandboxes are for building, some are for testing, and some are for not touching unless you’ve signed a release form.

If you’ve only ever worked in “Default” and someone’s told you it’s fine to build your production apps there—I’ve got bad news. That’s not an environment strategy. That’s how we get form merge conflicts and someone’s cat named “Buttons” showing up as a Contact in your live CRM.

The Nevermore Standard: Four Environments Per Instance

For each of Nevermore’s five Dynamics 365 instances, there’s a Dev, Test, Pre-Production, and Production environment. That’s a total of 20. Yes, 20. It sounds excessive until you realise it’s actually the bare minimum for sane ALM.

Let’s break it down.

1. Development (Dev)

This is the wild west. Makers, developers, and technically adventurous interns build and test freely here. Every change is made inside an unmanaged solution, tracked with source control, and nothing here is sacred.

Permissions: Developers and makers only.
Key use: Building, testing, breaking things on purpose.

2. Test

Once the build’s ready, it moves to Test. This environment is used for automated tests, manual testing, and integration checks. The solution is now managed, and it should behave the same way it will in production. Emphasis on should.

Permissions: QA testers, solution reviewers, UAT coordinators.
Key use: Validating if your “fix” actually fixed anything without breaking five other things.

3. Pre-Production

A near-exact replica of Production. Final stop before going live. It runs in the same region, same data types, and usually has mocked-up versions of integrations and data flows.

Permissions: Deployment teams only.
Key use: Staging deployments, validating full deployments end-to-end, and one last chance to panic before go-live.

4. Production

The real deal. The live customer experience. Not a place to experiment. Not a place to test new flows at 2am. Not the place for your canvas app labelled “Test_2_final_REALLY_FINAL.msapp”.

Permissions: Read-only for most, strict admin access.
Key use: Serving actual users who don’t want to hear the words “solution layering conflict.”

Why Not Just Have Two Environments? It’s Quicker, Right?

Yes, just like crossing the motorway on foot is quicker than walking to the pedestrian bridge. The extra environments aren’t about delay—they’re about control, predictability, and disaster avoidance.

By the time something reaches production in Nevermore’s world, it’s passed through three stages of testing, validation, and sign-off. And because everything is solution-based, layered correctly, and moved using pipelines, they know exactly what was deployed, when, and by whom.

You don’t get that clarity when you’re publishing directly from make.powerapps.com and praying to the Dataverse gods.

Region and Versioning Matters (And Yes, It Bit Us Once)

One of the sneaky little surprises in Power Platform is that environments in different regions might be on different service update schedules. So if you build your solution in Canada (Station 2) and deploy it to the US (Station 5), you might hit compatibility issues.

Rule of thumb: your development environments should always be in a region that updates before or at the same time as production. That way, your exported solutions don’t end up missing dependencies or unsupported components.

[Placeholder for Image: Map of Power Platform service update stations with arrows showing safe deployment directions]

More info here: Released versions of Microsoft Dataverse

Naming, Permissions, and Policies

Nevermore uses naming conventions like:

• Sales-Dev-UK
• Support-Test-NA
• CanvasApps-PreProd
• Integration-Prod-EU

Why? Because when you’ve got 20 environments and three pipelines running simultaneously, ambiguity is your enemy. The same goes for security roles—each environment is locked down to match its purpose.

No, Bob from Marketing doesn’t need access to the Dev environment for Support. And yes, he asked. Twice.

Bonus Tip: Avoid the Default Environment

It’s there. It exists. It’s automatically created for every tenant. But for the love of all things structured, don’t use it for anything real.

You can read more here: Default environment guidance

Next Up: Solutions—Your New Best Friend (and Occasional Nemesis)

Now that you’ve seen how Nevermore keeps its house in order with environments, the next logical step is how they move apps and automations around.

In Blog 3, we’ll dive into solutions: unmanaged vs managed, how to avoid layering hell, and why segmentation matters more than you think. We’ll also touch on why the Common Data Service Default Solution is not your friend.

Until then, go double-check your environment names. If you’ve got “Test” and “FinalTest” sitting beside “Production2,” we need to talk.