Study guide
12.2 ALM for Copilot Studio Agents, Connectors & Solution Packaging
Microsoft Certified: Agentic AI Business Solutions Architect Expert AB-100
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Requirements Analysis & Grounding Data
1.1 Assessing Agents for Task Automation, Analytics & Decision-Making 1.2 Grounding Data Evaluation: Accuracy, Relevance, Timeliness, Cleanliness & Availability 1.3 Structuring Enterprise Business Data for AI System Interoperability
2 Chapter 2: AI Strategy, Cloud Adoption Framework & CoE
2.1 Cloud Adoption Framework (CAF) for Azure AI Strategy & Roadmap 2.2 Multi-Agent Architecture: Microsoft 365 Copilot, Copilot Studio & Foundry 2.3 Microsoft AI Center of Excellence (CoE) & Solution Governance 2.4 Developing Use Cases for Prebuilt Agents & the Microsoft Agent Catalog 2.5 Solution Rules & Constraints for Copilot Studio, Microsoft Foundry & Foundry Tools
3 Chapter 3: Model Selection, Prompt Engineering & Dynamics AI
3.1 Model Selection Strategy, Custom Models & Small Language Models (SLMs) 3.2 Enterprise Prompt Engineering Guidelines & Prompt Libraries 3.3 Cross-App AI Strategy for Multi-App Dynamics 365 Solutions
4 Chapter 4: ROI, TCO, Build vs Buy & Model Routing
4.1 ROI Criteria & Total Cost of Ownership (TCO) for AI Solutions 4.2 Comprehensive Financial ROI Analysis for Business Processes 4.3 Build vs Buy vs Extend Architectural Decision Framework 4.4 Dynamic Model Router Architecture & Cost-Performance Optimization
5 Chapter 5: Dynamics 365 AI & Contact Center Design
5.1 Business Terms & Copilot Customization in Customer Experience and Service 5.2 Connectors & Data Flow Design for Copilot in Dynamics 365 Sales 5.3 Agent Integration with Dynamics 365 Contact Center Channels
6 Chapter 6: Agent Archetypes & Copilot Studio Core
6.1 Designing Task Agents, Autonomous Agents & Prompt-and-Response Agents 6.2 Copilot Studio Topic Design, Trigger Phrases & Graceful Fallbacks 6.3 Orchestration Selection: Standard NLP vs CLU vs Generative AI Orchestration
7 Chapter 7: Copilot Studio Advanced Actions & Power Platform
7.1 Designing Agent Flows & Prompt Actions in Copilot Studio 7.2 Power Apps Canvas App Integration, Generative Pages & Agent Feeds 7.3 Power Platform Well-Architected Framework for AI Workloads 7.4 Proposing Microsoft Power Platform AI Features & the AI Hub
8 Chapter 8: Agent Extensibility, MCP & Computer Use
8.1 Microsoft Foundry Custom Models & Foundry Tools Selection 8.2 Agent Extensibility via Model Context Protocol (MCP) in Copilot Studio 8.3 Computer Use Automation & Web UI Interactions in Copilot Studio
9 Chapter 9: Advanced Behaviors & Prebuilt App Orchestration
9.1 Agent Behaviors: Multi-Step Reasoning, Voice Mode & M365 Agent Optimization 9.2 Orchestrating Prebuilt AI in Dynamics 365 F&O and M365 Copilot for Sales/Service 9.3 Orchestrating Prebuilt Copilot AI Features in Dynamics 365 Customer Experience & Service 9.4 Proposing Microsoft 365 Agents for Business Scenarios 9.5 Adding Knowledge Sources to In-App Help & Guidance in Dynamics 365 Finance & Supply Chain
10 Chapter 10: Telemetry, Monitoring & Agent Tuning
10.1 Monitoring Architectures: Azure Monitor, Application Insights & Studio Analytics 10.2 Telemetry Data Interpretation, Performance Metrics & Latency Tuning 10.3 User Feedback Analysis, Backlog Prioritization & Continuous Improvement
11 Chapter 11: Testing Strategy & Model Validation
11.1 Agent Testing Frameworks, Quality Metrics & Groundedness Benchmarks 11.2 Custom AI Model Validation, Safety Criteria & Regression Testing 11.3 Copilot-Assisted Test Case Generation & Cross-Dynamics End-to-End Testing 11.4 Validating Effective Copilot Prompt Practices
12 Chapter 12: ALM for Grounding Data & Copilot Studio Agents
12.1 ALM for Grounding Data, Vector Indexes & Knowledge Synchronization 12.2 ALM for Copilot Studio Agents, Connectors & Solution Packaging 12.3 Environment Strategy & Automated Deployment Pipelines for Studio Agents
13 Chapter 13: ALM for Foundry Agents & Dynamics 365 AI
13.1 ALM for Microsoft Foundry Agents Service & Model Registries 13.2 ALM for Custom AI Models, Fine-Tuning Artifacts & Deployment Slots 13.3 ALM for Dynamics 365 AI in Finance, Supply Chain & Customer Engagement
14 Chapter 14: Agent Identity, Security & Access Controls
14.1 Agent Identity Architecture, Microsoft Entra ID & Authentication Flows 14.2 Access Controls, Role-Based Security & Permissions on Grounding Data 14.3 Secure Data Processing & Grounding Data Isolation
15 Chapter 15: Model Security & Threat Mitigation
15.1 Model Security Architecture & Defense Against Vulnerabilities 15.2 Mitigating Prompt Manipulation, Jailbreaks & Indirect Prompt Injections 15.3 Azure AI Content Safety, Prompt Shields & Guardrails
16 Chapter 16: Responsible AI, Governance, Residency & Audit
16.1 Microsoft Responsible AI Standard: Principles, Assessment & Implementation 16.2 Data Residency, Sovereign Boundaries & Cross-Border Compliance 16.3 Comprehensive Audit Trails, Model Decision Logging & Microsoft Purview 16.4 Designing Governance for Agents: Environment Strategy, Data Policies & Agent Inventory
12.2 ALM for Copilot Studio Agents, Connectors & Solution Packaging
Key Takeaways Explain This Topic AI
Microsoft Copilot Studio agents, topics, entities, and actions are stored in Dataverse tables and packaged using Microsoft Power Platform Solutions; enterprise ALM mandates that solutions remain unmanaged strictly in Development and are exported and deployed as managed solutions into Test, UAT, and Production.
A comprehensive Copilot Studio solution package includes the core bot definition ('bot' and 'botcomponent' records), conversational topics, custom entities, Power Automate agent flows, Connection References, Environment Variables, and Custom Connectors.
Deploying updates via Solution Upgrades (as opposed to standard Solution Updates) is mandatory when removing obsolete topics or components, as an Upgrade automatically purges deleted components from the target managed environment upon applying the upgrade.
Unmanaged customizations introduced directly into downstream environments (Test or Production) create an unmanaged layer on top of the managed solution stack, effectively 'masking' future managed releases and causing critical deployment failures.
Connection References and Environment Variables decouple runtime agent conversational logic from environment-specific endpoints (such as Azure OpenAI endpoints, AI Search index names, and API URLs), enabling seamless deployment parameterization via deploymentSettings.json.
Last updated: September 2026
ALM for Copilot Studio Agents, Connectors & Solution Packaging
Quick Answer: Microsoft Copilot Studio agents are packaged and transported across enterprise environments using Microsoft Power Platform Solutions. Development occurs exclusively in unmanaged solutions, which are committed to Git as unpacked declarative XML/YAML and built into immutable managed solutions for deployment to Test, UAT, and Production. To prevent environmental coupling, architects must abstract all external endpoints and credentials into Environment Variables and Connection References , bound automatically at deploy-time via deploymentSettings.json .
Deploying conversational and agentic AI at enterprise scale requires rigorous ALM controls. In Microsoft Copilot Studio, agents are not standalone code files; they are composite, data-driven entities whose dialog trees, trigger phrases, generative knowledge sources, and action bindings reside within Microsoft Dataverse. Transporting these assets safely across environments demands a deep understanding of Power Platform Solution architecture, component dependency trees, and solution layering mechanics.
1. Power Platform Solution Architecture for Copilot Studio
In Microsoft Copilot Studio, every agent asset is modeled as a record in Dataverse. Understanding the underlying schema is vital for diagnosing packaging errors, resolving missing dependencies, and structuring source control repositories. +-----------------------------------------------------------------------------+
- | COPILOT STUDIO SOLUTION PACKAGE (MANAGED) |
- +-----------------------------------------------------------------------------+
- | |
- | +---------------------------+ +-----------------------------------+ |
- | | Core Agent Definition | | Conversational Assets | |
- | | - Schema: 'bot' | <---> | - Schema: 'botcomponent' | |
- | | - Agent metadata | | - Topics (Trigger/Dialog YAML) | |
- | | - Default language | | - Entities (Closed / Regex) | |
- | +---------------------------+ | - Modern Agent Actions | |
- | +-----------------------------------+ |
- | | | |
- | v v |
- | +---------------------------+ +-----------------------------------+ |
- | | Extensibility Assets | | Configuration & Secrets | |
- | | - Agent Cloud Flows | <---> | - Environment Variables | |
- | | - Custom Connectors | | - Connection References | |
- | | - AI Builder Prompts | | - Azure Key Vault References | |
- | +---------------------------+ +-----------------------------------+ |
- +-----------------------------------------------------------------------------+
- Core Solution Components for Copilot Studio
Bot Record ( bot ): The root container entity representing the agent. It stores the agent display name, icon, schema version, default language, and runtime settings.
Bot Components ( botcomponent ): Granular sub-components that define the agent's intelligence. Each record has a componenttype attribute:
Topic (Type 9): Conversational dialog paths, trigger phrases, condition nodes, and response templates defined in declarative YAML.
Bot Variable (Type 11): Global and session variables shared across topics.
Dialog (Type 0): System dialogs including Greeting, Fallback, End of Conversation, and Escalate.
Knowledge Source (Type 15): Grounding configurations pointing to SharePoint, Dataverse, or Azure AI Search.
Bot Subtype / Trigger (Type 12): Event listeners that trigger agent actions based on external signals.
Agent Cloud Flows (Power Automate): Specialized automated flows invoked synchronously or asynchronously by agent topics to query backend enterprise databases or execute transactions.
Connection References ( connectionreference ): Abstractions that map flow and agent actions to physical connectors (e.g., SharePoint, Dataverse, SAP, Office 365 Outlook) without embedding user credentials.
Environment Variables ( environmentvariabledefinition ): Decoupled configuration values (e.g., Azure OpenAI model deployment names, API base URLs, tenant IDs) stored separately from the code.
Custom Connectors ( connectors ): OpenAPI (Swagger) specifications defining custom REST API integrations utilized by the agent.
Managed vs. Unmanaged Solutions: The Cardinal Rules
- Attribute Unmanaged Solutions Managed Solutions
- Target Environment Development Sandboxes ONLY Integration, Test, UAT, and Production
Mutability Fully editable. Components can be added, modified, or deleted directly by makers. Immutable / Read-Only. Direct editing of topics or flows is locked to prevent unauthorized drift.
De-installation Impact Deleting the solution container deletes only the container ; all custom components remain behind in the default solution. Deleting the managed solution removes the container and all associated components and data cleanly.
Export Capability Can be exported as either Unmanaged (for backup/branching) or Managed (for deployment). Cannot be exported. Once imported as managed, it remains managed permanently.
Source of Truth Temporary working canvas. The authoritative source of truth is the Git repository. Production executable release artifact generated by the automated CI/CD pipeline.
Caution
Critical Architecture Rule: Never import an unmanaged solution into a Test or Production environment. Once unmanaged components enter an environment, they contaminate the Default Solution layer, creating permanent configuration drift that prevents clean upgrades and breaks automated ALM.
2. Solution Layering, Upgrades & Dependency Management
Power Platform calculates the active behavior of an agent by evaluating its Solution Layer Stack from bottom to top. Understanding this evaluation hierarchy is essential for diagnosing why updates fail to appear in production. +-------------------------------------------------------------------------+
- | THE SOLUTION LAYER STACK |
- +-------------------------------------------------------------------------+
- | [ Top Layer ] | Active / Unmanaged Customizations Layer |
- | | (Formed by manual edits in Prod - BLOCKS UPDATES!) |
- |-----------------+-------------------------------------------------------|
- | [ Middle Layer ]| Managed Solution Patch / Upgrade (v1.1.0) |
- | | (Latest CI/CD automated release) |
- |-----------------+-------------------------------------------------------|
- | [ Base Layer ] | Managed Base Solution (v1.0.0) |
- | | (Initial release package) |
- |-----------------+-------------------------------------------------------|
- | [ Bottom Layer ]| System Solution (Dataverse Core Metadata) |
- +-------------------------------------------------------------------------+
Rule of Precedence: The HIGHEST layer wins at runtime.
The Unmanaged Customization "Ghosting" Anti-Pattern
If an administrator or maker opens Copilot Studio directly in the Production environment and modifies a single node in a Topic (e.g., updating a support telephone number), Dataverse automatically writes an Unmanaged Customization Layer at the very top of the stack for that specific component.
When the engineering team subsequently deploys a new managed release (e.g., v1.2.0 ) via the automated pipeline, the pipeline reports success, but users in production continue seeing the old telephone number . Because the unmanaged layer sits above all managed layers, it permanently masks any managed updates beneath it.
Remediation: Architects must enforce environment permissions to prevent direct editing in production. If an unmanaged layer is inadvertently created, an administrator must navigate to the component's Solution Layers view in the maker portal or execute a CLI command to explicitly Remove Unmanaged Customizations .
Solution Import Operations: Update vs. Upgrade vs. Patch
When deploying a new version of an agent solution, architects must select the correct deployment operation: Scenario: Developer deletes Topic 'Legacy_Returns_Topic' in Development.
Deploying via SOLUTION UPDATE:
- Target environment updates modified topics.
- 'Legacy_Returns_Topic' REMAINS in Production as an orphaned active topic!
Deploying via SOLUTION UPGRADE:
- Deploys holding solution 'SolutionName_Upgrade'.
- Replaces all modified topics.
- Automatically DELETES 'Legacy_Returns_Topic' from Production.
- Result: Perfect parity with Development.
Solution Update: Imports the new package and applies changes to existing components. However, it does not delete any components that were removed in the development environment. If an architect deletes five obsolete topics in Dev, those topics will remain active in Production after a Solution Update, confusing users and degrading intent recognition.
Solution Upgrade (Mandatory for Major/Minor Releases): Deploys the package as a temporary holding solution ( Solution_Upgrade ), validates dependencies, and then applies the upgrade. During the "Apply Solution Upgrade" phase, Dataverse purges all components that existed in the prior version but are absent in the new package . This ensures that deleted topics, retired flows, and obsolete variables are cleanly removed from production.
Solution Patch: A lightweight, delta-only solution containing strictly the modified or added components, bound directly to a parent base solution. Patches are ideal for hotfixing critical conversational bugs in production without re-exporting the entire multi-megabyte solution corpus. Patches are subsequently consolidated into a new base solution via the Clone Solution (rollup) operation.
Resolving Missing Dependency Errors ( SolutionImportFailed )
During solution import into downstream environments, the most common deployment error is MissingDependencyException . This occurs when a component inside the solution references an asset that does not exist in the target environment or inside the solution package. Error Details:
Solution "CustomerServiceAgent" import failed: Missing dependencies.
- Dependent Component: Topic "Process_Refund" (botcomponent)
- Required Dependency: Cloud Flow "Execute_SAP_Refund" (workflow)
- Required Dependency: Connection Reference "sap_erp_conn_ref" (connectionreference)
Architectural Prevention Checklist:
Always Include Sub-Components: When adding an Agent to a solution, ensure that all dependent Topics, Entities, and Agent Actions are explicitly added.
Avoid Default Environment Connections: Ensure that every Power Automate flow invoked by an agent utilizes Connection References rather than direct, embedded maker credentials.
Run Solution Checker in CI: Enforce automated execution of the Power Platform Solution Checker in the pull request pipeline. The checker inspects declarative XML and warns of missing dependencies prior to package generation.
3. Decoupling Agent Configurations via Environment Variables & Connection References
Hardcoding API endpoints, Azure OpenAI resource names, or search indexes inside agent topics or flow definitions is an architectural anti-pattern that breaks multi-environment pipelines. All environment-specific parameters must be decoupled. [ Copilot Studio Agent / Agent Flow ]
- |
- | Reads at Runtime
- v
- +---------------------------+ +---------------------------+
- | Connection References | | Environment Variables |
- +---------------------------+ +---------------------------+
- | |
- | Dynamically Bound at Deploy-Time |
- v v
- +---------------------------+ +---------------------------+
- | deploymentSettings.json | | deploymentSettings.json |
- | Dev: Mock Connector | | Dev: 'aoai-dev-eastus' |
- | UAT: Staging Service Prin| | UAT: 'aoai-uat-eastus' |
- | Prod: Managed Identity | | Prod: 'aoai-prod-eastus' |
- +---------------------------+ +---------------------------+
- Connection References: Decoupled Connectivity
A Connection Reference is a solution-aware component that acts as a placeholder or pointer for an underlying physical connection. Instead of an agent flow binding directly to JaneDoe@enterprise.com's SharePoint Connection , it binds to cr_SharePoint_Grounding_ConnRef .
In Development: The connection reference binds to the developer's personal or shared development connection.
In Test and Production: During automated pipeline deployment, the connection reference is bound to an enterprise Service Principal (Entra ID Application Registration) or dedicated service account without requiring manual maker intervention.
Environment Variables: Parameterizing Agent Logic
Environment Variables store data keys and configuration parameters that vary across environments. Copilot Studio topics and agent flows read these values dynamically at runtime.
Variable Schema Name Data Type Purpose Dev Value Prod Value
aoai_endpoint_url String Base URL for Azure OpenAI https://aoai-dev.openai.azure.com https://aoai-prod.openai.azure.com
- aoai_model_deployment String Target LLM deployment name gpt-4o-mini-sandbox gpt-4o-ptu-enterprise
- search_index_alias String Azure AI Search Index Alias kb-dev-synthetic enterprise-knowledge-active
search_api_key_secret Secret (Key Vault) API Key for Search Service @Microsoft.KeyVault(...) @Microsoft.KeyVault(...)
- max_agent_turns Number Reasoning loop cutoff threshold 3 5
- Automating Deployment via deploymentSettings.json
When deploying managed solutions via the Power Platform CLI ( pac ) or Azure DevOps / GitHub Actions, configuration values and connection bindings are supplied via a single, environment-specific deployment configuration file: {
- "EnvironmentVariables": [
- {
- "SchemaName": "aoai_endpoint_url",
- "Value": "https://aoai-prod-eastus.openai.azure.com/"
- },
- {
- "SchemaName": "aoai_model_deployment",
- "Value": "gpt-4o-enterprise-v1"
- },
- {
- "SchemaName": "search_index_alias",
- "Value": "enterprise-knowledge-active"
- }
- ],
- "ConnectionReferences": [
- {
- "LogicalName": "cr_Dataverse_Grounding",
- "ConnectionId": "7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d",
- "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
- },
- {
- "LogicalName": "cr_SAP_ERP_Connector",
- "ConnectionId": "b1c2d3e4-5f6a-7b8c-9d0e-1f2a3b4c5d6e",
- "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_customconnector"
- }
- ]
- }
During the pipeline deployment stage, the CLI command automatically injects these values: pac solution import \
- -path ./build/CustomerServiceAgent_managed.zip \
- -activate-plugins true \
- -settings-file ./config/prod-deploymentSettings.json
This approach guarantees that the managed solution artifact is built once (immutable) and promoted across Test, UAT, and Production without modifying a single line of internal agent logic.