La fase di deploy & maintain riguarda come portare un contenuto Power BI dal lavoro dell’analista fino agli utenti finali in modo controllato, riutilizzabile e governato. In Power BI Service questo si traduce in tre strumenti chiave: deployment pipeline, dataflow e le funzionalità di governance (endorsement, sensitivity label, lineage view), oggi collocati dentro l’ecosistema Microsoft Fabric.

Deployment pipeline

Una deployment pipeline collega tre workspace in altrettanti stage: Development, Test e Production. Ogni stage ospita una copia del contenuto (semantic model, report, dashboard, dataflow) e il deploy da uno stage al successivo è incrementale: alla prima pubblicazione l’intero contenuto viene copiato, poi solo le differenze.

Il punto d’esame più delicato sono le deployment rules, che si configurano per stage e permettono di sostituire configurazioni senza modificare manualmente il file. Le più usate:

  • Data source rules: cambiano l’origine dati passando da uno stage all’altro (es. il database dev-sql in Development diventa prod-sql in Production).
  • Parameter rules: cambiano il valore di parametri già definiti nel semantic model.

Le regole si applicano allo stage di destinazione e agiscono al momento del deploy: quando promuovi verso Production, il modello punta automaticamente alle sorgenti corrette. Requisiti importanti: le deployment rules valgono solo per semantic model e dataflow, non per i report; le regole restano configurate anche dopo il deploy e vanno impostate una volta, non a ogni pubblicazione.

Dataflow: preparazione dati riutilizzabile

Un dataflow è un layer di ETL lato Service basato su Power Query Online. Serve a centralizzare la preparazione dati: si definiscono le trasformazioni una volta e più semantic model/report vi si connettono, evitando di ripetere la stessa logica in ogni file .pbix.

Quando scegliere un dataflow rispetto a Power Query dentro Power BI Desktop:

  • Riuso: la stessa tabella pulita serve a più team o più report.
  • Separazione dei ruoli: chi prepara i dati non è chi costruisce i report.
  • Refresh centralizzato e riduzione del carico sulle sorgenti.

I dataflow scrivono l’output in storage (in Fabric, su OneLake) e possono essere referenziati come sorgente. Attenzione: un dataflow non è un semantic model, non contiene misure DAX né relazioni — è solo il livello di staging/trasformazione a monte.

Governance: endorsement, sensitivity label, lineage

  • Endorsement: marca la qualità di un asset. Promoted indica contenuto che l’autore ritiene affidabile e pronto all’uso; Certified è un livello superiore assegnato solo da utenti autorizzati dall’amministratore, secondo un processo formale. Certified segnala “single source of truth” ufficiale.
  • Sensitivity label (da Microsoft Purview): applicano classificazione e protezione persistente (crittografia, restrizioni). La label segue il dato anche nell’export verso Excel, PowerPoint e PDF — protezione che l’endorsement non offre.
  • Lineage view: mostra graficamente il flusso end-to-end (origine dati → dataflow → semantic model → report → dashboard), fondamentale per impact analysis prima di modificare o rimuovere una sorgente.

Power BI dentro Microsoft Fabric

Nel 2026 i workspace Power BI vivono in Microsoft Fabric. Il livello di storage unificato è OneLake, un unico data lake organizzativo dove convergono dataflow, lakehouse e semantic model. Concetti chiave da riconoscere:

  • Il Fabric workspace è l’unità di collaborazione e di associazione alla capacity.
  • I Fabric-enabled workspace possono usare artefatti Fabric (lakehouse, warehouse, pipeline) accanto ai contenuti Power BI classici.
  • Le sensitivity label e il lineage si estendono agli asset Fabric, mantenendo governance coerente su tutto OneLake.

Trappole tipiche d’esame

  • Cambiare il database tra Test e Production senza toccare il file → configura una data source deployment rule sullo stage di Production (non modificare manualmente il semantic model).
  • Serve la “fonte ufficiale” approvata dall’IT → Certified endorsement (Promoted è auto-dichiarato e non richiede autorizzazione).
  • Il dato deve restare protetto anche dopo l’export in Excel → sensitivity label di Microsoft Purview, non l’endorsement.
  • Stessa logica di pulizia dati usata da più report/team → costruisci un dataflow riutilizzabile, non ripetere le query in ogni .pbix.
  • Valutare l’impatto della rimozione di una sorgente → usa la lineage view per l’impact analysis prima di procedere.