Environment variables e connection references

Quando una solution passa da un ambiente all’altro (dev → test → prod), alcuni valori devono cambiare senza toccare i componenti. Le environment variables e le connection references sono i due meccanismi che rendono questo passaggio ripetibile, automatizzabile e privo di rework manuale.

Environment variables

Una environment variable è un componente della solution che rappresenta un valore configurabile per ogni ambiente. Invece di scrivere in modo fisso un URL, una chiave, il nome di un sito SharePoint o un flag di comportamento dentro un flow, un’app o una business rule, si fa riferimento alla variabile: il valore concreto viene fornito ambiente per ambiente.

Ogni environment variable è composta da due parti distinte:

• Definition: il metadata (schema name, tipo, descrizione, default value). Viaggia SEMPRE dentro la solution.
• Current value: il valore effettivo per quell’ambiente specifico. È un dato separato dalla definition.

I tipi supportati includono Text, Number, Boolean, Decimal, JSON, Data source e Secret (quest’ultimo con integrazione Azure Key Vault per credenziali e chiavi sensibili, che non vanno mai messe in chiaro come default value).

Come gestire i valori tra ambienti

Il pattern corretto per un deployment pulito:

• In dev definisci la variabile e, se serve, un default value generico.
• NON esportare i current value di dev in una managed solution destinata a prod: il current value verrebbe portato con sé e sovrascriverebbe la configurazione di destinazione.
• In test/prod imposti il current value tramite il Power Platform admin center, una deployment pipeline o Azure DevOps con override automatici.

Se una variabile non ha né current value né default value in un ambiente, i componenti che la usano falliscono a runtime: è un errore di configurazione classico.

Connection references

Una connection reference è un componente della solution che fa da livello di indirezione tra un cloud flow (o un connettore usato da un’app) e la connection concreta che contiene le credenziali. Il flow punta alla connection reference, non direttamente alla connection.

Questo separa la logica (il flow, che sta nella solution) dalle credenziali (la connection, che è un dato per-ambiente e per-utente e NON è un componente della solution). Il beneficio pratico: lo stesso flow importato in test o prod si aggancia alla connection valida per quell’ambiente senza essere riscritto.

Deployment e mapping

• La connection reference viaggia dentro la solution; la connection no.
• All’import di una managed solution in un nuovo ambiente devi mappare ogni connection reference a una connection esistente (o crearla). Con le pipelines o Azure DevOps questo mapping si automatizza.
• Best practice: una connection reference per connettore, riusata da tutti i flow che usano quel connettore, invece di crearne una nuova per ogni flow.

Perché insieme rendono i deployment ripetibili

Con environment variables e connection references, la solution diventa portabile: contiene solo la logica e i puntatori, mentre i valori specifici (endpoint, chiavi, credenziali) vivono fuori e si iniettano per ambiente. Il risultato è un ciclo dev-test-prod automatizzabile con pipelines, senza aprire manualmente ogni flow per riconfigurarlo.

Trappole tipiche d’esame

• Scenario: un cloud flow con la connessione impostata direttamente (hardcoded) viene importato in un nuovo tenant e si rompe / va riconfigurato a mano ogni volta. → La risposta corretta è usare una connection reference, così il flow si riaggancia alla connection dell’ambiente di destinazione senza modifiche.
• Scenario: l’URL di un servizio o il nome di un sito SharePoint cambia tra dev e prod. → Usa una environment variable, non modificare i componenti della solution.
• Scenario: dopo l’import in prod, il current value continua a puntare a dev. → Non esportare i current value di dev in una managed solution; imposta il valore in prod (admin center / pipeline). Porta solo la definition e, se opportuno, il default value.
• Scenario: serve memorizzare una API key o una password come environment variable. → Usa il tipo Secret integrato con Azure Key Vault; mai in chiaro come default value.
• Scenario: una environment variable non ha valore nell’ambiente di destinazione. → Il componente che la referenzia fallisce a runtime; assicurati che esista un current value o un default value.