Il problema: dove mettere i dati di un’app Power Platform

Come Functional Consultant, una delle prime decisioni architetturali riguarda dove risiedono i dati che alimentano una Power App o un flusso. Le opzioni tipiche sono Microsoft Dataverse, le SharePoint list, i file Excel e i connettori standard verso sistemi esterni (SQL, Dynamics, sistemi line-of-business). La scelta non è mai “il più potente vince”: dipende da relazioni tra i dati, requisiti di sicurezza, logica di business e — spesso sottovalutato — licenze.

Cosa rende Dataverse la scelta forte

Dataverse è un data platform relazionale gestito, non un semplice contenitore di righe. Va scelto quando servono capacità che le SharePoint list non offrono in modo nativo.

  • Relazioni complesse: Dataverse supporta relazioni 1:N, N:1 e N:N con integrità referenziale, lookup reali e cascade behavior. Su SharePoint le colonne Lookup esistono ma non gestiscono in modo robusto molte-a-molte e integrità.
  • Sicurezza granulare: il modello di security role, business unit, team e permessi a livello di table, record (row-level) e colonna (column-level / field security) è nativo. Se lo scenario richiede che l’utente A veda solo i propri record e il manager quelli del team, Dataverse lo fa senza workaround.
  • Logica server-side: business rules, calculated/rollup column, plug-in e regole di validazione girano lato server, quindi valgono qualunque sia il client (app, flusso, API). Su SharePoint la logica vive spesso solo dentro l’app e si aggira facilmente.
  • Scalabilità e tipi dati ricchi: gestisce volumi elevati meglio del soglia di 5.000 elementi delle SharePoint view, offre choice, currency, datetime con timezone, e alternate/key per l’upsert.
  • Integrazione: è il data layer nativo di Dynamics 365 e si integra con Microsoft Purview per governance/data classification e con l’ecosistema AI.

Table standard vs custom

Dataverse arriva con standard table (Account, Contact, ecc.) che fanno parte del data model comune. La regola d’esame: riusa la standard table quando l’entità di business corrisponde (un cliente → Account/Contact), perché eredita relazioni, integrazione Dynamics e mapping già pronti. Crea una custom table solo quando il concetto è specifico del dominio e nessuna standard table lo rappresenta. Evita di duplicare Account con una custom “Clienti”.

Quando NON usare Dataverse

Dataverse ha un costo: richiede licenze premium (Power Apps per-app o per-user, Power Automate premium). Va evitato quando:

  • I dati sono una lista semplice senza relazioni né sicurezza per record (es. elenco FAQ, registro presenze basilare) → SharePoint list è sufficiente e coperta da Microsoft 365.
  • Ci sono vincoli di budget e gli utenti hanno solo licenze M365 seeded → i connettori standard (SharePoint, Excel/OneDrive, Outlook) non consumano premium.
  • I dati vivono già in un sistema autoritativo (SQL, ERP) e serve solo leggerli/scriverli → usa il connettore standard verso quella fonte, non replicare in Dataverse.
  • Il caso d’uso è prototipale o monouso con pochi record e nessun requisito di governance.

Excel/OneDrive resta accettabile solo per dataset piccolissimi e statici: niente concorrenza affidabile, niente delegation robusta, niente sicurezza.

Griglia decisionale rapida

  • Relazioni N:N + integrità → Dataverse
  • Sicurezza row/column-level → Dataverse
  • Logica valida su tutti i client → Dataverse
  • Lista semplice, utenti solo M365 → SharePoint
  • Fonte già esistente (SQL/ERP) → connettore standard

Trappole tipiche d’esame

  • Scenario: “L’azienda ha solo licenze Microsoft 365 e vuole minimizzare i costi per un semplice registro visitatori.” → Risposta giusta: SharePoint list, NON Dataverse. Scegliere Dataverse per abitudine ignora il costo delle licenze premium obbligatorie.
  • Scenario: “Ogni venditore deve vedere solo i propri lead; i manager vedono quelli del proprio team.” → Risposta giusta: Dataverse con security role + business unit/team e row-level security. SharePoint non copre questo requisito in modo nativo.
  • Scenario: “Serve una relazione molti-a-molti tra Progetti e Consulenti con integrità referenziale.” → Risposta giusta: Dataverse (relazione N:N), non colonne Lookup SharePoint.
  • Scenario: “I dati clienti esistono già in un database Azure SQL usato dall’ERP e vanno solo consultati nell’app.” → Risposta giusta: connettore SQL standard, non migrare/duplicare in Dataverse.
  • Scenario: “Una regola di validazione deve valere sia dall’app sia dai flussi automatizzati.” → Risposta giusta: Dataverse business rule / plug-in (server-side), non validazione solo nel canvas app.