DEV Community

Cover image for The Default Environment: Dos & Dont's
Fernanda Ek
Fernanda Ek

Posted on

The Default Environment: Dos & Dont's

Power platform developers often find themselves scratching their heads when they deploy crucial applications/automations to the default environment. As my C# professor use to say "It's like the Bermuda Triangle" of environments – easy to get lost in! The lack of clear documentation adds an extra layer of mystery, making us feel like we're deciphering ancient hieroglyphics.

So, let's unravel the enigma and find out what this default environment is all about and why it might not be the best choice for production purposes.

What exactly is the default environment?

Think of the default environment as a pre-set production zone automatically generated for each tenant. It's like a communal playground where everyone's invited to play and they get an all-access pass to the default environment, like entering a cool club!

But beware! There are some pitfalls to avoid if you're considering the default environment for production.

Why not risk it all on the default environment?

First of all, to keep your data and apps separate from other environments. You don't want unauthorized peeps poking around your important stuff, right? Plus, in the default environment, everyone has permission to create apps and flows, and there's no way to block that. Non-default environments give you more control over who can do what. Another reason is that you can't back it up or restore it, which can be risky for your data.

Tips

  • Create clear procedures and instructions for users to ensure proper usage of the default environment

  • Implement a governance framework to oversee its operations

Conclusion

The default env. is perfect for first-party integrations, like turning a boring SharePoint list into a bold app. But don't put your super important or business-critical apps there and remember to give it a good name to make its purpose clear.

Top comments (1)

Collapse
 
nlxdodge profile image
NLxDoDge • Edited

We even have 4 environments:

  • Development (where every outbound connection is mocked, might be broken often)
  • Test (more stable should be only used for functional testing)
  • Acceptance (used for customer acceptance and also a 1 on 1 copy of production, this way load testing can be done as well)
  • Production (😎 the actual production cluster).