Un custom connector estende Power Platform quando nessun connettore standard copre l’API di cui hai bisogno. È un wrapper attorno a una REST API che espone actions e triggers riutilizzabili in Power Automate cloud flow, Power Apps e Copilot Studio, con gestione centralizzata di autenticazione, parametri e schema di risposta.

Definire un custom connector

Un custom connector è essenzialmente una OpenAPI (Swagger 2.0) definition arricchita da metadati Power Platform. Puoi crearlo in quattro modi:

  • Import di una OpenAPI definition (.json/.yaml): il metodo più preciso, mantiene schema, operationId e descrizioni.
  • Import di una Postman Collection: utile quando hai già chiamate di esempio; genera automaticamente parametri e response.
  • Da zero con il wizard (General → Security → Definition → Test).
  • Da un’Azure Function o Logic App esistente.

Il wizard è organizzato in fasi: General (host, base URL, HTTPS obbligatorio), Security (autenticazione), Definition (actions/triggers) e Test. Ogni operazione mappa un verbo HTTP + path su un’action con parametri di request e schema di response (fondamentale: senza response schema definito perdi il dynamic content tipizzato nel flow).

Autenticazione

La scelta del tipo di autenticazione è una decisione architetturale ricorrente all’esame:

  • No authentication: solo per API pubbliche.
  • Basic authentication: username/password, richiesti alla creazione della connection.
  • API Key: l’utente inserisce la chiave quando crea la connection; tu definisci nome del parametro e posizione (header o query). Semplice, ma la chiave è legata all’identità del chiamante, non delega scope.
  • OAuth 2.0: per identity provider come Microsoft Entra ID, GitHub, Google. Configuri Client ID, Client secret, Authorization/Token URL e scope. È la scelta corretta quando serve delegated access per-utente, refresh token e permessi granulari.

Con OAuth 2.0 verso Microsoft Entra ID registri una app registration e usi il Resource URL dell’API target. Il redirect URL globale di Power Platform (https://global.consent.azure-apihub.net/redirect) va aggiunto tra i redirect URI dell’app.

Actions, triggers e policy templates

Le actions eseguono un’operazione on-demand. I triggers avviano un flow e sono di due tipi:

  • Polling trigger: Power Automate chiama periodicamente l’endpoint; usi il campo x-ms-trigger e configuri la logica di deduplica/paginazione.
  • Webhook trigger: il servizio a monte notifica Power Automate registrando una subscription (x-ms-notification-content). Preferibile quando l’API lo supporta, perché evita il polling.

Le policy templates trasformano request/response senza scrivere codice: Set HTTP header, Route request (redirect condizionale), Convert array to object, Set property value. Sono lo strumento giusto per adattare payload o iniettare header senza modificare l’API a monte.

Quando usare cosa

  • Connettore standard: se esiste, usalo sempre — è gestito e certificato da Microsoft.
  • Custom connector: quando l’API non ha connettore standard e la riuserai in più flow/app, o vuoi centralizzare auth e schema. È l’unico modo per esporre triggers custom.
  • Chiamata HTTP diretta (azione HTTP o HTTP with Microsoft Entra ID): per una singola chiamata one-off, un prototipo, o quando non vuoi mantenere una definition. Attenzione: l’azione HTTP è premium e non riutilizzabile, e gestisci auth/schema manualmente ogni volta.

Distribuzione e limiti

Un custom connector vive in un environment e si sposta tra ambienti come componente di una solution (ALM). È diverso da un certified connector: la certificazione è il processo con cui pubblichi il connettore in tutti i tenant del catalogo pubblico Microsoft, richiede validazione e un backend pubblicamente raggiungibile. Per uso interno aziendale non serve certificare: basta condividere il custom connector o includerlo nella solution.

Trappole tipiche d’esame

  • Serve delegated access per-utente con refresh token e scope → OAuth 2.0 (spesso verso Microsoft Entra ID), non API Key.
  • Chiamata singola one-off a una REST API in un cloud flow → azione HTTP; il custom connector si giustifica solo con il riuso o l’esigenza di un trigger.
  • Distribuire il connettore a un altro environment dell’organizzazione → inseriscilo in una solution; NON confondere con la certification, che serve solo per il catalogo pubblico multi-tenant.
  • Rispettare il rate limit del servizio a monte → gestiscilo nel flow con retry policy/concurrency control e paginazione; il connettore non impone da sé i limiti dell’API.
  • Il secret OAuth/API key non deve finire hard-coded → il segreto è configurato a livello di connector/connection (idealmente via Microsoft Entra ID app registration), non incollato nei parametri del flow.