2.1 Plan Integration with Enterprise Systems

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:

1. What the agent may know (knowledge / RAG)
2. What the agent may do (tools, connectors, flows, APIs)
3. Who owns each capability (single agent vs multi-agent)
4. How identity flows (covered in 2.2)
5. 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

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:

1. Custom connector (reusable OpenAPI wrapper) — best default for low-code reuse across agents
2. HTTP request in a topic — faster to prototype, harder to govern/reuse
3. REST API tool on the agent — generative orchestration can call it as a tool
4. MCP tools — standardized external tool/data exposure when the enterprise standardizes on Model Context Protocol
5. Computer use — last resort when only a UI exists (no API)

Integration pattern catalog

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)

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

1. List intents and label each know vs do vs hand off.
2. Map systems (ServiceNow, SAP, Dataverse, SharePoint, LOB APIs) to patterns.
3. Choose credentials model (user-delegated vs maker/service) per action.
4. Estimate volume and API limits; design batch middle layers where needed.
5. Decide single-agent vs multi-agent ownership and environment placement.
6. Record DLP, connector classifications, and secrets storage (Key Vault via flows when needed).
7. Only then design topics, tools, and knowledge sources.

Solid integration planning turns AB-620 case studies into mechanical decisions instead of guesswork.