Study guide
15.1 Create a Solution
Microsoft Certified: AI Agent Builder Associate AB-620
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Candidate Profile & Prerequisites 1.3 Skills Map & Study Strategy
2 Plan Integration, Identity & Channels
2.1 Plan Integration with Enterprise Systems 2.2 Plan Identity Strategy 2.3 Plan Channels and Deployment
3 Responsible AI, Security & Reuse
3.1 Plan Responsible AI Strategy 3.2 Security and Governance Considerations 3.3 Plan Reusable Agent Components 3.4 Design Agents for Internal or External Audiences
4 Agent Flows Fundamentals
4.1 Create an Agent Flow 4.2 Human-in-the-Loop Agent Flows 4.3 Configure Actions and Connectors in Flows
5 Agent Flow Monitoring & Resilience
5.1 Monitor Agent Flows 5.2 Input and Output Parameters 5.3 Error Handling in Agent Flows
6 Topics Configuration Core
6.1 Add Agent Flows to a Topic 6.2 Configure Agent Response Formatting 6.3 Add Tools to a Topic
7 Advanced Topic Responses
7.1 Custom Prompts for Advanced Responses 7.2 Custom Knowledge Sources for Advanced Responses 7.3 API and Send HTTP Request Responses
8 Generative Answers, Cards & Variables
8.1 Configure the Generative Answers Node 8.2 Configure Adaptive Cards 8.3 Manage Variables
9 Enterprise Knowledge Sources
9.1 Connect to Copilot Connectors 9.2 Connect to Power Platform Connectors 9.3 Connect to Azure AI Search
10 Add Tools to Agents
10.1 Configure and Monitor Computer Use 10.2 Configure MCP Tools 10.3 Tools via Existing Custom Connectors 10.4 Add REST APIs to an Agent
11 Multi-Agent Collaboration
11.1 Design Multi-Agent Solutions 11.2 Integrate a Foundry Agent 11.3 Integrate an Existing Copilot Studio Agent
12 Fabric Data Agents & A2A
12.1 Integrate a Fabric Data Agent 12.2 Multi-Agent Solutions with A2A Protocol
13 Integrate Agents with Azure
13.1 Generative Answers with Azure AI Search & Foundry 13.2 Foundry Model Catalog for Custom Prompts 13.3 Monitor Agents with Application Insights
14 Evaluate Agent Performance
14.1 Create a Test Set 14.2 Choose an Evaluation Method 14.3 Review Test Results
15 Application Lifecycle Management
15.1 Create a Solution 15.2 Add Existing Agents to a Solution 15.3 Create and Use Environment Variables 15.4 Power Platform Pipelines for Agents
15.1 Create a Solution
Key Takeaways Explain This Topic AI
Every Copilot Studio agent lives in a Power Platform solution; custom solutions—not the default solution—are the ALM carrier for multi-environment promotion.
Unmanaged solutions are for development and editing; managed solutions are the deployable artifact for test and production and cannot be exported as managed.
Create a custom publisher with a meaningful prefix before you create solution components so schema names stay consistent and collision-safe.
Set a preferred solution so new agents and components land in your custom solution by default instead of the Default solution.
Solution layering places unmanaged customizations above managed layers; production should receive managed packages so you can uninstall cleanly.
Last updated: August 2026
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 :
- Environment role Typical purpose for agents
- Development Author topics, tools, knowledge; work in unmanaged solutions
- Test / UAT Import managed solutions; run evaluation sets; validate connections
- Production Import managed solutions only; limited maker rights; governed channels
- Pipelines host (optional) Central place that stores pipeline definitions and deployment history
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)
- Aspect Unmanaged Managed
- Primary use Development and active editing Test, UAT, production deployment
- Editable components Yes, directly Not edited in place; customize via unmanaged layer if allowed
- Export Can export as unmanaged or managed Cannot export a managed solution
Delete solution Removes the container; customizations often remain in default layer Uninstalls components included with that managed package
ALM role Source of truth for makers / source control Build artifact promoted downstream
Rules that trap candidates:
You cannot import a managed solution into the same environment that still holds the originating unmanaged solution. Test managed packages in a separate environment.
Export managed from the unmanaged source in development—do not try to “turn production into unmanaged” as the normal path.
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:
Create New solution (name, publisher, version).
Choose Set preferred solution so subsequent agents and components default into that custom solution.
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:
Managed layers — installed managed solutions (often one per product/team package).
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.
- Layering concept Why agents care
- Managed under unmanaged Production hotfixes can block clean managed upgrades
- Multiple managed solutions Modular base + extension solutions with dependencies
- Layer inspection Diagnose “why didn’t my import change the topic?”
- How to create a custom solution for agents (workflow)
Confirm you are in the development environment (environment switcher).
Open Copilot Studio Solutions (side bar … → Solutions , or via Export agent / Import agent ).
Select New solution → enter display name, select or create publisher , set initial version (for example 1.0.0.0).
Optionally Set preferred solution to the new solution.
Create or move agents into that solution (section 15.2 covers adding existing agents).
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.