6.1.1. ALM for Copilot Studio Agents and Connectors
💡 First Principle: Copilot Studio agents are governed by the Power Platform solution framework. Every agent, connector, and action must be packaged in a solution, exported, and promoted through environments (dev → test → production). Anything left outside a custom solution cannot travel between environments at all.
Managed and unmanaged solutions — get this exactly right:
"Managed" is a precise Power Platform term, not a loose synonym for "governed." The distinction decides what you can edit, what you can export, and what you destroy when you uninstall.
| Unmanaged | Managed | |
|---|---|---|
| Where it lives | Development environments only | Every environment that is not the development environment for that solution — test, UAT, SIT, production |
| What it is for | Developed — the editable working copy | Deployed — a build artifact |
| Editing components | Directly editable | Not directly editable. To change one you add it to an unmanaged solution, which creates a dependency that blocks uninstalling the managed solution until removed |
| Export | Can be exported as unmanaged or as managed | Cannot be exported at all |
| Source control | Export unmanaged and check that in — this is your source of truth | Never your source; it is an output |
| Deleting it | Only the solution container goes; the customizations survive and fall back to the default solution | Uninstalls every customization — and data in its custom tables and columns is lost |
⚠️ Exam Trap: "Export the managed solution from Dev" is not a thing that can happen. You author in an unmanaged solution in Dev and export it as managed for downstream environments. A second constraint follows from the same rule: you cannot import a managed solution into the environment that holds its originating unmanaged solution, so testing a managed solution genuinely requires a separate environment.
Update, upgrade, or patch — only one of them removes anything:
| Action | What it does | Removes components no longer present? |
|---|---|---|
| Update | Deploys changes to the parent managed solution | No |
| Patch | Carries only the changes, layered on the parent — a hotfix-shaped change | No |
| Upgrade | Rolls up all patches into a new version; can be applied immediately or staged for pre-completion work | Yes |
⚠️ Common Misconception: Shipping updates keeps an environment tidy. It does not — a team that only ever ships updates and patches accumulates orphaned components indefinitely, because only an upgrade deletes components that are no longer in the solution.
Publisher and prefix: define one publisher and use it consistently. The publisher prefix prevents naming collisions between solutions installed side by side, the publisher of a component owns what other solutions may change about it, and once a component ships in a managed solution its publisher cannot be changed. Change the prefix before you create metadata items, not after.
Copilot Studio's own wrinkles:
- Creating an agent places it in the default solution automatically — and the default solution cannot be exported. To move an agent between environments you must create a custom solution and add the agent to it. This is the single most common "why can't I export my agent?" answer.
- Solution management now lives inside Copilot Studio (… → Solutions): view, export, import, set the preferred solution, and configure pipelines without leaving the product.
- The solution explorer inherits the user's own security-role privileges — opening it in Copilot Studio grants nothing extra.
- When someone has edited a managed agent directly in a downstream environment, that edit sits in an unmanaged layer above it. Advanced → See solution layers → Remove unmanaged layer is how you put production back under source control.
What Must Be Versioned:
| Artifact | Where It Lives | ALM Approach |
|---|---|---|
| Agent definition | Copilot Studio (in solution) | Solution export/import, version controlled |
| Topics | Part of agent definition | Included in solution package |
| Actions and connectors | Power Platform connectors | Versioned with solution; connection references for environment-specific credentials |
| Knowledge sources | SharePoint, Dataverse, external | Managed separately; sync configuration per environment |
| Environment variables | Solution-level configuration | Environment-specific values set at deployment |
Environment Promotion Pattern:
Connection References:
Connection references are the mechanism that separates what a connector does (its definition) from how it connects (its credentials). In dev, the connector authenticates with dev service accounts. In production, it uses production credentials. Without connection references, promoting a solution overwrites production credentials with dev credentials — a common ALM failure.
Power Platform Pipelines — the in-product deployment path:
Pipelines bring CI/CD into the product itself: an admin configures the stages once, and makers then deploy from inside their own development environment in a few clicks. What matters for the exam is the constraints, because they are what scenarios turn on.
| Property | Behaviour |
|---|---|
| What is deployed | Solutions, plus connections, connection references, and environment variables. Never Dataverse data |
| Solution type | Managed only. Unmanaged solutions cannot be deployed — they are auto-exported and stored in the pipelines host for source control |
| Where you run it | From an unmanaged solution in a development environment. Not from the default solution, not from a managed solution, not in a target environment |
| Stage integrity | The artifact is exported once, on submission, and the same artifact passes through stages in order — customization cannot bypass a QA stage, and tampering is prevented |
| Environments | The host should be a production environment but need not be managed; all other environments in a pipeline must be Managed Environments. From February 2026 Microsoft began enabling this automatically for pipeline targets |
| Import behaviour | Defaults to Upgrade without Overwrite customizations; update-versus-upgrade is not currently selectable |
| Approvals | Available through delegated deployments, optionally running as a service principal |
| Hard limits | No cross-tenant deployment; cross-geo requires the Cross-Geo Solution Deployments setting; one solution per deployment; a single development environment per solution |
So where do Azure DevOps, GitHub Actions, and the Build Tools fit? Use pipelines for core deployment and reach for the CI/CD tooling where pipelines stop: cross-tenant promotion, complex branching, multi-developer isolated environments, or gates that must live alongside application code. Microsoft's own guidance is to extend pipelines rather than replace them — the ALM Accelerator remains the option for the most advanced scenarios. The exam's tell is the constraint in the stem: a scenario that says "deploy to a customer's separate tenant" rules pipelines out on its own.
Action Versioning:
When an agent uses custom actions (Power Automate flows, custom connectors, API plugins), those actions must be versioned alongside the agent. An agent upgrade that expects a new action parameter but runs against the old action version will fail silently or produce incorrect results.
⚠️ Common Misconception: ALM for Copilot Studio agents is handled automatically by the platform. In reality, solutions must be explicitly packaged, exported, versioned, and promoted across environments using the solution framework and deployment pipelines.
Troubleshooting Scenario: A team promotes a Copilot Studio agent from dev to test. The agent works perfectly in dev but fails in test — all connector-based actions return errors. The solution was exported and imported correctly, and the agent's topics and flows are intact. What happened? Connection references. The solution package carries connector definitions but not credentials. In the test environment, connection references must be mapped to test-environment credentials. This is the single most common ALM failure for Copilot Studio agents, and the exam tests it directly.
The broader principle: AI solution ALM requires managing both the solution artifact (topics, flows, prompts) and its runtime dependencies (connections, secrets, environment variables) as separate but coordinated pipelines. Forgetting either one guarantees a broken promotion.
Reflection Question: A Copilot Studio agent in production uses three custom connectors and a SharePoint knowledge source. The dev team adds a new topic and modifies one connector. Walk through the ALM process to promote this change safely to production.
