Study guide
2.1 Plan Integration with Enterprise Systems
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
2.1 Plan Integration with Enterprise Systems
Key Takeaways Explain This Topic AI
Choose knowledge for read-only grounding (SharePoint, Dataverse, SAP/ServiceNow articles); choose tools/actions for create-update-delete operations against live systems.
Prefer Power Platform connectors for ServiceNow, SAP, Dataverse, and SharePoint when a prebuilt or custom connector exists; reserve HTTP nodes and REST tools for gaps or pro-code APIs.
Plan multi-agent when domains, owners, or security boundaries differ—use an orchestrator agent with specialized child agents rather than one monolithic agent.
Document each integration with connected system, caller (topic/tool/flow), pattern, volume, and peak rate before build starts.
User-delegated credentials respect source permissions; maker/service credentials broaden access and require stricter governance.
Last updated: August 2026
2.1 Plan Integration with Enterprise Systems
Quick Answer: Ground answers with knowledge (SharePoint, Dataverse, indexed ServiceNow/SAP content). Perform actions with tools and agent flows (create tickets, update records, call LOB APIs). Split domains with multi-agent when ownership, scale, or security boundaries demand it. Prefer Power Platform connectors; use custom connectors, REST, MCP, or computer use only when connectors are insufficient.
AB-620 expects you to plan how a Copilot Studio agent reaches enterprise systems before you wire a single node. Integration is not “add every connector.” It is a deliberate map of user intents to data access patterns, action patterns, and system-of-record boundaries.
Why integration planning is scored first
Agents become useful only when they can ground on trusted enterprise content and act on systems of record. Microsoft’s guidance frames Copilot Studio as a front door: one conversation can read a SharePoint policy, create a ServiceNow incident, and email the requester—without the user hopping apps. That power fails without a plan for:
- What the agent may know (knowledge / RAG)
- What the agent may do (tools, connectors, flows, APIs)
- Who owns each capability (single agent vs multi-agent)
- How identity flows (covered in 2.2)
- Where users meet the agent (covered in 2.3)
Exam scenarios often give a messy requirement list and ask which integration approach fits. Start by classifying each requirement as read/ground , write/act , or orchestrate across specialists .
Knowledge vs tools vs multi-agent
Pattern Primary purpose Typical sources / targets When to choose
Knowledge Generative answers grounded in enterprise content SharePoint sites/lists, uploaded docs, Dataverse, Copilot connectors, ServiceNow/Salesforce/Zendesk KB articles, SAP/Snowflake/Databricks structured data (as supported) User needs explanations, policies, product facts, ticket history narrative—not a guaranteed transaction
Tools (actions) Let generative orchestration invoke operations Prebuilt connectors, custom connectors, REST APIs, MCP tools, computer use User needs create/update/delete, status change, meeting booking, inventory check with a live call
Topics + nodes Deterministic path with Power Fx inputs HTTP request node, connector action in topic, generative answers node Compliance needs fixed sequence, or you must force a specific API call at a known step
Agent flows Multi-step, high-throughput, or human-in-the-loop automation Connector actions, approvals, Key Vault secrets Batch-ish logic, multi-system choreography, approvals, secrets not safe in topic nodes
Multi-agent Specialize and orchestrate Child agents, Foundry agents, Fabric data agents, A2A peers Separate domains (HR vs finance), separate security scopes, or reuse of existing specialist agents
Decision rules you can memorize
Knowledge first when the user asks “what / why / how according to our docs.” Knowledge sources work with generative answers. SharePoint, Dataverse, and enterprise connectors that surface indexed content honor the signed-in user’s permissions —critical for intranet and LOB content.
Tools when the user asks “do / create / change / schedule.” A ServiceNow “create incident” action is a tool, not a knowledge source. Tools need clear natural-language descriptions so generative orchestration knows when to select them, plus defined inputs/outputs.
Multi-agent when a single agent’s instructions, tools, and knowledge become a governance or reliability risk. Example: a corporate “employee help” agent routes payroll questions to a finance agent (Dataverse + SAP tools) and device issues to an IT agent (ServiceNow tools + KB knowledge).
Do not fake transactions with knowledge. Indexing last week’s SAP extract as knowledge does not replace a live inventory check tool.
- Enterprise systems AB-620 loves to name
- Microsoft Dataverse
Dataverse is the Power Platform system of record for many line-of-business apps and Dynamics 365. Use it as:
- Knowledge for structured/unstructured Dataverse content agents can reason over
- Tools/connectors for CRUD on tables the agent must update
A landing zone for synchronized LOB data (for example nightly SAP product catalog sync into Dataverse via flow)
Plan whether the agent works in the same environment as the business data. Cross-environment access complicates ALM and security roles.
SharePoint and Microsoft 365 content
SharePoint is the default enterprise document grounding path (Graph-based search). Plan site URL scope carefully—too broad dilutes answers; too narrow misses policies. Unstructured files and folders (SharePoint, OneDrive) have different limits than classic site URL knowledge. User authentication is required so the agent only returns content the user can open.
ServiceNow
Typical split:
- Knowledge: knowledge base articles, unstructured KB content for generative answers
- Tools / agent flows: create/update incidents, query cases, assignment group updates
Prebuilt ServiceNow connectors cover common operations. Custom connectors wrap org-specific REST extensions. For helpdesk agents, plan both: ground with KB knowledge, act with incident tools.
SAP
SAP integration often mixes:
- Structured knowledge / connectors for product, order, or master data visibility
- Tools or flows for transactional checks that must be real-time
Batch middle layers (flow or pipeline) when conversational latency cannot wait on heavy SAP APIs—sync a slice to Dataverse, then ground or query Dataverse
Microsoft’s SAP AI guidance positions Copilot Studio with the broad connector ecosystem (SAP among ServiceNow, Salesforce, Dataverse, and others). On the exam, prefer connector or documented enterprise knowledge path over inventing custom middleware unless the scenario says no connector exists.
Line-of-business REST APIs
When no connector exists:
- Custom connector (reusable OpenAPI wrapper) — best default for low-code reuse across agents
- HTTP request in a topic — faster to prototype, harder to govern/reuse
- REST API tool on the agent — generative orchestration can call it as a tool
MCP tools — standardized external tool/data exposure when the enterprise standardizes on Model Context Protocol
- Computer use — last resort when only a UI exists (no API)
- Integration pattern catalog
Pattern Strengths Watch-outs
Prebuilt Power Platform connectors Fast, low-code, monitoring paths, Power Fx parameters Large result sets slow conversations; third-party connectors may prompt user credentials
Custom connectors Share once, use in many agents; virtual network scenarios Requires OpenAPI discipline and ALM of the connector
HTTP request node Any REST surface quickly Not reusable org-wide; makers may struggle to support; secrets handling needs care
Agent flows Deterministic multi-step, HITL, Key Vault, concurrency API limits of downstream systems; design explicit error handling back to the agent
- Bot Framework skills Pro-code reuse, private endpoints Azure cost/ops outside Power Platform ALM
- MCP Scalable standard tool/knowledge exposure Org must operate MCP servers securely
- Computer use Automate apps without APIs Higher ops/monitoring cost; treat as exception
Patterns combine . A single agent might ground on SharePoint knowledge, call ServiceNow via connector tools, and hand complex refunds to a child finance agent.
- Solution architecture choices
- Single agent with mixed knowledge + tools
Best for one domain (for example IT service desk) with one owner team. Keep tool count and knowledge source count manageable; author precise tool descriptions for generative orchestration.
Orchestrator + specialist agents
Best when:
- Security scopes differ (HR data must not leak into a public web channel agent)
- Teams own different systems (SAP COE vs ServiceNow ops)
- You integrate Foundry, Fabric data agents, or existing Copilot Studio agents
Plan handoff contracts : what context the parent passes, what the child returns, and which channel identity is trusted.
Middle-layer data integration
When conversational UX needs sub-second answers but the LOB system is slow or rate-limited, plan a cache or sync layer (Dataverse, Azure data services) plus clearer SLAs. Document peak calls per minute against each API—Microsoft’s integration planning examples explicitly track daily volume and peak rate.
Sample integration matrix (exam-ready template)
- Connected system Called by Called with Expected daily volume Peak Notes
- ServiceNow KB Generative answers / knowledge Connector knowledge 5,000 1,000 Ground tickets with KB
- ServiceNow incidents Tool / agent flow Prebuilt connector 2,000 400 User credentials for create
- SharePoint policies Knowledge Graph search 8,000 2,000 Entra user auth required
- Dataverse cases Tool Dataverse connector 1,500 300 Environment security roles
- Contoso Order API Topic HTTP / custom connector REST 500 100 Custom connector preferred for reuse
- SAP product master Nightly flow → Dataverse Agent flow 20,000 — Batch; agent queries Dataverse
- Exam scenarios to rehearse
Scenario A: Employees ask policy questions and must open IT tickets.
Plan: SharePoint knowledge for policies + ServiceNow create-incident tool; Authenticate with Microsoft or Entra manual auth so knowledge respects permissions.
Scenario B: Sales needs live order status from a custom ERP with OpenAPI, plus product PDFs in SharePoint.
Plan: Custom connector or REST tool for ERP; SharePoint knowledge for PDFs—not PDF-only for order status.
Scenario C: Global firm has separate Contoso HR and Contoso Finance agents already in production.
Plan: Multi-agent orchestration; do not copy all tools into one mega-agent.
Scenario D: Only a legacy desktop app can approve vendor payments; no API.
Plan: Computer use (with governance), not fake knowledge of yesterday’s approvals.
Planning checklist before build
List intents and label each know vs do vs hand off .
Map systems (ServiceNow, SAP, Dataverse, SharePoint, LOB APIs) to patterns.
Choose credentials model (user-delegated vs maker/service) per action.
Estimate volume and API limits; design batch middle layers where needed.
Decide single-agent vs multi-agent ownership and environment placement.
Record DLP, connector classifications, and secrets storage (Key Vault via flows when needed).
Only then design topics, tools, and knowledge sources.
Solid integration planning turns AB-620 case studies into mechanical decisions instead of guesswork.