I workspace come contenitori collaborativi

Un workspace in Power BI service è l’unità organizzativa in cui team di analisti e sviluppatori collaborano su report, semantic model (già “dataset”), dashboard, dataflow e paginated report. A differenza del My Workspace personale, un workspace condiviso consente il co-sviluppo e la distribuzione strutturata dei contenuti, e costituisce il confine su cui si applicano i ruoli e le policy di governance.

Ogni workspace è associato a una capacity: shared (default, Pro) oppure Premium/Fabric capacity o Premium Per User (PPU). La capacity determina non solo prestazioni e funzionalità (refresh più frequenti, modelli più grandi, deployment pipeline), ma soprattutto chi può consumare i contenuti e con quale licenza.

I quattro ruoli di workspace

I ruoli si assegnano a livello di workspace — a singoli utenti, security group, gruppi Microsoft 365 o distribution list — e sono cumulativi in privilegi.

  • Viewer — legge e interagisce con i report (filtri, slicer, drill). Non modifica né pubblica. Sul semantic model non riceve automaticamente il permesso Build: senza di esso non può creare nuovi report né usare Analyze in Excel.
  • Contributor — crea, modifica ed elimina contenuti, pubblica report, configura scheduled refresh e credenziali delle origini dati. Non gestisce i permessi degli altri né pubblica/aggiorna l’app.
  • Member — tutto ciò che fa Contributor, più: pubblica e aggiorna l’app, condivide elementi e ne concede il reshare, aggiunge utenti con ruolo pari o inferiore, mette in evidenza contenuti.
  • Admin — pieno controllo: aggiorna ed elimina il workspace, gestisce tutti i ruoli inclusi altri Admin, cambia la capacity.

Permessi sul semantic model

Il punto critico a livello ASSOCIATE è distinguere l’accesso al report da quello al semantic model sottostante. Per costruire nuovi report o interrogare il modello (Excel, Analyze in Excel, composite model) serve il permesso Build, distinto dal semplice Read. Concedere Build troppo largamente amplia la superficie di riutilizzo dei dati; concederlo troppo poco blocca i self-service analyst. Chi ha ruolo di workspace (Contributor e superiori) ottiene Build implicitamente; il Viewer no.

Opzioni di distribuzione

App di Power BI

L’app di Power BI è il meccanismo consigliato per distribuire a grandi audience di sola lettura. Impacchetta un set curato di report e dashboard, supporta audience multiple con contenuti diversi per gruppo, e separa l’ambiente di authoring dal consumo: i consumatori vedono solo ciò che pubblichi, non il workspace di sviluppo.

Condivisione diretta

La condivisione diretta di un singolo report o dashboard (link o invito) è adatta ad audience piccole e ad-hoc. Attenzione: condividere il report concede implicitamente Read sul semantic model necessario a visualizzarlo, ma non Build, e ogni elemento va gestito singolarmente — non scala.

Impatto delle licenze

  • Pro: in shared capacity, sia autori sia consumatori necessitano di licenza Power BI Pro.
  • Premium/Fabric capacity (F64+ / P SKU): i consumatori con licenza Free possono visualizzare i contenuti; la Pro resta necessaria per pubblicare.
  • PPU: sblocca funzionalità Premium a livello di singolo utente, ma tutti — autori e consumatori — devono avere licenza PPU; non è possibile condividere con utenti Pro o Free.

Trappole tipiche d’esame

  • Scenario: a un analista che deve solo visualizzare i report è stato assegnato Member → sovradimensionamento; il ruolo corretto è Viewer (minimo privilegio). Member abilita pubblicazione dell’app e gestione permessi.
  • Scenario: hai condiviso il report ma i consumatori non riescono a creare report propri sul modello → manca il permesso Build sul semantic model; il Read basta a visualizzare, non a costruire.
  • Scenario: distribuire a centinaia di utenti in sola lettura → usa l’app di Power BI con audience, non la condivisione diretta elemento-per-elemento.
  • Scenario: utenti con licenza Free devono consumare i report senza acquistare Pro → ospita il workspace in Premium/Fabric capacity (F64+); in shared capacity servirebbe Pro per tutti.
  • Scenario: un collaboratore deve schedulare il refresh e modificare i report ma non gestire utenti né app → Contributor è sufficiente; Member o Admin sarebbero eccessivi.