Le solution sono il meccanismo con cui Power Platform impacchetta, versiona e trasporta le personalizzazioni (tabelle Dataverse, app, flow, ruoli di sicurezza) tra ambienti — tipicamente da dev a test a produzione. Come functional consultant devi sapere quando usare il tipo giusto e come impostare correttamente il contenitore fin dall’inizio, perché scelte sbagliate qui si trascinano per tutto il ciclo di ALM (Application Lifecycle Management).
Unmanaged vs managed
Una solution unmanaged è un contenitore di sviluppo: i suoi componenti sono modificabili direttamente nell’ambiente. Le modifiche che fai nel maker portal vengono scritte “live” sui componenti sottostanti. Una unmanaged è quindi lo stato di lavoro sorgente, non un pacchetto pensato per la produzione.
Una managed solution è invece un pacchetto di distribuzione bloccato: viene generata esportando una unmanaged come managed, e una volta importata nell’ambiente di destinazione i suoi componenti non sono direttamente modificabili. Le personalizzazioni sopra un componente managed sono possibili solo dove il produttore ha lasciato proprietà customizable e avvengono come layer (managed layer) sopra il componente originale.
Regola pratica per l’esame: si sviluppa in unmanaged, si distribuisce in managed. Gli ambienti di produzione dovrebbero contenere solo managed solution, così che ogni ambiente resti pulito, versionato e ripristinabile.
Publisher e customization prefix
Ogni solution è associata a un publisher. Il publisher definisce due cose importanti:
- il customization prefix (es.
contoso_), che viene anteposto ai nomi logici (schema name) dei componenti creati — tabelle, colonne, choice — dando riconoscibilità e prevenendo collisioni con altri produttori; - l’option value prefix, che determina il range numerico assegnato ai valori delle choice (Option Set).
Il prefix va deciso prima di creare componenti, perché lo schema name non è modificabile dopo. Usare un publisher dedicato (non il Default Publisher di Microsoft) è una best practice attesa: identifica chiaramente chi possiede le customizzazioni.
Solution component e il Default solution
Una solution component è qualsiasi elemento tracciabile: tabelle, colonne, relazioni, model-driven/canvas app, cloud flow, ruoli di sicurezza, dashboard, choice globali. Puoi aggiungere componenti “esistenti” o crearne di nuovi dentro la solution.
Il punto chiave: non si sviluppa mai nella Default solution. La Default solution è una vista aggregata di tutti i componenti unmanaged dell’ambiente; modificare lì significa non poter esportare in modo pulito e selettivo, non applicare il tuo prefix, e non avere versionamento. Il flusso corretto è: dal maker portal creare una solution unmanaged dedicata con il proprio publisher, e lavorare esclusivamente al suo interno.
Cancellare una managed solution
Ecco la trappola più insidiosa. Disinstallare (eliminare) una managed solution rimuove i componenti che essa ha introdotto — e se elimini una managed che ha creato tabelle, cancelli anche i dati (record) contenuti in quelle tabelle. La rimozione è distruttiva e non è un semplice “scollegamento”: è come una disinstallazione software.
Al contrario, eliminare una unmanaged solution rimuove solo il contenitore: i componenti restano nell’ambiente (rimangono nella Default solution). Questa asimmetria è deliberatamente oggetto di domande d’esame.
Trappole tipiche d’esame
- Scenario: hai personalizzato direttamente la Default solution e ora devi spostare tutto in produzione. → Risposta giusta: crea una solution unmanaged dedicata con publisher e prefix propri, aggiungi i componenti, poi esporta come managed. Non esportare la Default solution.
- Scenario: devi rimuovere una feature (con le sue tabelle) da produzione senza perdere i dati aziendali. → Attenzione: eliminare la managed solution cancella tabelle e record correlati. Se i dati servono, esportali/valuta un percorso alternativo prima della disinstallazione.
- Scenario: gli schema name dei nuovi campi appaiono con prefix
new_. → Stai usando il Default Publisher. Crea un publisher dedicato con il customization prefix corretto prima di generare i componenti — lo schema name non si cambia dopo. - Scenario: in produzione un componente managed non è modificabile. → Comportamento atteso: le managed sono bloccate. Modifica nel dev (unmanaged), rigenera la managed e reimporta con una nuova versione; non cercare di editare direttamente in produzione.
- Scenario: quale tipo di solution deve contenere un ambiente di produzione? → Solo managed. Gli ambienti unmanaged sono riservati allo sviluppo.