Study guide
11.2 Evaluating and Recommending Connectors
Microsoft Certified: Intelligent Applications Builder Associate AB-410
Track your progress as you read
Finished sections get a check mark.
1 Introduction
1.1 About the AB-410 Exam 1.2 How to Use This Study Guide
2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools
2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options
3 Chapter 3: Environments and ALM Strategy
3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy
4 Chapter 4: Dataverse Tables and Columns
4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns
5 Chapter 5: Relationships, AI Data Features, and Data Security
5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security
6 Chapter 6: Model-Driven App Forms and Views
6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language
7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps
7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards
8 Chapter 8: Creating and Designing Canvas Apps
8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps
9 Chapter 9: Canvas App Components, Variables, and Error Handling
9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps
10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps
10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App
11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals
11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows
12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting
12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows
13 Chapter 13: Building Prompts in AI Hub
13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt
14 Chapter 14: Prompt Settings, Models, and Consuming AI
14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows
15 Chapter 15: Business Rules and Business Process Flows
15.1 Configuring Business Rules 15.2 Configuring Business Process Flows
16 Chapter 16: Calculated Columns and Business Logic Strategy
16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic
11.2 Evaluating and Recommending Connectors
Key Takeaways Explain This Topic AI
Connectors are pre-built proxies around APIs; the catalog has 1,000+ connectors, and each exposes triggers, actions, or both
Standard connectors (SharePoint, Outlook, Teams) ship with Microsoft 365; premium connectors (Dataverse, SQL Server, HTTP, and every custom connector) require a Power Automate premium license
A connection is an authenticated instance of a connector stored in one environment; a connection reference is a solution component that points to a connection so managed solutions can be re-pointed at import without editing flows
DLP policies classify every connector as Business, Non-business, or Blocked, and Business and Non-business connectors can never be combined in the same flow or app
Each connector enforces its own throttling limits — for example, the SharePoint connector allows roughly 600 calls per minute per connection
Last updated: July 2026
A connector is a pre-built wrapper around a service's API. Power Platform offers more than 1,000 connectors , and every connector exposes triggers (events that start a run), actions (operations performed inside a run), or both. The Office 365 Outlook connector has both; the Approvals connector is actions-only — it can never start a flow by itself.
Standard, Premium, and Custom
Standard connectors are included with Microsoft 365 licenses: SharePoint, OneDrive for Business, Office 365 Outlook, Office 365 Users, Teams, Excel Online. No Power Automate premium license is needed to use them.
Premium connectors require a premium entitlement (Power Automate Premium, per-flow, or pay-as-you-go): Microsoft Dataverse , SQL Server, Salesforce, SAP, the generic HTTP actions, and all custom connectors. A flow containing even one premium connector is a premium flow, and every run-only user needs the matching license.
Custom connectors wrap any REST API that is not already in the catalog. You build one from an OpenAPI (Swagger) definition , a Postman collection , or from blank — defining the host, authentication (none, Basic, API key, or OAuth 2.0, typically with Microsoft Entra ID), actions, and optionally webhook triggers. A custom connector is visible only inside the tenant where it is created or shared.
Exam trap: the HTTP actions are premium. A maker holding only a seeded Microsoft 365 license cannot 'get around' premium licensing by calling a third-party API with the raw HTTP connector instead of its premium connector.
Microsoft-Published vs Independent Publishers
Microsoft-published connectors ship from Microsoft and appear in every tenant. Independent publisher (verified) connectors come from ISVs and partners through Microsoft's connector certification program: the publisher submits the connector through the ISV certification pipeline, Microsoft validates its API definition, documentation, and security model, and once certified it is deployed to the public catalog for all tenants. Until a custom connector goes through certification it stays private to your organization — that lifecycle (custom → certified → public catalog) is a favorite exam point.
Connections vs Connection References
A connection is an authenticated instance of a connector stored in one environment — the result of signing in to SharePoint, SQL, or a third-party service. Connections live under make.powerautomate.com → Connections; they are environment-scoped and tied to the identity that created them.
A connection reference is a solution component that contains no credentials at all; it simply points at a connection. When a flow inside a solution uses connection references, application lifecycle management (ALM) becomes clean: export the managed solution, import it into production, and at import time point each connection reference at the production connection — no opening the flow, no re-authenticating inside the designer. This is why the exam's ALM questions push you toward always building flows inside solutions with connection references . Connections themselves cannot travel in a solution; connection references can.
DLP Policies: Business, Non-business, Blocked
Data loss prevention (DLP) policies are configured in the Power Platform admin center (Policies → Data policies) at tenant or environment scope. Every connector is classified into one of three groups:
- DLP group Meaning Typical members
- Business May share data only with other Business connectors Dataverse, SharePoint, Outlook, Teams, SQL Server
Non-business May share data only with other Non-business connectors Consumer/social services such as X (Twitter), Gmail, personal Dropbox
Blocked Cannot be used in any app or flow within scope Whatever the admin prohibits
Data cannot cross the Business/Non-business boundary inside a single flow or app. A maker who tries to save a flow combining Dataverse (Business) with X (Non-business) gets a DLP error at save time; if an admin later tightens a policy, already-enabled flows that violate it are suspended. Two nuances the exam likes: (1) certain Microsoft first-party connectors such as SharePoint and Teams cannot be blocked , and (2) DLP governs connector combinations — it does not inspect the data payload itself.
Throttling and Performance Limits
Each connector enforces its own throttling limits , and exceeding them produces HTTP 429 responses (Power Automate retries automatically, but throughput collapses). Numbers worth remembering:
SharePoint connector: about 600 calls per minute per connection .
Dataverse: service protection limits of roughly 6,000 requests per user per 5 minutes for paid licenses, enforced by the platform.
Power Automate itself: per-license API request entitlements measured per 24 hours, plus structural limits such as the 100,000-item ceiling on an Apply to each loop.
Design around throttling: batch reads with OData filters and pagination instead of row-by-row loops, reuse trigger payload values instead of adding redundant Get row actions, and raise Apply-to-each concurrency only when the downstream connector can actually absorb the call rate.
Connector Action vs Dataverse Action: The Recommendation Trap
When the data lives in Dataverse, recommend the native Dataverse connector actions (Add a new row, Update a row, List rows, Delete a row, Relate rows, Perform a bound or unbound action) rather than generic HTTP calls against the Web API. The Dataverse connector handles authentication, OData query construction, and typed outputs for downstream dynamic content. The mirror-image trap is reaching for a custom connector when a certified connector already covers the service — build custom only when the API genuinely is not in the catalog. The decision order for any 'how should the flow call this system?' question is: native connector action → certified third-party connector → custom connector → raw HTTP as the last resort.