Catalogue › Copilot Studio › studio-environments

Studio environments

Applies the organisation's environment strategy to Copilot Studio work - the concrete personal, team, test and production environments makers use, environment routing for new makers, Managed Environment and agent settings per zone, security groups, data policies and how agents move between zones. Use when makers start building agents, when agents pile up in the default environment, or when a team asks for its own development space.

Department

Copilot Studio

Lifecycle

Mobilise, Deliver, Scale

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

copilot-studio, power-platform, entra

Editions

starter, scale, enterprise

Reviewers

design-authority, security-privacy

Status

draft

Copilot Cowork

Copilot Studio plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Copilot Studio makers need somewhere safe to experiment, somewhere to build properly and somewhere controlled to run agents others depend on. This skill turns the organisation's environment strategy into the concrete environments, routing rules and settings Copilot Studio makers actually use, so building is easy and production is controlled. It usually goes wrong when every maker builds in the default environment, when each team is given a bespoke environment with no consistent settings, or when environments are so locked down that makers turn to unmanaged tools instead.

When to use

• The organisation is opening Copilot Studio to makers and needs the environments ready.
• Agents are accumulating in the default environment with no clear owner or route to production.
• A team asks for its own development, test or production environment for agents.
• Environment settings, data policies or security groups for Studio work need to be made consistent.

When not to use

• Setting the organisation's environment strategy and governance zones for all AI building - use platform-governance:ai-environment-strategy.
• Environment topology across Microsoft 365, Power Platform and Azure - use ai-architecture:environment-topology.
• Who may build and share agents and flows - use platform-governance:maker-governance.
• Moving a specific agent between environments with solutions and pipelines - use copilot-studio:studio-alm.

Questions to ask first

1. What governance zones has the organisation agreed, and what may happen in each (personal productivity, team collaboration, enterprise production)?
2. Where do new makers land today when they open Copilot Studio, and what is already in the default environment?
3. Which teams build agents regularly enough to need their own development and test environments?
4. Which data policies, sharing limits and security groups apply in each zone?
5. Who administers each environment and approves promotion between zones?

Required inputs

• The environment strategy and zone definitions from platform-governance:ai-environment-strategy.
• Data policies from platform-governance:connector-policy.
• An inventory of existing environments and agents, for example from the CoE Starter Kit or admin reports.
• Security groups for makers and audiences, owned by the identity team.

If no environment strategy exists, do not invent zones here; hand back to platform-governance:ai-environment-strategy and, in the meantime, at least stop new production-bound agents being built in the default environment.

Decision framework

Every non-personal environment is a Managed Environment with a security group, agreed data policy, named admin owner, and consistent settings for sharing, analytics and agent capabilities. Create a new environment only when an existing one cannot meet a distinct owner, data boundary, region or release cadence.

Practitioner approach

Start with where makers actually are. Inventory the default and other environments, list the agents in them, their owners and audiences, and identify those that are shared widely or use business data. These are the agents to move first, and they show what the zones must support.

Design routing before opening the doors. Environment routing can send new makers to a personal or developer environment rather than the shared default, so experimentation does not pollute a common space. Agree what makers see when they first open Copilot Studio, and publish a short guide explaining which environment to use for what. Makers follow the path of least resistance; make the governed path the easy one.

Define a small, repeatable set of environment types rather than bespoke environments. For each type, fix the settings: Managed Environment on, security group, data policy, sharing limits, whether web knowledge or unauthenticated agents are permitted, analytics and transcript settings, and the admin owner. Apply the same type the same way every time, ideally from a script or checklist, so settings do not drift.

Give regular building teams their own development environment and a shared test environment, and keep production environments free of direct making. Changes reach production through solutions and pipelines, which copilot-studio:studio-alm designs. Production environments are where business owners, support and reviewers can rely on what they see.

Agree how an agent graduates. A personal prototype that proves useful is rebuilt or exported as a solution into a team development environment, gains an owner and brief, and follows the release path. Write the graduation criteria down so makers know what is expected before their agent can be shared more widely.

Plan the default environment's future. Decide what may stay there, how existing shared agents are moved, and how makers are told. Moving agents takes effort; prioritise those with wide sharing, business data or no owner.

Review environments quarterly with the platform owner: unused environments, settings drift, agents in the wrong zone and capacity. Route capacity and licence questions to platform-governance:ai-licensing-and-capacity.

Outputs

• An environment catalogue for Studio work: each environment, its zone, type, purpose, admin owner, security group, data policy and settings.
• Environment routing rules and a maker guide explaining where to build what.
• Graduation criteria for moving agents between zones.
• A remediation list for agents in the wrong environment, with priority and owner.
• The environment section of the alm-and-environment-plan.

Microsoft platform considerations

Environment routing, Managed Environment features, agent-specific admin settings and data policy controls change frequently and some depend on licensing. Check ms-copilot-studio-zoned-governance, ms-copilot-studio-security-governance and ms-managed-environments for the current position, use ms-coe-starter-kit for inventory, and route licensing questions to the licensing guide or a licensing partner.

Adoption considerations

Makers abandon governed routes that are slow or confusing. Publish the maker guide with the environments, offer a fast request route for team environments, and celebrate agents that graduate properly.

Knowledge considerations

Not applicable to environment design itself, because environments contain agents rather than knowledge; note only that knowledge connections and uploaded files must be re-established when agents move between environments.

Security and privacy considerations

Production environments have restricted maker access, security groups, appropriate data policies and controls on unauthenticated agents and web knowledge. Agents using sensitive data do not live in personal or default environments. Environment settings that affect data exposure go to security-privacy:data-exposure-review.

Responsible AI considerations

Not applicable directly, because environment design does not shape agent behaviour; it supports responsible AI by making sure higher-risk agents run where reviewers and owners can see and control them.

Evaluation requirements

Not applicable for agent quality; instead, verify each environment's settings against its type after creation and at quarterly review, and confirm routing sends new makers where intended.

Value measures

Track agents in the correct zone, time to provision a team environment, settings drift found at review and the number of shared agents remaining in the default environment, owned by the platform owner and reported at portfolio level.

Scale notes

Starter

Routing for new makers, one team development environment, one test and one production environment, all managed, with a one-page maker guide.

Scale

Environment types applied consistently per business unit, scripted provisioning, quarterly reviews and a remediation programme for the default environment.

Enterprise

Automated provisioning and policy assignment, environment groups per zone, regional environments where data residency requires them, and environment reporting feeding the solution inventory.

Hand-offs

• To copilot-studio:studio-alm for solutions and pipelines between environments.
• To platform-governance:maker-governance for who may build in each zone.
• To platform-governance:ai-licensing-and-capacity for capacity and licence questions.
• To copilot-studio:studio-agent-lifecycle for agents found without owners during inventory.

Reviewer gates

From risk tier 2, design-authority checks that the agent's production environment matches its zone and type, and security-privacy checks data policy and exposure settings. A tier 2 or higher agent running in a personal or default environment is a blocking finding.

Failure modes

• Routing is not configured, so new makers keep building shared agents in the default environment.
• Every team gets a bespoke environment and settings drift until no two behave the same.
• Production environments allow direct making, and untested changes reach users.
• Environments are so restricted that makers move to unmanaged tools.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Let production-bound or widely shared agents be built in the default environment.
• Allow direct making in production environments.
• Create a new environment where an existing type already meets the need.
• State licensing or capacity conclusions; route them to the licensing guide or a licensing partner.