Low-code first, pro-code where needed

Il Solution Architect PL-600 non è un evangelista del codice custom: è chi decide dove fermarsi. Il principio guida è low-code first / pro-code where needed. Ogni riga di codice pro-code introdotta è debito tecnico che qualcuno dovrà mantenere, testare a ogni release della piattaforma e documentare. La domanda d’esame ricorrente non è “come lo scrivo”, ma “serve davvero scriverlo?”.

Il ragionamento architetturale procede a strati: prima le capability out-of-the-box di Dataverse (business rules, calculated/rollup columns, formula columns), poi le componenti low-code (Power Fx, cloud flow di Power Automate, agent di Copilot Studio, modelli AI Builder), e solo quando il requisito eccede queste opzioni si scende al pro-code (plugin, Azure Functions, custom connector, PCF).

Dove AI Builder aggiunge valore

AI Builder copre scenari di intelligenza artificiale prepacchettizzati senza data science: document processing (estrazione da fatture, ricevute, ID), prediction (modelli binari su dati Dataverse storici), category classification, sentiment analysis e prompt GPT riutilizzabili. Il valore è la supportabilità: il modello vive dentro l’ALM di Power Platform, si sposta con le solution, consuma AI credits governati a livello di environment.

Il trade-off chiave riguarda i modelli custom. Se il requisito è “estrai campi da un layout documentale ricorrente”, AI Builder document processing è la scelta a minor rischio. Se invece serve una computer vision addestrata su un dominio esotico o un LLM fine-tuned, si esce dalla piattaforma verso Azure AI Foundry e si integra via custom connector: più potenza, più costo operativo, ALM separato.

Copilot Studio vs orchestrazione custom

Copilot Studio è la scelta d’elezione per agenti conversazionali e agenti autonomi che orchestrano azioni. Con topic, generative orchestration, knowledge source (Dataverse, SharePoint, siti pubblici) e actions (flow, connector, prompt) copre la maggior parte dei casi self-service e di automazione agentica. È estendibile e governabile centralmente.

Si estende con pro-code quando: serve logica di orchestrazione che la generative orchestration non modella, integrazione con sistemi legacy senza connector, oppure controllo fine su autenticazione e data residency. In quei casi l’agente chiama un’Azure Function o un custom connector, senza spostare fuori tutta l’esperienza conversazionale.

Estendere Dataverse: plugin, Functions, connector

Sul lato dati la scelta tra plugin e Azure Functions è un classico architetturale allineato al Well-Architected Framework:

  • Plugin (sync/async) — quando serve logica transazionale dentro la transazione Dataverse: validazione atomica, rollback, coerenza immediata. Vincolo duro: 2 minuti di timeout, sandbox isolata, no chiamate a servizi lenti in modalità sync. È il posto giusto per business logic vicina al dato, non per integrazioni pesanti.
  • Azure Functions — quando la logica è lunga, resiliente, disaccoppiata: integrazioni esterne, elaborazioni batch, fan-out. Il pattern raccomandato è event-driven: Dataverse emette eventi via plugin async o Dataverse plugin execution verso Service Bus/Event Grid, la Function consuma. Migliora Reliability e Performance Efficiency isolando i fallimenti esterni dalla UX.
  • Custom connector — quando la stessa API esterna deve essere riusabile in modo low-code da flow, app e Copilot Studio, con gestione centralizzata di auth (preferibilmente Microsoft Entra ID) e policy DLP.

Il pilastro Security impone di gestire i segreti in Azure Key Vault (mai in variabili plaintext), autenticare via Entra ID / managed identity, e applicare le DLP policy perché un connector custom non finisca a esfiltrare dati.

Governare l’extensibility

Ogni estensione va dentro l’ALM: solution managed, pipeline Power Platform, ambienti dev/test/prod separati. Il pro-code sparso — un plugin registrato a mano in produzione, una Function senza IaC — è il debito che a lungo termine rende l’ambiente non supportabile e non riproducibile. Operational Excellence significa che ogni componente è versionato, deployato via pipeline e osservabile (Application Insights sui plugin e sulle Functions).

Trappole tipiche d’esame

  • Requisito: estrarre dati da fatture con layout ricorrente → AI Builder document processing, non una computer vision custom su Azure. Minor rischio, dentro l’ALM.
  • Requisito: chatbot self-service su knowledge SharePoint + Dataverse → Copilot Studio con knowledge source e generative orchestration; il codice custom qui è overengineering.
  • Requisito: integrazione con API esterna lenta (>2 min) o batch → Azure Function event-driven, non un plugin sync (violerebbe il timeout sandbox e degraderebbe la UX).
  • Requisito: validazione atomica con rollback alla creazione del record → plugin sincrono dentro la transazione Dataverse, non un cloud flow (che è asincrono e non garantisce atomicità).
  • Requisito: stessa API riusata da app, flow e agente con auth centralizzata → custom connector con Entra ID + Key Vault + DLP, non tre integrazioni duplicate.