Environment Management

Overview

Building and deploying agents in a single environment is a common starting point, but it is a risky long-term strategy. One accidental change to a live agent can break the experience for every user. Environments give you the separation you need—a place to build, a place to test, and a place to run production workloads, each with its own configuration and security controls.

This video walks you through setting up an environment strategy for Copilot Studio, moving agents between environments using solutions, and managing environment-specific configuration for government cloud tenants.

What You’ll Learn

• Environment strategy: How to structure development, test, and production environments
• Solution management: How to package and move agents between environments
• Environment configuration: How to handle settings that differ per environment
• Governance: Best practices for managing environments at scale

Script

Hook: One environment is not enough

If you are building and deploying agents in the same environment, you are one accidental publish away from breaking your live agent. A topic change that seemed fine in testing might confuse users. A connector update might point to the wrong data source. And there is no easy way to roll back.

Environments give you separation between development, testing, and production. In the next eight minutes, I will show you how to set up an environment strategy for Copilot Studio that protects your live agents while giving builders the freedom to experiment.

Environment strategy for Copilot Studio

Let us start with what an environment actually is. In Power Platform, an environment is a container that holds agents, Power Automate flows, Dataverse data, and configuration. Each environment has its own security settings, DLP policies, and user access controls. Think of it as a self-contained workspace.

When you first set up Copilot Studio, a default environment is created automatically. This default environment is fine for initial exploration, but it is not ideal for production workloads. It has limited governance controls and is shared by anyone in your tenant who has a license.

The recommended strategy is to create at least three environments.

First, a development environment. This is where builders create and iterate on agents. It should have relaxed controls so people can experiment freely—try new connectors, test different conversation flows, and break things without consequences.

Second, a test or staging environment. This is where completed agents are validated before going live. It should mirror production as closely as possible—same DLP policies, same security configuration, same data structure. Testing here catches issues that would otherwise surface in front of real users.

Third, a production environment. This is where approved agents serve real users with real data. Access should be tightly controlled. Only approved deployers should be able to import solutions into production.

The reason this matters is straightforward. Changes in development do not affect production. Testing happens in a realistic but safe environment. And production stays stable because only validated, reviewed agents get deployed there.

In government clouds, environments are tied to your tenant and respect your data residency boundaries. Each environment has its own security configuration, DLP policies, and access controls. This means you can apply stricter policies to production while keeping development more flexible—an approach that aligns well with government security frameworks that emphasize layered controls.

Moving agents between environments

The mechanism for moving agents between environments is the Power Platform solution. Solutions package your agent and its dependencies into a portable unit that you can export from one environment and import into another.

Here is how the process works.

In your development environment, add your agent to a solution. A solution is essentially a container—it holds the agent, all its topics, entities, connectors, Power Automate flows, and any other components the agent depends on. If your agent uses environment variables or connection references, include those in the solution as well.

Once your agent is ready for testing, export the solution from the development environment as a managed package. Managed is the key word here. A managed solution is read-only in the target environment—nobody can edit the agent’s topics or change its configuration directly. This prevents unauthorized changes in test and production.

Import the managed solution into your test environment. Run your validation tests—check every topic, every connector, every conversation path. Confirm that the agent behaves correctly with the test environment’s data and connections.

After testing, import the same managed solution into production. The agent is now live, read-only, and protected from accidental modifications.

The distinction between managed and unmanaged solutions is important. Unmanaged solutions are editable—use them in development where you need flexibility. Managed solutions are read-only—use them in test and production where you need stability. Never import an unmanaged solution into production.

For government agencies with formal change management requirements, the solution export and import process provides an auditable record of what was deployed and when. Each import creates a record in the environment’s solution history. Combine this with your agency’s change advisory board process for production deployments to maintain a complete audit trail.

Managing environment-specific configuration

Your agent almost certainly has configuration values that differ between environments. A SharePoint site URL might be different in development than in production. An API endpoint might change per environment. A feature flag might be enabled in test but disabled in production.

Environment variables solve this problem. An environment variable is a named value that you define in your solution and set differently in each environment. When your agent needs a URL, it reads the environment variable instead of using a hardcoded value. When you import the solution into a new environment, you set the variable’s value for that environment—no need to edit the agent itself.

For example, if your agent retrieves documents from a SharePoint site, create an environment variable called “DocumentLibraryURL.” In development, it points to your dev SharePoint site. In production, it points to the production site. The agent’s logic stays identical. Only the configuration changes.

Connection references work similarly for connector authentication. Each environment has its own connections—authenticated links to services like SharePoint, Dataverse, or external APIs. When you import a solution, you map the solution’s connection references to the target environment’s existing connections. This ensures the agent authenticates correctly in each environment without modifying the agent itself.

In GCC High and DoD, some service endpoints differ from commercial and GCC. Use environment variables to manage these differences cleanly. This avoids hardcoding URLs that change between environments and ensures your agent connects to the correct government cloud services. It is a simple practice that prevents a common and frustrating category of deployment failures.

Best practices for environment governance

With your environments in place, apply governance to keep them manageable.

Restrict production environment access to admins and approved deployers. Use Entra ID security groups to control who can import solutions into production. This is your final gate before an agent goes live.

Use managed environments for production. Managed environments are a Power Platform feature that enables additional governance capabilities including usage insights, sharing limits, and solution checker enforcement. They give you more control over what happens in production.

Apply DLP policies per environment. Your development environment can have more permissive policies so builders can experiment with different connectors. Your production environment should have strict policies that enforce your agency’s data protection requirements. This per-environment approach gives you flexibility without compromising security.

Use clear naming conventions. Name your environments so their purpose is obvious—something like “CS-Dev,” “CS-Test,” and “CS-Prod.” When someone looks at the environment list in the admin center, they should immediately understand what each environment is for.

Perform regular cleanup. Archive or remove environments that are no longer in use. Environment sprawl makes governance harder and increases your administrative overhead. If a project is complete and its agent is in production, the development environment can be cleaned up.

Document your environment strategy so new team members understand the process. Include which environments exist, who has access, how solutions are promoted, and what approvals are required. A shared wiki page or a document in your team’s SharePoint site is sufficient.

One final tip: create an environment request process. When someone needs a new environment—for a new project or a new team—route the request through your admin team. This prevents environments from proliferating without oversight.

Close: Environments protect your agents

Let us recap. Start with a multi-environment strategy: development for building, test for validation, production for live agents. Use solutions to move agents between environments—managed exports for test and production, unmanaged for development. Use environment variables and connection references to handle configuration differences. And apply governance at the environment level with access controls, DLP policies, and managed environment features.

Environments are the foundation of professional agent development. They protect your users from untested changes and give your builders a safe space to innovate.

Next up, we will cover DLP policies for controlling data flow in and out of your Copilot Studio agents.

Sources & References

• Copilot Studio environments first run experience — Getting started with environments in Copilot Studio
• Power Platform environments overview — Comprehensive guide to environment types and management
• Copilot Studio documentation — Main documentation hub for Copilot Studio
• Solution concepts for ALM — Application lifecycle management with solutions for packaging and deploying resources