15.1 Create a Solution

Why solutions matter for Copilot Studio agents

On AB-620 Domain 3, create a solution is not optional packaging trivia—it is how enterprise agents move from a maker sandbox to test and production without hand-copying topics. Microsoft Copilot Studio builds every agent inside a Power Platform solution. A solution is the carrier for agent definitions and related Dataverse components: topics, agent flows, connection references, environment variables, knowledge configuration, and other dependent objects you deliberately include.

Without a custom solution, agents accumulate in the platform Default (or Common Data Service Default) solution. That path is fine for personal experiments. It fails enterprise ALM because you cannot cleanly version, export, approve, or pipeline-promote a coherent package. Healthy practice is: create a custom unmanaged solution with your publisher, set it as the preferred solution, author agents inside it, then export as managed for downstream environments.

Environments first, then solutions

Solutions move components, not entire tenants. You still need an environment strategy:

All ALM environments need a Dataverse database. Copilot Studio solution explorer inherits your security roles—you need at least privileges equivalent to System Customizer (or higher) for many export/import tasks. If a maker can edit an agent but cannot create solutions, an administrator must grant the right environment roles.

Managed vs unmanaged (exam core)

Rules that trap candidates:

1. You cannot import a managed solution into the same environment that still holds the originating unmanaged solution. Test managed packages in a separate environment.
2. Export managed from the unmanaged source in development—do not try to “turn production into unmanaged” as the normal path.
3. When a managed solution is uninstalled, its managed components leave; when an unmanaged solution container is deleted, many customizations remain behind in the default solution.

Exam trap: “Edit production by converting managed to unmanaged.” Healthy ALM re-exports from development as a new managed version and upgrades production—not ad-hoc production edits.

Publishers and prefixes

Every solution has a publisher. The publisher owns the components created in that solution and carries a prefix used in schema names to reduce collisions (for example, contoso → contoso_OrderStatusAgent). Best practices:

• Create a custom publisher with a short, stable, organization-meaningful prefix before you create tables, agents, or other metadata you will promote.
• Prefer one primary publisher for related agent solutions so ownership and layering stay predictable. You can move ownership of a component between solutions of the same publisher more easily than across publishers.
• Do not rely on the default publisher for production-grade work; default prefixes make multi-ISV and multi-team environments harder to govern.

Changing a publisher prefix after metadata exists is painful because schema names are sticky. Decide prefix early.

Default solution vs preferred (custom) solution

When an agent is created, it is placed into a solution automatically—often the Default solution unless you set a preferred solution. In Copilot Studio solution explorer you can:

1. Create New solution (name, publisher, version).
2. Choose Set preferred solution so subsequent agents and components default into that custom solution.
3. Open an agent → View solution from overview or settings to confirm packaging.

Default solution risks: components from many makers and projects mix together; export becomes either too large or incomplete; ownership is unclear; pipelines cannot promote a clean unit of change.

Preferred custom solution benefits: new agent work lands in the right package; export/import targets a known version; pipelines deploy a predictable artifact; CoE reviews can map solutions to business owners.

Solution layering in plain language

Dataverse stacks customizations in layers. Simplified model:

1. Managed layers — installed managed solutions (often one per product/team package).
2. Unmanaged layer — active development customizations and emergency fixes made outside managed packages.

Runtime behavior merges layers with unmanaged usually winning where present. That is why a “quick fix” in production creates an unmanaged layer on top of a managed agent. Later upgrades of the managed package may appear not to apply until you remove the unmanaged layer. Copilot Studio exposes See solution layers on an agent so you can inspect and remove unmanaged layers when appropriate.

How to create a custom solution for agents (workflow)

1. Confirm you are in the development environment (environment switcher).
2. Open Copilot Studio Solutions (side bar … → Solutions, or via Export agent / Import agent).
3. Select New solution → enter display name, select or create publisher, set initial version (for example 1.0.0.0).
4. Optionally Set preferred solution to the new solution.
5. Create or move agents into that solution (section 15.2 covers adding existing agents).
6. Export as managed when promoting; keep an unmanaged export (or source control of the unmanaged package) as the editable source of truth.

Versioning follows semantic-style increments. Pipelines and manual import can upgrade or update managed solutions; upgrades can remove components no longer in the package, while patches are smaller change sets layered on a parent.

What a “good” agent solution contains

A production-ready agent solution typically includes:

• The agent component itself
• Required objects discovered after you add topics, flows, tools, and knowledge dependencies
• Environment variables for URLs, site IDs, feature flags, display-name suffixes
• Connection references (not raw secrets in topics)
• Related agent flows, custom connectors (with known import order constraints), and child/component collections when used

Not every runtime property travels with export (for example some channel details, conversation IDs, environment IDs, and topic/node comments). Plan to reconfigure authentication and channels after first import into a new environment and publish before sharing.

Scenario — Contoso HR agent package

Contoso builds an employee benefits agent. The Center of Excellence requires ALM. The team creates publisher ContosoAgents with prefix ctso, solution CTSO HR Benefits Agents version 1.0.0.0, and sets it as preferred. Makers author only in the Dev environment unmanaged solution. They never publish production channels from Dev. When topics stabilize, they export managed 1.0.0.1 to Test, fix connection references, run evaluation, then pipeline-promote the same managed artifact to Production. That story is the AB-620 mental model for “create a solution.”

Common mistakes

• Building for months only in the Default solution, then scrambling to re-home components before go-live.
• Editing managed agents directly in production without a new unmanaged development cycle.
• Using multiple publishers for the same product line, making later merges difficult.
• Forgetting security roles so “export” fails for makers who can chat-test agents.
• Assuming solution export includes every chat transcript or channel secret—it does not; solutions carry definitions and configuration hooks, not operational conversation history.

AB-620 takeaway

Creating a solution means deliberately choosing custom unmanaged packaging with a real publisher, using preferred solution so agents do not fall into Default, understanding managed vs unmanaged roles, and respecting layering so production stays upgradeable. Master this vocabulary before you add agents, environment variables, or pipelines—the later skills all assume a correct solution foundation.