Un report può essere impeccabile in Power BI Desktop e diventare davvero utile solo quando viene pubblicato, aggiornato e condiviso nel Power BI Service. Qui spiego come funziona l’ambiente cloud, quali differenze esistono tra workspace, report e dashboard, e come usare DAX per costruire indicatori affidabili senza cadere negli errori più comuni.
Il servizio cloud trasforma i modelli DAX in analisi condivise e aggiornate
- Power BI Service ospita report, dashboard e modelli semantici accessibili via browser.
- Power BI Desktop serve soprattutto per preparare dati, relazioni, visualizzazioni e formule DAX.
- Le misure DAX cambiano risultato in base a filtri, segmentazioni e livello di dettaglio del report.
- Il refresh programmato arriva fino a 8 volte al giorno con Pro e fino a 48 con PPU o capacità Premium.
- La sicurezza dipende da workspace, ruoli, permessi e RLS, non dal semplice fatto che un report sia online.
Che cos’è il servizio cloud di Power BI e a cosa serve
Il servizio online di Power BI è il punto in cui i contenuti analitici vengono pubblicati, distribuiti e utilizzati da altre persone. Non è soltanto uno spazio dove caricare file: permette di visualizzare report interattivi, creare dashboard, gestire autorizzazioni, programmare aggiornamenti e distribuire raccolte di contenuti tramite app.
Io lo considero l’ultimo anello di una catena che parte dai dati e arriva alla decisione. Power BI Desktop è più adatto alla costruzione del modello, mentre l’ambiente cloud è pensato per la collaborazione e il consumo quotidiano delle informazioni.
Un flusso tipico funziona così:
- si collegano una o più fonti, come Excel, SQL Server, CRM o file CSV;
- si puliscono e trasformano i dati con Power Query;
- si costruisce un modello con tabelle, relazioni e misure DAX;
- si crea il report in Power BI Desktop;
- si pubblica il contenuto in un workspace;
- si configura il refresh e si distribuisce il risultato agli utenti.
Il vantaggio principale è che il lettore non deve ricevere ogni volta un nuovo file. Accede allo stesso contenuto online, applica filtri e segmentazioni e vede i dati secondo i permessi assegnati.
Workspace, report, dashboard e modello semantico non sono la stessa cosa
Molti problemi iniziali nascono dalla confusione tra questi quattro elementi. Microsoft definisce il modello semantico, chiamato in passato dataset, come il contenitore dei dati su cui vengono costruiti report e dashboard. Se il modello è progettato male, anche la visualizzazione più elegante produrrà risultati poco affidabili.
| Elemento | Che cosa contiene | Quando si usa |
|---|---|---|
| Modello semantico | Tabelle, relazioni, colonne, gerarchie e misure DAX | Per centralizzare dati e logica di calcolo |
| Report | Una o più pagine di grafici, tabelle, filtri e indicatori | Per analizzare un tema in profondità |
| Dashboard | Una singola pagina con riquadri, chiamati tile | Per monitorare rapidamente gli indicatori principali |
| Workspace | Area collaborativa che raccoglie contenuti e autorizzazioni | Per sviluppare, gestire e distribuire soluzioni |
| App | Raccolta organizzata di report e dashboard pubblicata agli utenti | Per offrire una versione controllata al pubblico aziendale |
Un report risponde a domande analitiche, per esempio quali prodotti hanno perso margine in Lombardia. Una dashboard, invece, dovrebbe mostrare in un’unica schermata pochi KPI essenziali, come fatturato, margine e ordini aperti. Usare una dashboard come se fosse un report completo porta quasi sempre a sovraccaricare la pagina.
Per un team italiano potrei organizzare un workspace commerciale con il modello semantico certificato, i report di analisi vendite e un’app destinata alla direzione. Questa separazione riduce le copie dello stesso file e aiuta a mantenere una singola versione attendibile dei numeri.
DAX nel servizio cloud fa la differenza tra un grafico e un’analisi
DAX, acronimo di Data Analysis Expressions, è il linguaggio usato per creare misure, colonne calcolate, tabelle calcolate e alcune regole di sicurezza. La parte più importante non è memorizzare decine di funzioni, ma capire il contesto di filtro, cioè l’insieme di filtri che determina quali righe entrano nel calcolo.Misure e colonne calcolate hanno scopi diversi
Una misura viene calcolata quando il visual ne ha bisogno. Per esempio:
Vendite totali = SUM ( Vendite[Importo] )Se inserisco questa misura in una tabella per regione, il risultato cambia per ogni regione. Se aggiungo un filtro sull’anno o sulla categoria, DAX ricalcola il valore nel nuovo contesto. È il motivo per cui le misure sono normalmente la scelta migliore per KPI e indicatori dinamici.
Una colonna calcolata, invece, viene valutata riga per riga durante l’aggiornamento del modello. Può essere utile per classificare un prodotto o creare un attributo stabile, ma aumenta la dimensione del modello. Nella pratica preferisco creare una misura quando il valore deve reagire ai filtri del report.
Un esempio pratico con margine e anno precedente
Per calcolare il margine percentuale si può partire da misure semplici:Margine = SUM ( Vendite[Margine] )
Margine % = DIVIDE ( [Margine], [Vendite totali] )La funzione DIVIDE è più sicura della divisione diretta perché gestisce correttamente il caso in cui il denominatore sia vuoto o uguale a zero. È un dettaglio piccolo, ma evita molti messaggi di errore nei report destinati a utenti non tecnici.
Per confrontare il risultato con l’anno precedente servono una tabella calendario ben costruita e una relazione corretta con la tabella delle vendite. Una misura può essere scritta così:
Vendite anno precedente =
CALCULATE (
[Vendite totali],
DATEADD ( Calendario[Data], -1, YEAR )
)Il contesto di riga non è il contesto di filtro
Il contesto di riga rappresenta la riga corrente, tipico delle colonne calcolate e delle funzioni iteratrici. Il contesto di filtro nasce invece da slicer, filtri pagina, filtri visuale, righe e colonne di una matrice. Confonderli è una delle ragioni principali per cui una misura restituisce un totale diverso da quello atteso.
Quando una formula diventa complessa, io la scompongo in più misure e uso variabili DAX. Il codice è più leggibile, il debugging è più rapido e diventa più semplice spiegare il risultato a chi dovrà mantenere il modello dopo di me.
Pubblicazione, refresh e sicurezza richiedono una procedura precisa
Pubblicare un file PBIX non significa aver completato il progetto. Dopo l’invio al workspace bisogna controllare credenziali, connessioni, modalità di archiviazione e aggiornamento. Con il metodo Import i dati vengono caricati nel modello; con DirectQuery, invece, molte interrogazioni vengono eseguite direttamente sulla fonte.
Se la sorgente si trova nella rete aziendale, può essere necessario un gateway, cioè un componente che permette al servizio cloud di raggiungere database e file interni senza spostarli manualmente nel cloud.
Quante volte si possono aggiornare i dati
Con Power BI Pro si possono configurare fino a 8 refresh programmati al giorno. Con Premium Per User o con una capacità Premium o Fabric il limite sale fino a 48 aggiornamenti giornalieri. Questi sono limiti operativi, non una garanzia che il dato sia sempre in tempo reale.
Un aggiornamento può fallire per credenziali scadute, gateway offline, query troppo lente o modifiche alla struttura della fonte. Per questo conviene attivare le notifiche di errore e controllare lo storico dei refresh, invece di accorgersi del problema quando qualcuno segnala che il dashboard mostra dati vecchi.
Leggi anche: Drillthrough in Power BI e DAX - guida alla pagina di dettaglio
Ruoli, app e sicurezza a livello di riga
I workspace prevedono quattro ruoli principali: Admin, Member, Contributor e Viewer. Il ruolo Viewer è adatto a chi deve leggere i dati, mentre gli altri ruoli concedono capacità crescenti di modifica e gestione.
Quando utenti diversi devono vedere porzioni diverse dello stesso modello, si usa la Row-Level Security, o RLS. Per esempio, un agente commerciale può visualizzare solo i clienti assegnati alla propria area. Le regole vengono definite nel modello, spesso con espressioni DAX basate sull’identità dell’utente.
La RLS non sostituisce la gestione dei ruoli. Gli utenti con permessi elevati nel workspace possono avere capacità di modifica che impediscono l’applicazione del filtro nello stesso modo previsto per i semplici lettori. Prima della distribuzione bisogna quindi testare ogni ruolo con account reali o con la funzione di simulazione dedicata.
Licenze e scelta dell’architettura dipendono da chi deve usare i dati
La licenza gratuita permette di lavorare nel proprio spazio personale, ma non offre lo stesso modello di condivisione delle licenze Pro e Premium Per User. Per pubblicare in workspace condivisi, modificare contenuti collaborativi e condividere report con altri utenti servono normalmente Pro o PPU, salvo scenari in cui i contenuti risiedano in una capacità Premium o Fabric idonea.
| Scenario | Scelta generalmente adatta | Attenzione principale |
|---|---|---|
| Analisi personale e prototipi | Power BI Desktop e workspace personale | La condivisione è limitata |
| Team piccolo che collabora sui report | Workspace condiviso con licenze Pro | Gestire con cura ruoli e permessi |
| Molti lettori e contenuti aziendali | App Power BI e capacità dedicata | Valutare costi, carico e governance |
| Dati riservati per area o responsabile | Modello centralizzato con RLS | Testare identità, relazioni e ruoli |
Non sceglierei una capacità Premium solo perché il progetto “sembra grande”. Prima misurerei il numero di utenti, la frequenza di refresh, la complessità delle query e il livello di concorrenza. In molti casi un modello ben progettato e un workspace Pro risolvono il problema con meno complessità amministrativa.
Il metodo più solido per partire senza complicare il progetto
Per un primo progetto suggerisco di partire da un solo processo aziendale, come vendite o acquisti, e da un modello a stella con una tabella dei fatti e dimensioni separate. Prima di creare decine di grafici, definirei cinque o sei misure DAX essenziali e verificherei i totali direttamente sulla fonte.
La sequenza che trovo più efficace è semplice. Si prepara il modello in Desktop, si pubblica in un workspace di sviluppo, si testa il refresh, si verifica la sicurezza e solo dopo si distribuisce un’app agli utenti finali. Questo riduce il rischio che una modifica tecnica finisca immediatamente davanti a tutta l’organizzazione.
Il vero valore del servizio cloud non sta nel numero di visualizzazioni, ma nella combinazione tra modello affidabile, misure DAX leggibili, aggiornamento controllato e accesso corretto. Quando questi quattro elementi funzionano insieme, Power BI smette di essere una raccolta di grafici e diventa uno strumento concreto per prendere decisioni migliori.
