In Power Platform ogni risorsa — app, flow, tabelle Dataverse, chatbot, connessioni — vive dentro un environment. Come functional consultant devi saper scegliere il tipo di environment giusto per ogni fase del progetto e conoscere come amministrarlo dal Power Platform admin center (PPAC). L’environment è anche il confine di sicurezza e di governance: definisce chi accede ai dati, quale regione ospita il Dataverse e quali connettori sono ammessi.

Tipi di environment

Ogni environment ha un type che ne determina scopo e comportamento:

  • Default: creato automaticamente con il tenant, uno solo, condiviso da tutti gli utenti licenziati. Comodo per prototipi personali, ma non adatto alla produzione perché non isolabile e non ripristinabile facilmente.
  • Production: l’ambiente “vero” per i carichi live. Richiede capacità Dataverse e va protetto con security role e DLP.
  • Sandbox: ambiente non produttivo per sviluppo e test. Supporta operazioni tipiche di ALM come Copy, Reset e Restore (ripristino a un punto nel tempo), quindi è la scelta ideale per Dev/Test prima del deploy in Production.
  • Developer: legato a un singolo utente (Power Apps Developer Plan), gratuito, con Dataverse incluso ma non condivisibile con il team. Serve per apprendere e sperimentare.
  • Trial: temporaneo, scade tipicamente dopo circa 30 giorni; utile per PoC a breve termine.

Un environment con Dataverse abilita tabelle, business rule, security role e solution; senza Dataverse ospita solo canvas app e flow “leggeri”.

Ciclo di vita e admin center

Dal Power Platform admin center l’amministratore crea, gestisce e dismette gli environment. Alla creazione scegli regione, type, se aggiungere il Dataverse database e la security group che ne limita l’accesso. Le operazioni chiave del ciclo di vita:

  • Copy: duplica un environment (es. da Production a Sandbox) per test realistici.
  • Reset: azzera un Sandbox riportandolo pulito.
  • Backup/Restore: ripristino point-in-time (solo Sandbox e Production).
  • Delete e Recover: gli ambienti eliminati restano recuperabili per un periodo di grazia.

Environment settings

Nelle environment settings configuri elementi funzionali come: features e behavior, business closures e calendario, auditing, email/mailbox, formati di data/valuta, e le security role. Qui abiliti anche funzionalità come Copilot per app e agenti quando previsto dallo scenario.

Licensing (livello concettuale)

Le licenze Power Platform seguono modelli che devi saper distinguere:

  • Per-user (Power Apps Premium): l’utente può eseguire un numero illimitato di app e usa premium connectors e Dataverse. Adatto a utenti che lavorano su molte app.
  • Per-app: consente l’accesso a un set limitato di app per utente/mese. Conviene quando gli utenti usano una o due app specifiche.
  • Pay-as-you-go: collegato a una Azure subscription, si paga a consumo mensile per utente attivo per app, senza acquistare licenze anticipate. Ottimo per adozione variabile o incerta.
  • Power Automate: licenze per-user e per-flow (capacità dedicata a un processo, indipendente dagli utenti).

I connettori sono classificati standard vs premium: usare un premium connector (incluso Dataverse) richiede una licenza premium o pay-as-you-go.

DLP policy e governance

Le Data Loss Prevention (DLP) policy si definiscono nel PPAC (o via Power Platform for admins) e classificano i connettori in Business, Non-Business e Blocked. Connettori in gruppi diversi non possono coesistere nella stessa app o flow, impedendo che dati aziendali fluiscano verso servizi non approvati. Le policy si applicano a livello di tenant o di environment specifici, e sono lo strumento primario per prevenire esfiltrazione di dati.

Trappole tipiche d’esame

  • Scenario: un reparto vuole distribuire in produzione un’app usata da centinaia di utenti → Risposta: creare un environment Production dedicato con Dataverse, non usare il Default (condiviso da tutto il tenant e non isolabile).
  • Scenario: servono test con ripristino a un istante precedente e possibilità di azzerare l’ambiente → Risposta: usare un Sandbox (supporta Reset e Restore), non un Production.
  • Scenario: utenti che usano solo una specifica app e vuoi minimizzare i costi → Risposta: licenza per-app; se il numero di utenti è imprevedibile, valuta pay-as-you-go.
  • Scenario: impedire che un flow invii dati Dataverse a Twitter/servizi social → Risposta: una DLP policy che colloca i connettori in gruppi Business/Non-Business separati (o blocca quello social).
  • Scenario: un’app richiede un premium connector ma gli utenti hanno solo licenze Microsoft 365 → Risposta: serve una licenza Power Apps Premium/per-app o pay-as-you-go; i connettori premium non sono coperti dalle licenze standard.