Section 01 · Unit introduction

The integration problem

An AI capability is only useful if it can reach the data and the systems where work actually happens. In most organisations that means a landscape of legacy line-of-business applications, relational databases, third-party SaaS products, and a few well-loved spreadsheets — none of which were designed with an AI assistant in mind.

The integration question is therefore the question that decides whether an AI project ships. The model is rarely the hard part. Getting the right context to the model, and getting its output safely back into the systems people use, is where most of the engineering effort and most of the risk live.

By the end of this unit
  • Distinguish the main integration patterns available on the Microsoft platform and the situations each one suits.
  • Decide when to reach for a prebuilt connector, a Graph connector, a custom connector, or an event-driven design.
  • Identify the authentication, latency, and governance considerations that determine which pattern is safe to use.

Four ways to connect

  • Over 1,000 Microsoft-maintained connectors for common SaaS and Microsoft services
  • Used inside Power Automate, Power Apps, Logic Apps, and Copilot Studio
  • Best when a maintained connector already exists for your target system
  • Lowest build effort, lowest maintenance burden
  • Index external content into Microsoft Graph so Copilot can ground answers in it
  • Bring data from file shares, databases, and third-party repositories into Microsoft Search
  • Best when you want Copilot to read from a system, not act in it
  • Respects item-level permissions when configured correctly
  • Wrap any REST or SOAP API the system exposes in a connector definition
  • Required when no prebuilt connector exists for a legacy or bespoke system
  • You own the OpenAPI definition, authentication, and lifecycle
  • Highest flexibility, highest ownership cost
  • Systems publish events; AI processing is triggered by the event, not a poll
  • Implemented with Event Grid, Service Bus, or webhook triggers
  • Best for near-real-time reactions and decoupled, scalable designs
  • More moving parts; needs careful retry and idempotency handling
The model is the easy 20 per cent. The integration is the 80 per cent that decides whether anyone ever uses it.
Working principle · Integration design
Section 02

Connectors and Graph connectors

Two of the four patterns are low-code and Microsoft-maintained: prebuilt connectors and Graph connectors. They cover a surprising proportion of real integration needs, and you should always check whether one of them fits before commissioning custom work.

Prebuilt connectors

A prebuilt connector exposes a third-party or Microsoft service as a set of actions and triggers you can drop into a flow or app. SharePoint, SQL Server, Dataverse, Salesforce, ServiceNow, and SAP all have maintained connectors. Authentication is handled through the connection object — typically OAuth or a managed identity — so credentials are not embedded in the flow logic.

Graph connectors

A Graph connector is different in intent. Rather than letting an automation act in a system, it indexes that system's content into Microsoft Graph so that Copilot and Microsoft Search can ground responses in it. If your goal is "Copilot should be able to answer questions using our knowledge base in a legacy wiki", a Graph connector is the right tool — not a flow.

Decision note

Ask one question first: do you need the AI to read from the system or act in it? Reading for grounding points to a Graph connector. Acting — creating records, sending messages, updating status — points to a prebuilt or custom connector inside an automation.

Permissions trimming matters
When you index content with a Graph connector, you must map the source system's access control onto Microsoft Search so that a user only sees grounding content they are entitled to see. Skip this and Copilot can surface restricted material in its answers. Permission mapping is configuration, not an afterthought.
Connectors carry their own throttling
Each connector has request limits. A flow that loops over thousands of records through a connector will hit throttling and fail intermittently. Design for batching and respect the documented limits rather than discovering them in production.
Connections are shareable assets — and a governance surface
A connection holds credentials to a system. Who can create, share, and use connections is an administrative decision. Treat connections as a governed resource within your Power Platform environment strategy, not as something every maker can create freely.
Section 03

APIs and custom connectors

When no maintained connector exists — which is common for older line-of-business systems — you wrap the system's own API in a custom connector. This is the most flexible pattern and the one that carries the most ongoing ownership.

1. Confirm the system exposes a usable API

A REST API with an OpenAPI (Swagger) definition is ideal. SOAP and older interfaces can be wrapped but cost more. If the system has no API at all, you may need an integration layer in front of it — do not screen-scrape a production system as a long-term pattern.

2. Define authentication once, securely

Choose OAuth 2.0, API key, or managed identity depending on what the system supports. Store secrets in Azure Key Vault, never in the connector definition or flow. The custom connector references the secret; it does not contain it.

3. Model the actions you actually need

Expose only the operations the solution requires, with clear names and typed inputs and outputs. A tightly scoped connector is easier to govern and reason about than one that mirrors the entire API surface.

4. Plan the lifecycle

You now own this connector. When the underlying API changes, the connector breaks. Assign an owner, document the dependency, and include the connector in your environment promotion and testing process.

Knowledge check

A legacy CRM has a documented REST API but no prebuilt connector. The team needs Copilot Studio to create and update records in it. What is the appropriate pattern?

Section 04

Event-driven patterns

Polling — repeatedly asking "has anything changed?" — is simple but wasteful and slow. Event-driven integration flips the relationship: the source system announces a change, and your AI processing reacts. On Azure this is built with Event Grid, Service Bus, and webhook triggers.

Reflect

Think of an AI workflow you are planning. Does it need to react within seconds of something happening, or is a scheduled batch acceptable? The honest answer to that question usually decides whether you need event-driven complexity at all.

When event-driven earns its complexity

Near-real-time reactions
A support ticket arrives and you want an AI triage response within seconds. Polling every few minutes is too slow and too wasteful; an event trigger fires the moment the ticket is created.
Decoupling producers from consumers
With a message queue such as Service Bus between the source and the AI processing, a spike in events does not overwhelm the model endpoint. The queue absorbs the burst and the consumer drains it at a sustainable rate. This is also how you protect a rate-limited model from traffic spikes.
Idempotency and retries are non-negotiable
Event systems deliver at least once, which means a message can arrive twice. Your handler must be idempotent — processing the same event twice must not create two records or send two emails. Design a deduplication key and honour it before you go live.
Continue on Microsoft Learn

Deepen this with the official learning paths:

Get started with Power Automate ↗
Manage and govern Power Platform ↗

End of Unit 11

You should now be able to:

  • Match each integration pattern to the situations it suits.
  • Decide between reading for grounding and acting in a system.
  • Recognise when event-driven design is justified and what it demands of your handlers.
Section 05

Unit review

Question 1 of 4

Your goal is for Copilot to answer questions grounded in content held in a legacy internal wiki. Which pattern fits best?

Question 2 of 4

Why should secrets for a custom connector be stored in Azure Key Vault rather than in the connector definition?

Question 3 of 4

Why must an event handler be idempotent?

Question 4 of 4

What is the first question to ask before choosing an integration pattern?

End of module

You have completed Course 11: Connecting AI to Existing Systems. Next: Power Platform and AI — practical low-code automation with Power Automate, Power Apps, and AI Builder.

Craig Stanley Studio · Deploy — Architecture, Integration & Operations · Connecting AI to Existing Systems · Access by direct link only.