Thanks for joining me in Part 2 of this blog post series on creating an autonomous agent in Copilot Studio.
In the previous post, I created a Microsoft Form that will be used by requesters to submit mentoring requests to help them prepare for Microsoft courses.
In this post, I’ll explore environments in Copilot Studio, how they relate to the Power Platform, and how they’re managed through the Power Platform admin portal.
If you missed Part 1, you can find it here: Building an Autonomous AI Agent in Copilot Studio – Part 1: Create a Microsoft Form – Cloud Build
What is an environment and why does it matter?
An environment in Microsoft Copilot Studio (and the wider Power Platform) is a dedicated space used to store and manage agents, data, and related resources. Every agent you build lives inside a specific environment.
Environments help you separate work (for example, keep learning and testing separate from production), apply different security or governance rules, and meet regional or data‑residency requirements. They also make it easier to manage solutions as they grow in size or complexity.
By default, many Power Platform experiences, including Copilot Studio, start in the default environment. However, Microsoft recommends using a non‑default production environment for agents that you intend to deploy to production. This reduces risk and keeps production agents isolated from experimentation or testing activities. The Default environment is a predefined type of environment intended for experimentation, exploration, and lightweight development, not production workloads.
Users are automatically added to Default environment
When a new user signs up for Power Apps, they’re automatically added to the Maker role of the default environment allowing them to make apps, and you cannot prevent this. This allows them to start creating assets, and you can’t prevent this role assignment for the Default environment. Users are not automatically added to the Environment Admin role of the default environment.
The Default environment is created in the region closest to the default region of the Microsoft Entra tenant, and is named as follows: “{Microsoft Entra tenant name} (default)”. The Default environment can be renamed. Furthermore, admins can be assigned to the Default environment to allow more control.
You can’t stop users from accessing the Default environment, but you can use Data Loss Prevention (DLP) policies to restrict which connectors are available there. While this doesn’t completely block app or flow creation, it does limit what users can build. Combining DLP policies with role-based access control and environment segmentation provides a strong foundation for governance. We explore environment types later in this post.
You can’t delete the Default environment. You can’t manually back up the default environment; system backups are done continuously. Furthermore, the Default environment has restrictions such as storage limits. To avoid these restrictions, you will need to set up a production environment. More on types of environments shortly. Learn more about the Default environment at: Default Environment
Common environment strategies
There are many valid strategies for using multiple environments. For example, you may choose to:
- Create separate environments for specific teams or departments, each containing agents and data relevant to that audience.
- Create separate environments for different global regions or branches of your organisation.
- Create separate environments to meet data residency or compliance requirements.
- Use development or sandbox environments for learning and testing, and a production environment for published agents.
More info available at: Work with Power Platform environments – Microsoft Copilot Studio | Microsoft Learn
Task: Create new environment for my Copilot Studio Autonomous agent
- Go to the Power Platform admin center at https://admin.powerplatform.com/ and sign in using your work account. Use the same Microsoft Entra tenant that you use for Copilot Studio.
- Click Manage from the left pane
3. Click New
4. The New environment pane opens as shown in the image below. Let’s explore the fields:
Name: Provide a suitable name for your environment
Make this a Managed Environment (Yes/No): I’m leaving the default setting of No. An explanation is provided below.
What is a managed environment?
A managed environment is a Power Platform environment with additional governance and control features enabled. It is designed to help administrators monitor usage, enforce best practices, and reduce risk as solutions move beyond individual experimentation and into wider use.
Why use a managed environment?
Managed environments provide benefits such as better visibility, policy enforcement, and controlled growth of apps, flows, and Copilot Studio agents. They are especially useful for enterprise scenarios, where organisations want to ensure solutions are built and used responsibly without slowing down innovation. More info at: Managed Environments overview – Power Platform | Microsoft Learn
Group: the drop down displays None by default.
Explanation of Groups
Environment groups allow administrators to organise multiple managed environments into logical collections and apply governance rules consistently at scale, rather than configuring each environment individually. Think of an environment group as a folder for environments, making large Power Platform estates easier to manage. Environment groups can only be used with Managed Environments, which is why this option is not available when creating a standard environment. More info on Groups and how to create them is available at the following link: What are environment groups
Region: Select your region
Explanation:
A region determines where your Power Platform environment and its data are hosted in Microsoft datacentres. When you create an environment, all associated resources, such as Dataverse databases, apps, flows, and Copilot Studio agents are deployed in the selected region. Choosing the correct region is important because it can improve performance by keeping data closer to users, and it helps organisations meet data residency, regulatory, and compliance requirements. More at: Regions
A short explanation of Dataverse is provided shortly.
Type: Select the environment type. Options include:
Developer: A Developer environment is intended for personal development, learning, and experimentation. It is not suitable for production workloads and cannot be converted to a production environment later.
Developer environments are designed for single‑user development, which is why security groups cannot be assigned to them. They provide an isolated workspace for individuals to build and test apps, flows, and solutions without affecting shared or production environments.
Power Platform administrators retain full administrative control, including the ability to allow or restrict the creation of developer environments, create them on behalf of users, apply tenant‑level policies (such as DLP), and delete environments if required.
Developer environments are commonly provided through the Power Apps Developer Plan, which offers a free development environment for as long as it remains actively used for non‑production purposes.
Further details about the developer plan at: Developer plan FAQ
Production: A Production environment is designed for stable, business‑critical workloads. Any app, flow, or Copilot Studio agent that users rely on for daily operations should be deployed in a production environment.
Production environments provide the highest level of governance, allowing administrators to control access, assign security groups, apply policies, and manage lifecycle operations. Microsoft recommends using non‑default production environments for live solutions to ensure proper separation from experimentation and personal productivity work.
Trial (Standard):
A Trial (standard) environment is intended for individual or small‑scale evaluation of Power Platform features. It is typically used by a single user to explore capabilities, build quick proof‑of‑concepts, or test ideas.
Standard trial environments:
- Are free
- Expire after 30 days. Within the last seven days before the standard trial environment is set to expire, the trial environment admin can do a self-service extension of the expiring environment. This extension adds an extra 30 days from the original expiration date. There’s only one self-service extension allowed per standard trial environment. To further retain the environment, it must be converted to production.
- Are usually user‑initiated (if tenant policy allows)
- Are best suited for personal testing or short demos
These environments are lightweight by design and are not intended for sustained work or multi‑team collaboration. When the trial expires, the environment and its contents are automatically removed unless it is converted to production before the expiration date.
Typical use case:
“I want to quickly try a feature, connector, or idea without involving IT or committing capacity.”
Trial (Subscription-based): This type of trial environment allows companies to develop larger, multiuser, and multiple-department solutions and perform proof-of-concept reviews. Tenant admins can add a trial (subscription-based) environment to their tenant. The expiration of subscription-based trial (also known as an admin trial) environments is tied to the subscription’s expiration. More at: Extend Subscription Trial
Sandbox: Used for non-production environments allowing developers to build, tweak and test applications and flows before moving them to a separate production environment so end users can leverage the apps in production. A sandbox environment is the place to safely develop and test application changes with low risk. It is also possible to reset the environment to delete and reprovision it, for uses such as creating a new project, free up storage or remove an environment containing personal data. You can only reset sandbox environments. The reset reprovisions the environment to factory settings and permanently deletes the data. More info: Sandbox Environment
Purpose: Provide a description of the environment’s purpose, such as whether it will be used for learning, testing, demonstrations, or production workloads.
Add a Dataverse data store:
Explanation:
Microsoft Dataverse is the secure data platform for Power Platform. It’s used to store and manage structured business data, such as customers, requests, or records, in a way that apps, automations, and Copilot agents can reliably read from and write to.
Data in Dataverse is stored in tables, similar to Excel tables, with rows and columns that represent business information. Dataverse includes built‑in tables for common business scenarios and also allows you to create custom tables tailored to your organisation’s needs.
Dataverse provides important capabilities such as security, relationships, business rules, validation, and auditing, which help ensure data remains consistent and trustworthy, regardless of which app, flow, or agent accesses it. For example, you can track changes to data, including who made the change and the previous and new values.
In Copilot Studio, Dataverse is typically used when an agent needs to work with structured business data, such as creating or updating records, tracking requests, or retrieving information in a consistent format.
If you already use another data source, such as SharePoint, Excel, or an external database, you can connect to those using Power Platform connectors. However, if you need a native data source built into Power Platform, Dataverse is a good choice because it supports relationships between tables, rich security controls, and scalability without manual infrastructure management.
Dataverse integrates with Microsoft Entra ID (Microsoft’s Cloud Identity and Access Management Solution), allowing admins to control who can read, write, or modify data. It works across all Power Platform services, including Power Apps, Power Automate, and Copilot Studio.
Pay-as-you-go-with Azure
The Pay‑as‑you‑go with Azure option is only available for production and sandbox environment types. It lets you link a Power Platform environment to an Azure subscription so usage is billed based on actual consumption, instead of requiring upfront Power Apps, Power Automate, or Copilot Studio licenses for every user. In Power Apps, Power Automate, or the Power Platform admin center, you can link environments to an Azure subscription using a billing policy.
Once an environment is linked to an Azure subscription, usage of apps and any Dataverse or Microsoft Power Platform requests that go above the included amounts are billed against the Azure subscription.
Use cases for pay-as-you-go with Azure include:
- Widely distributed apps: Use the pay-as-you-go plan for apps that need to be shared with a large user base with infrequent and/or unpredictable use.
- Establish usage patterns: Understand adoption patterns for new apps to determine whether prepaid licenses make financial sense for your business.
- Flexible purchasing: Use an Azure subscription for Power Apps and Power Automate to reduce license procurement overhead and consolidate with other Microsoft services. This is especially helpful if you already have an Azure subscription. More info at the following link: Pay-as-you-go plan
5. Click Next.
6. I’ll be leaving the default language as English US and currency as USD. Feel free to change as per your requirements.
Custom URL
There is an option to use your own domain name. If you leave the default option, a URL ending in *.dynamics.com is automatically created for you.
Deploy sample apps and data: Sample data gives you something to experiment with as you learn, and is optional.
7. Click Save
That’s it for this post. I hope you found it useful.
In the next blog post, I will build a Copilot Autonomous AI Agent in my new developer environment using Copilot Studio. Click the following link to continue to part 3: Building an Autonomous AI Agent in Copilot Studio – Part 3: Create a Copilot Studio Agent (Name, Image, Description, and Instructions) – Cloud Build
