PowerPlatform Pills #9 - Mocking Power Automate - Il potere dello Static Result

Hai mai dovuto “sporcare” i dati solo per provare una modifica?

Hai mai dovuto creare record fittizi, attivare manualmente un trigger o modificare un campo in produzione solo per verificare che una condizione nel flusso funzionasse come previsto?

Hai mai pensato: “Devo solo sistemare un IF… ma per provarlo devo toccare il dato. E se poi lo rovino?”

Succede più spesso di quanto vorremmo ammettere.
Che tu stia testando un flusso, implementando una nuova logica o, peggio ancora, fixando qualcosa in produzione (non dovrebbe mai accadere… ma capita 😅), il problema è sempre lo stesso:
serve un dato “giusto” per vedere se il flusso si comporta come previsto.

E per ottenerlo, spesso ci ritroviamo a:

• Creare dati ad hoc (che poi vanno cancellati).
• Simulare risposte API con strumenti esterni.
• Fare deploy in ambienti separati solo per “provare”.
• E, nei casi peggiori… testare direttamente in produzione, rischiando di sporcare entità, log e report.

Static Result: la scorciatoia che non ti aspettavi

Lo Static Result è una funzionalità di Power Automate ancora in preview, e sì - potrebbe sparire da un momento all’altro - ma è disponibile dal ’22, quindi dubito sparirà.
Purché tu sappia cosa stai facendo, con lo Static Result puoi mockare il risultato di un’azione all’interno del flusso, senza eseguirla davvero.
In pratica, puoi dire al flusso:

“Fai finta che questa azione abbia restituito questo risultato”
…e vedere come si comporta tutto il resto.

È una scorciatoia elegante che ti permette di:

• Sviluppare più velocemente, senza dover aspettare che ogni azione si esegua davvero.
• Testare condizioni e rami logici senza creare dati fittizi.
• Evitare modifiche indesiderate su ambienti sensibili o in produzione.
• Simulare scenari complessi (es. errori API, output vuoti, risposte condizionali) in pochi clic.

Insomma, anche se è ancora in preview, il suo utilizzo non nuoce al processo di produzione: quindi lo sfrutto a dovere perché permette di lavorare in modo più pulito, più controllato e decisamente più intelligente.

 Come funziona:

Per mostrare il valore reale dello Static Result, ho creato un flusso volutamente semplice — ma sufficiente per capire come funziona e perché può fare la differenza già in fase di sviluppo.

Il flusso parte con un trigger manuale, che riceve un parametro numerico chiamato ID.
Questo ID viene poi utilizzato in un’azione Get items su una lista SharePoint, per cercare un item con quell’identificativo.

🔍 Nota tecnica: per gli screenshot userò volutamente la vecchia esperienza di Power Automate.
Questo mi permette di mostrare, nella stessa schermata, le proprietà di più azioni contemporaneamente — cosa che con la nuova interfaccia non è più possibile.
Se stai usando la nuova esperienza, non preoccuparti: i passaggi sono gli stessi, cambia solo l’aspetto visivo.

Dopo il recupero, ho inserito una condizione IF che verifica se l’item è stato trovato:

• Se sì, esegue una certa azione (1).
• Se no, ne esegue un’altra (2).
  

Il controllo, lo effettuo in modo molto semplice, verificando la lunghezza dell’array restituito dall’azione Get items.
Se la lunghezza è maggiore di 0, significa che almeno un item con quell’ID è stato trovato.

Ecco la formula che uso nella condizione:

Fin qui tutto bene. Ma ora arriva il punto critico: come faccio a sviluppare e testare entrambi i rami della condizione?

Per farlo in modo “tradizionale”, dovrei:

• Creare un item con l’ID desiderato per testare il ramo “vero”.
• Eliminare (o modificare) l’item per testare il ramo “falso”.

In entrambi i casi, sto toccando la base dati SharePoint, anche se sono ancora in fase di sviluppo.
E questo, oltre a essere scomodo, può introdurre errori, sporcare i dati o rallentare il lavoro.

A questo punto… entra in gioco la tecnica dello Static Result che può risultare una soluzione elegante per mockare la risposta dell’azione Get items, evitando di toccare i dati reali.

Ma prima di poter simulare una risposta, dobbiamo capire com’è fatta quella vera.
Per farlo, ho aggiunto un’azione Compose subito dopo il Get items, con questa espressione:  

Ho poi eseguito il flusso con un ID valido, così da ottenere un risultato reale.
Nel run history, il Compose mi mostrerà esattamente come Power Automate struttura l’array degli item: un elenco di oggetti JSON, ciascuno con le proprietà dell’item SharePoint.

Configurare lo Static Result

Ora che ho il formato corretto, posso usarlo per configurare lo Static Result sull’azione Get items.

Ad esempio: Un array vuoto → per testare il ramo “falso”

Dopo la configurazione noteremo un dettaglio che indicherà che la tecnica è attiva sull’Action.

 6. A questo punto, potremo Simulare l’esecuzione: 

Come noterete, una volta configurato lo Static Result, il flusso si comporterà come se SharePoint avesse restituito esattamente ciò che abbiamo simulato.
Nessuna chiamata reale, nessun dato toccato, nessuna attesa.

E il bello è che possiamo ripetere il processo tutte le volte che vogliamo, modificando il JSON per testare scenari diversi, condizioni particolari.

Ora potremo dedicarci allo sviluppo del resto della business del processo 🤓(nel mio scenario i 2 rami della condizione).

In pochi minuti, abbiamo:

• Capito il formato della risposta reale.
• Creato una simulazione controllata.
• Creato scenari per sviluppare entrambi i rami della condizione.
• Evitato di toccare la base dati.

E tutto questo senza uscire dal designer, senza dover creare ambienti di test, e senza sporcare nulla. Una tecnica semplice, ma che può davvero accelerare lo sviluppo, migliorare la qualità del flusso e ridurre il rischio di errori. Insomma, una di quelle scorciatoie che non solo ti fanno risparmiare tempo… ma ti fanno anche sembrare più bravo 😄.

Restate sintonizzati, perché torneremo presto con nuovi consigli e funzionalità pratiche per rendere il nostro sviluppo ancora più efficiente e divertente. Alla prossima! 

Power :) et voilà!!