Microsoft Dataverse è il data platform sicuro e scalabile su cui poggia l’intera Power Platform. Quando crei una app con Power Apps, un flusso con Power Automate o un agente con Copilot Studio, Dataverse è il posto naturale dove archiviare e gestire i dati in modo strutturato, senza doverti preoccupare di infrastruttura, backup o scalabilità: è un servizio cloud completamente gestito, ospitato nel tenant di Microsoft e protetto da Microsoft Entra ID.

Il modello dati: tables, columns e relationships

Dataverse organizza i dati secondo il Common Data Model (CDM), uno schema standard e condiviso che definisce entità di business comuni (Account, Contact, ecc.) con nomi e significati coerenti tra applicazioni diverse.

Gli elementi fondamentali sono:

  • Tables (tabelle): rappresentano un tipo di entità, ad esempio “Clienti” o “Ordini”. Ogni riga è un record.
  • Columns (colonne): definiscono i campi di una tabella, ciascuno con un data type (testo, numero, data, choice, lookup, ecc.).
  • Relationships (relazioni): collegano le tabelle tra loro. Le più comuni sono one-to-many (1:N) e many-to-many (N:N), utili ad esempio per legare un cliente ai suoi ordini.

Dataverse include già molte standard tables predefinite (come Account e Contact) pronte all’uso, ma puoi anche creare custom tables su misura per i tuoi processi. Questo permette di partire velocemente e allo stesso tempo modellare esigenze specifiche.

Business rules: logica low-code

Le business rules consentono di applicare logica direttamente a livello di tabella senza scrivere codice, con un’interfaccia visuale. Il grande vantaggio è che la regola vale ovunque venga usata la tabella: sia nelle app che nell’ambiente di modellazione.

Con le business rules puoi:

  • impostare valori di default su una colonna;
  • eseguire validazioni e mostrare messaggi di errore;
  • applicare logica condizionale (mostra/nascondi, abilita/disabilita campi, rendi obbligatorio un campo).

Sono lo strumento tipico per garantire qualità e coerenza del dato in modo semplice e riutilizzabile, ideale per chi non è sviluppatore.

Security roles: accesso granulare

La sicurezza è uno dei punti forti di Dataverse. L’accesso non è “tutto o niente”: si basa su security roles che definiscono in modo preciso cosa un utente può fare.

Il controllo agisce su due livelli:

  • a livello di tabella: quali operazioni (Create, Read, Write, Delete, Append, Share) sono consentite su una data tabella;
  • a livello di record: fino a che ambito (solo i propri record, quelli del team/business unit, dell’organizzazione) l’utente può operare.

Gli utenti ereditano i permessi dai security roles assegnati, garantendo il principio del minimo privilegio.

Perché Dataverse rispetto a Excel o SharePoint

Excel e le liste di SharePoint vanno bene per dati semplici o volumi ridotti, ma Dataverse offre vantaggi decisivi quando servono dati aziendali strutturati:

  • Sicurezza granulare: permessi per tabella e per record tramite security roles, molto più fine della condivisione di un file o di una lista.
  • Scalabilità e performance su grandi volumi, con un modello relazionale vero (relationships, tipi di dato, chiavi).
  • Integrità dei dati garantita da colonne tipizzate, relazioni e business rules.
  • Logica integrata (business rules, colonne calcolate) che segue il dato ovunque venga consumato.

In sintesi: Excel/SharePoint per prototipi e casi leggeri; Dataverse per applicazioni di business che richiedono sicurezza, struttura e scala.

Trappole tipiche d’esame

  • Scenario: serve un archivio sicuro, relazionale e scalabile per una app enterprise con permessi per singolo record → risposta giusta: Microsoft Dataverse, non una lista SharePoint o un file Excel.
  • Scenario: vuoi imporre un valore di default e validare un campo senza scrivere codice → risposta giusta: business rule (non un plug-in o codice custom).
  • Scenario: un utente deve vedere solo i record che ha creato lui, non quelli dei colleghi → risposta giusta: security roles con scope a livello di record (non permessi di file).
  • Scenario: devi collegare “Ordini” a “Clienti” così che un cliente abbia molti ordini → risposta giusta: relationship one-to-many (1:N).
  • Scenario: la domanda cita lo schema standard e condiviso di entità come Account/Contact → risposta giusta: Common Data Model con le sue standard tables.