9.2 Connect to Power Platform Connectors
Key Takeaways
- Power Platform connectors can serve dual roles in Copilot Studio: real-time knowledge for grounding without data replication (preview patterns) and tools/actions for read/write transactions.
- Real-time knowledge indexes metadata such as table and column names only; each request runs at runtime against the target system under the user's authentication tokens.
- Knowledge versus tools is an exam trap: use knowledge for natural-language Q&A over enterprise data; use tools when you must create, update, approve, or orchestrate multi-step changes.
- The same Power Platform connections are governed by environment data loss prevention (DLP) policies for both knowledge and actions.
- Supported knowledge connectors include systems such as Salesforce, ServiceNow, Azure SQL, Snowflake, Databricks, Zendesk, Confluence, Oracle, SAP OData, Dynamics 365, SharePoint, Dataverse, and Azure AI Search—availability depends on tenant/feature rollout.
9.2 Connect to Power Platform Connectors
Quick Answer: Power Platform connectors are live API bridges. In Copilot Studio they can ground answers as real-time knowledge (metadata indexed only; no data movement; runtime calls under the user’s identity) or run as tools/actions that read and write systems. Govern both with DLP. Never treat them as Graph index copies.
Where Copilot connectors index-then-answer, Power Platform connectors call-then-answer (or act). AB-620 Domain 2 expects you to choose the right role and configure knowledge without confusing it for tooling from Chapter 10.
Mental model: live bridge, two roles
Microsoft’s comparison article frames Power Platform connectors as connectors that call APIs in real time to read and/or write data and trigger actions across thousands of systems. In Copilot Studio:
- Real-time knowledge (preview patterns) — Ground generative answers on live enterprise systems without copying business rows into Microsoft 365. Microsoft indexes metadata (table names, column names), not full table contents, for the knowledge source.
- Tools / actions — Invoke connector operations from topics or agent-level tools to fetch a specific record, create a case, update an order, or complete a multi-step flow.
| Dimension | Power Platform connector |
|---|---|
| Primary purpose | Real-time knowledge with no data movement, or read/write tools and actions |
| Where connection lives | Power Platform connections per environment |
| Data movement for real-time knowledge | No bulk copy of business data into Graph for that pattern |
| Identity at runtime | Calls run under the user’s connection and tokens so source ACLs apply |
| Governance | Power Platform DLP / data policies enable or restrict connectors and knowledge sources |
| Latency | Depends on target API round-trips |
| Citations | Not inherent like Graph connectors; agent response logic presents returned facts |
| Best for | Up-to-the-minute status, transactional steps, no-replication constraints |
Knowledge versus tools — the exam trap
This leaf skill is titled Connect to Microsoft Power Platform connectors under enterprise knowledge sources, but the same connector technology also powers actions. AB-620 will punish candidates who only memorize “add ServiceNow” without specifying why.
| User intent | Prefer knowledge | Prefer tool / action |
|---|---|---|
| “Explain our Salesforce opportunity stages using live schema/data patterns” | Real-time knowledge over selected tables | Fixed REST get-one-record only if NL retrieval is not needed |
| “What is the current priority of INC-123?” | Real-time knowledge can ground the answer without Graph copy | Tool if you need a strict single-record contract in a topic |
| “Create a P1 incident and assign the network queue” | Not knowledge alone | Tool / agent flow with ServiceNow create operation |
| “Update the order ship date to Friday” | Not knowledge | Write action |
| “Summarize open cases over $50k for my accounts” | Knowledge (user-scoped query) | Tool if you must post results to another system |
Rule of thumb: If the success criterion is a grounded natural-language answer, think knowledge. If the success criterion is a state change in an external system, think tool. Mixed agents use both: knowledge to explain, tools to act.
Community and product behavior also surface an auth nuance: some structured knowledge sources execute in the end-user security context. That is a feature for permission fidelity. If a scenario requires a shared service account for a controlled write path, that is often designed as a tool (for example a flow with run-only connections)—not as “switch knowledge to maker credentials.”
Supported real-time knowledge connectors (maker awareness)
Microsoft documents supported Power Platform connectors for real-time knowledge patterns, including examples such as:
- Salesforce
- ServiceNow
- Azure SQL
- Azure AI Search
- SharePoint
- Dataverse
- Dynamics 365
- Snowflake
- Databricks
- Zendesk
- Confluence (cloud)
- Oracle Database
- SAP OData
- Google Sheets
Treat the list as feature-evolving—exam answers should reason about real-time, user-auth, DLP-governed knowledge, not memorize every logo forever. If a connector is missing from Featured, use Advanced. Preview availability can vary by region/tenant.
Configuration pattern in Copilot Studio
Aligned with Microsoft Learn steps for adding a Power Platform connector as knowledge:
- Open the agent.
- Add knowledge from Overview, Knowledge, or generative answers node properties.
- Select the real-time connector (Featured or Advanced).
- Sign in and create or select the connection with credentials appropriate to the environment.
- Choose target location / instance details for the system.
- Select tables/entities to expose as the knowledge surface.
- Name the knowledge source and write a clear description (critical for generative orchestration filtering when many sources exist).
- Where supported (Microsoft notes ServiceNow and Zendesk for this), add synonyms and glossary definitions so natural language maps to fields.
- Add to agent. Status moves In progress while metadata indexes, then Ready for testing.
Do not confuse this with custom connector as a tool (OpenAPI operations)—that is Domain 2 tools, not this knowledge leaf. Custom connectors still matter for enterprise APIs, but “Connect to Power Platform connectors” as knowledge is about grounding, not inventing every OpenAPI action here.
Authentication and governance
| Control | What to remember |
|---|---|
| User tokens | Runtime knowledge calls use the user’s authentication so only permitted data returns |
| Connection reuse | Connections established in Power Platform are reused by Copilot Studio |
| DLP / data policies | Admins enable/disable connectors and knowledge sources by environment or tenant |
| Standard vs premium | Connector licensing class can affect availability; plan with admins |
| Environment scope | Wrong environment connection → empty or wrong instance data |
| Channel auth | End-user auth still required for identity-bound systems; anonymous public channels cannot magically impersonate every CRM user |
Exam trap: “Turn off DLP so the agent can see everything” is never the responsible design answer. AB-620 pairs integration with security and governance thinking from Domain 1.
Decision guide: Copilot connectors vs Power Platform connectors
| Choose Copilot (Graph) connectors when… | Choose Power Platform connectors when… |
|---|---|
| Large bodies of external content need semantic indexing and citations across Microsoft 365 | Data must not be replicated into Microsoft 365 |
| Answers benefit from Graph search quality over KB articles, wikis, tickets | Facts must be up-to-the-minute from the live system |
| Content is relatively stable and searchable | You need transactions (create/update) via tools |
| Admin-led index pipeline is acceptable | Maker-led environment connections under DLP are the control plane |
Mixed mode (most enterprises): Index evergreen policies and historical KB with Copilot connectors; use Power Platform real-time knowledge for live priorities and tools for case creation.
Realistic scenarios
Scenario A — Live CRM without Graph copy. Contoso legal forbids copying Salesforce opportunity tables into Microsoft Graph. Builders add the Salesforce Power Platform connector as real-time knowledge, select opportunity-related tables, document synonyms for stage names, and keep DLP allowing Salesforce only in the production environment. Sellers ask, “What is the stage and amount for Contoso Renew?” and receive user-scoped answers without a Graph ingest project.
Scenario B — Knowledge plus action. The same agent answers “Show my open P1s” via real-time ServiceNow knowledge, then offers “Create incident” as a tool. Candidates who only add knowledge cannot pass the write path; candidates who only add tools force users through rigid dialogs for every Q&A.
Scenario C — Wrong surface. A stem says users need semantic citations from a multi-year Confluence corpus reused in Microsoft Search and agents. Prefer Copilot connectors (admin index), not only a one-off Power Platform call that never builds enterprise graph knowledge.
Pitfalls
- Using real-time knowledge when the business goal is write—missing tools.
- Expecting Graph-style automatic citations from every PP knowledge call.
- Ignoring DLP blocks that make connections fail only in certain environments.
- Poor descriptions/synonyms → generative orchestration skips the source among 25+ knowledge sources.
- Confusing Azure AI Search connector entry points with full Azure AI Search knowledge design (next section).
- Assuming maker credentials override end-user ACL for knowledge; design tools/flows when shared identity is required.
Success checklist
- Explain no data movement metadata indexing for real-time knowledge.
- Separate knowledge grounding from tools that change state.
- Configure tables, names, descriptions, and supported synonyms/glossary.
- Map governance to DLP and user identity.
- Choose PP vs Graph connectors with a clear constraint story (replication, freshness, transactions, citations).
When you can defend why a ServiceNow connector is knowledge in one stem and a tool in the next, you have internalized this blueprint leaf.
How does Microsoft describe data movement for Power Platform real-time knowledge connectors in Copilot Studio?
A Contoso agent must create a ServiceNow incident from chat and also answer natural-language questions about open incidents. What design best matches Microsoft guidance?
Which control plane primarily governs whether makers can use specific Power Platform connectors as knowledge or actions in an environment?