Before we start fleshing out the build for our self-employed business solution, we need somewhere for it to live! We’ll create Power Platform environments for this, so this blog will go over what they are, why they’re used and how to create them.
A Power Platform environment is a dedicated area to store and manage apps, flows, chatbots, data, security and more. In the business world, you might see environments for different departments or critical solutions.
To explain environments to someone completely new to the Power Platform, I liken them to a house. A house is a ringfenced area for a specified group of people. You’re still part of a wider community that has guardrails in place, but it’s your own space to operate as you wish.
In environments, we build solutions to meet our business needs. In a house, each room is a solution to our needs. A living room is our relaxing solution, kitchen our cooking solution and bedroom our sleeping solution (except in my house, which case a bedroom is a ‘lie awake for ages then get jumped on at 4am by a crazy 7yr old’ solution).
Environments also allow us to configure unique security. For example, you might be a system administrator whereas others may only be able to view particular resources. Again, not too dissimilar to a house; my wife & I have keys to our house, we do all the washing, cooking, cleaning and all that other fun stuff – we’re administrators of our environment. Our daughter has some independence, being a child she operates in our environment but under a smaller, or different capacity.
Environment types
There are 6 standard environment types:
- Dataverse for Teams
- Default
- Developer
- Production
- Sandbox
- Trial
Microsoft cover what role(s) each of these Power Platform environments can play in a Microsoft 365 tenant, security settings and database storage can be the main things to differ between each.Â
For the purposes of the solution for my wife’s business, we’re going to go with a typical 3 environment setup:
I was recently explaining this concept to someone and they asked “why create Sandbox environments instead of x2 Production environments?“.
A sandbox is an environment that’s a simulation of your Production environment. You’d use a sandbox for testing, debugging, experimenting, before promoting to Production. But why the name ‘sandbox’? Luckily, our best friend Google sheds some light:
“The word sandbox is derived from the sandboxes / sandpits, containers filled with sand for children to play with. Instead of setting up a real playground which would be costly and time-consuming, these sandboxes simulate an environment where children can play as they would outside“.
So ‘Sandbox > Sandbox > Production’ is pretty common, right? It’s going to be fine in my scenario but less so for larger organisations who’ll rely heavily on testing.
Environments in the Power Platform are assigned DTU’s – Database Transactional Units – which is a combination of RAM, processing power and hardrive space. Microsoft assign less DTU’s to sandbox environments as they are seen as a lower priority compared to Production environments. If you’re planning on using a sandbox for loads of testing, you may see your solutions running slower than normal as they’ve not got enough grunt behind them. It’s therefore a worthwhile consideration when planning any environment strategy.
Another part of having a multiple environments in place is to build, test and formalise Application Lifecycle Management (ALM) processes, but I’ll cover those in a future blog.
Who can create environments?
To create something in Microsoft 365, you’ll likely need elevated privileges. You’ll need to be an M365 Global Admin or have the Power Platform Administrator role if you want to create an environment.
Creating an environment
With the right level of access, here’s how to create an environment in your tenant:
1) Login to the Power Platform Admin Centre
2) Select ‘Environments’ from the left-hand menu, click ‘New’
Initial properties
3) In the slide-out pane that appears, populate the following:
Name: Make sure this is concise so others can easily understand its purpose. Depending on your internal strategies or guidance, you may need to follow a pre-defined naming convention.
Region: This is SUPER IMPORTANT!! Ensure you select the region that best complies with any geographical requirement(s) or laws for any data you’ll potentially store in the environment. Speak to your internal Information Governance/Security teams if you’re not sure. You cannot change this once the environment is created.
Type: Select the type of environment you need.
Purpose: Not mandatory, but good practice to whack in a brief description of what the environment is for.
Add a Dataverse data store? Decide whether you want the environment to have a Dataverse database installed. Don’t worry if you select ‘No’ at this point, you can provision one retrospectively at any point in future.
Â
Additional properties
4) If you choose not to have Dataverse installed for the environment, you can save the configuration and your new environment will start provisioning. Otherwise, you’ll have some more information to complete:
Language: Default language shown for environment users.
URL: This is optional, but similar to ‘Name’ in that you may have an organisational/departmental URL convention that may need to be adhered to.
Currency: Relevant currency that any environment reporting will be shown in.
Enable Dynamics 365 apps and data? Gives you the option to add Dynamics 365 apps such as Dynamics 365 Sales and Field Service. You need to have an appropriate Dynamics 365 license in order to select Yes.
Deploy sample apps and data? It’s up to you whether you want to deploy sample apps and data; this will be defaulted to ‘Yes’ and is a good option if you want some additional material to mess about with.
Security group: For some environment types, you’ll need to specify a relevant Security group (typically a predefined Azure AD Group or Office Group membership) or set to ‘None’ if the environment will be open to everyone.
For the purposes of building personal projects in my own tenant I can set this to None, but in normal day-to-day business, it’s prudent to grant access only to the group of people who will need it.
Applying security roles
Once you’ve created any environment, you’ll need to configure extra security. Users of your chosen security group still need a further level of security to build apps and flows, or view data.
Any developer will need the System Customizer role if your environment has a Dataverse database, or the Environment Maker role if it hasn’t. Similarly, an administrator will need either the System Administrator or Environment Administrator role. As a base, any other user will need the Basic User role. You can also create custom security roles and apply them as required.
To assign a security role to a user:
1) access the relevant environment and select ‘Users’:
2) Select the user in question and click on ‘Manage roles’:
3) Select / de-select the required role(s) and click ‘Save’
What if I'm not an admin?
Microsoft have you covered! Using your work or personal email, you can sign up for a Power Apps Developer Plan – essentially a developer environment just for you, with all the bells & whistles at no cost to you or the business.
Information about the Power Apps Developer Plan is here, or you can dive straight in by going here.
Don't forget Data Loss Prevention!
Your company may have Power Platform Data Loss Prevention in place, in which case any new environment may be added (either by default or manually) to a relevant policy. Power Platform DLP is a very important topic and one that’ll have its own dedicated post soon.
We now have the environment structure needed for developing not only the solution for my wife, but all the other personal projects that will have their own blog series in future.
In my next post, we’ll get into understanding and creating a Power Platform solution.
Hi Craig
Great article. This stuff is really cool