Catalogue › Copilot Studio › studio-alm

Studio ALM

Sets application lifecycle management for Copilot Studio agents - solutions and publishers, environment variables and connection references, source control, pipelines between development, test and production, managed versus unmanaged imports, versioning, change control and rollback. Use when an agent must move beyond one environment, when changes are made directly in production, or when several makers work on the same agent.

Department

Copilot Studio

Lifecycle

Mobilise, Deliver, Launch, Improve

Maturity

builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

copilot-studio, power-platform, github, azure

Editions

starter, scale, enterprise

Reviewers

design-authority

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

An agent that only exists in the environment where it was built cannot be tested safely, changed safely or recovered when something goes wrong. This skill sets the application lifecycle for Copilot Studio agents: how they are packaged in solutions, how they move from development through test to production, how configuration differs per environment, how changes are versioned and approved, and how a bad release is rolled back. ALM usually goes wrong when it is added after the pilot succeeds, when agents and their flows sit in different solutions or none, and when urgent fixes are made directly in production and then overwritten by the next import.

When to use

• An agent is about to move beyond the environment it was built in.
• Changes are being made directly in production, or nobody can say which version is live.
• Several makers work on the same agent, or an agent shares flows and connectors with others.
• A release needs a rollback route, or a reviewer asks for evidence of change control.

When not to use

• Deciding which environments exist and how makers are routed to them - use copilot-studio:studio-environments.
• CI/CD for pro-code AI solutions, prompts and models - use ai-engineering:ai-ci-cd.
• Publishing the released agent to its channels - use copilot-studio:studio-deployment.
• Assessing the impact of a change to a live agent as a formal review - use design-authority:ai-change-impact-review.

Questions to ask first

1. Which environments will this agent pass through, and who owns each?
2. What belongs with the agent - flows, connectors, tables, environment variables, child agents - and what is shared with other solutions?
3. What differs between environments: endpoints, connections, knowledge locations, sharing, authentication settings?
4. Who approves a release to production, and what evidence must accompany it?
5. If a release goes wrong, how quickly must the previous version be restored, and how?

Required inputs

• The environment catalogue and zone rules from copilot-studio:studio-environments.
• The solution design, including tools, flows, connectors and Dataverse dependencies.
• The organisation's release policy by risk tier, from platform-governance:ai-release-policy.
• The source control and pipeline tools the organisation has approved.

If no release policy exists, record the approver and evidence agreed with the business owner as an interim rule, and flag the gap to the platform owner.

Decision framework

Practitioner approach

Put the agent in a solution on day one. Create a solution with the organisation's publisher in the team development environment before building, and add the agent, its flows, custom connectors, tables and environment variables as they are created. Building outside a solution and adding things later is the main source of missing components at import.

Separate what changes per environment. Use environment variables for anything that differs - endpoints, site URLs, queue names, feature flags - and connection references for every connection. Write down the values for each environment in the alm-and-environment-plan. Knowledge sources pointing at development content, and connections created by the maker, are the commonest reasons an imported agent misbehaves.

Decide on shared components early. When several agents use the same flows or custom connectors, place them in a shared solution with its own owner and release cadence, and record which agent solutions depend on it. Without this, two teams import different versions of the same flow and break each other.

Move changes through pipelines, not by hand. Use the platform's pipelines to promote from development to test to production, importing managed solutions into test and production. As the number of makers or the risk tier grows, add source control: export the solution at each release, commit it, review differences and keep the history. Pro-code style pipelines with automated checks suit tier 3 and above or large teams.

Make production read-only for makers. Urgent fixes go through development and the pipeline, quickly if need be, so the next import does not silently undo them. If an emergency change is ever made in production, record it and replay it in development the same day.

Version and record every release: version number, changes, regression results, approver and date. Keep the previous managed solution so rollback is a re-import, and rehearse rollback for higher-tier agents. Remember that some parts of an agent's state - knowledge indexing, channel settings, connections - may need attention after import; include post-import checks in the release steps.

Finally, put the plan on the alm-and-environment-plan template and review it when the agent's design changes.

Outputs

• An ALM plan on the alm-and-environment-plan template: solutions, publisher, environment variables and connection references per environment, pipelines, source control, approvals and rollback.
• A release record per version: changes, regression evidence, approver, date and post-import checks.
• A shared component register where agents share flows or connectors.

Microsoft platform considerations

Solution support for Copilot Studio components, platform pipelines, source control integration and post-import behaviour for knowledge and channels are evolving. Check ms-copilot-studio-guidance for what is currently supported in solutions and pipelines, and ms-managed-environments for pipeline and environment controls. Use ms-coe-starter-kit to find agents and flows outside solutions.

Adoption considerations

Makers resist ALM that feels like bureaucracy. Provide a template solution, a short guide and pipelines that take minutes, and show makers that ALM is what lets their agent reach a wider audience.

Knowledge considerations

Knowledge connections may point to different locations per environment, and uploaded files travel with the solution. Record knowledge locations per environment and check knowledge after each import.

Security and privacy considerations

Pipelines and service accounts used for deployment need least privilege and owners. Production is read-only for makers. Secrets are never stored in solutions or repositories; use managed stores and connection references.

Responsible AI considerations

Not applicable directly, because ALM moves agents rather than shaping behaviour; it supports responsible AI by ensuring that the version reviewers approved is the version users receive.

Evaluation requirements

Each release carries regression evidence from copilot-studio:studio-testing-and-evaluation, run in test against the version being promoted. A release without regression evidence does not proceed beyond test.

Value measures

Track lead time from change to production, failed imports, rollbacks and direct production changes, owned by the Copilot Studio Architect and reported at agent and portfolio level.

Scale notes

Starter

One solution per agent, environment variables and connection references, platform pipelines from development to test to production, and the previous version kept for rollback.

Scale

Shared component solutions, source control for every release, a standard release record and pipelines with approvals set by risk tier.

Enterprise

Source-controlled pipelines with automated checks and regression runs, separation of duties between makers and approvers, and release reporting across the portfolio.

Hand-offs

• To copilot-studio:studio-deployment once a release reaches production.
• To copilot-studio:studio-testing-and-evaluation for regression evidence per release.
• To design-authority:ai-change-impact-review for significant changes to live agents.
• To copilot-studio:studio-environments where a new environment is needed.

Reviewer gates

From risk tier 2, design-authority reviews the ALM plan for packaging, configuration and rollback, and checks that production imports are managed and approved. Direct making in production for a tier 2 or higher agent is a blocking finding.

Failure modes

• The agent is built outside a solution and components are missing at import.
• Hard-coded endpoints make the production agent call development systems.
• An emergency fix made in production is overwritten by the next import.
• Two agents import different versions of a shared flow and break each other.

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

• Build a production-bound agent outside a solution.
• Make changes directly in production without replaying them through development.
• Store secrets in solutions, environment variable values or repositories.
• Promote a release to production without regression evidence and a recorded approver.