Quando si accede alle liste SharePoint Online da Power Automate come in questo caso
Get ItemsGet Items
ovvero si seleziona il sito a cui accedere e la lista, in realtà Power Automate non salva il nome della lista, ma salva il GUID.

Infatti esportando il flow e guardando all'interno dello zip si può vedere che effettivamente viene salvato solo il GUID, attributo table
Guid della listaGuid della lista

Questo impedisce di il porting, in modo semplice, di un flow Power Automate da un sito di DEV ad uno di produzione, in quanto non è possibile definire il GUID della lista, viene assegnato in modo automatico da SharePoint.

Il passaggio è possibile solo reimportando il flow con un altro nome e poi cambiando i riferimenti alle liste a mano, ovviamente più aumentano le action di tipo SharePoint più la cosa si complica e soggetta ad errori.
Inoltre quando si aggiorna un flow esistente in PROD, si fa disservizio finché non si finisce di aggiornare i riferimenti alle liste.

In alternativa si può usare uno script PowerShell come Come spostare un flow con connessioni SharePoint.

Soluzione

Un soluzione alternativa è cercare di rendere il flow Power Automate nativamente adattabile ai due ambienti di DEV e PROD.
In realtà in SharePoint Online non esiste un concetto di ambiente di DEV o PROD, l'ambiente è unico.
Si può cercare di simulare un concetto di ambiente creando due site collection, una dedicata agli sviluppi di DEV e una dedicata a PROD.

Variabili

La prima cosa da fare è rendere dinamica la url del sito definendo una variabile (SpSiteUrl) per contenere l'indirizzo
SpSiteUrlSpSiteUrl
questo rende veloce il cambiare la url dal sito di DEV a quello di PROD, soprettutto se si hanno decine di action SharePoint.
In questo caso, tutto funziona regolarmente, ma la lista non viene più risolta con il nome, viene visualizzato solo il GUID.
Ovviamente in questa situazione il nome della lista non è molto parlante, quindi va risolto il problema.

Si può definire una nuova variabile (TodoListId) con nome parlante che conterrà il GUID della lista.
Variabile ListIdVariabile ListId
In questo modo il flow è chiaro a chiunque debba fare manutenzione.

Risolvere il nome della lista

Comunque anche così non è molto pratico, quando si fa il passaggio in produzione va comunque cambiata la variabile ListId.
Inoltre più liste vengono usate nel flow più variabili devono essere aggiornate ad ogni passaggio in PROD.

Meglio trovare un modo più pratico.
Il trucco è riferirsi alla lista con il nome interno, lasciando a Power Automate il compito di trovare il corretto GUID in base al sito.

Per far questo usiamo l'action Send an HTTP request to SharePoint, che usiamo per cercare la lista per nome interno (EntityTypeName ) in modo da trovare il relativo GUID (Id).
Resolve GUIDResolve GUID
Viene genera un eccezione nel caso in cui il nome di lista non viene trovato.
Nella action inseriamo la url
URL
_api/web/lists?$filter=EntityTypeName eq 'TodoListList'&$select=Id,EntityTypeName
nel caso di più liste i nomi interni vanno messi in OR
URL
_api/web/lists?$filter=EntityTypeName eq 'TodoListList' or EntityTypeName eq 'OtherName'&$select=Id,EntityTypeName
e tramite l'action Apply to each e Switch si assegna il valore alla variabile corretta.
Nel mio caso la lista aveva nome TodoList.
Essendo una lista, SharePoint aggiunge il suffisso List, è per questo che nel mio caso il nome interno è TodoListList con List duplicato.

Di seguito si potrà fare riferimento alle liste tramite le rispettive variabili.
Cambiando solo la variabile SpSiteUrl il flow si adatta all'ambiente anche se i GUID delle liste cambiano, l'importante è che rimangano invariati i nomi interni (Url / EntityTypeName).
Per trovare il valore di EntityTypeName immettere nel bowser questa url
URL
https://tenant.sharepoint.come/sites/nomeSito/_api/web/lists?$select=Id,EntityTypeName
Questo è un esempio di JSON ritornato
JSON
{
  "value": [
    {
      "EntityTypeName": "TodoListList",
      "Id": "82832c39-xxxx-xxxx-xxxx-6c2f26dc7909"
    },
    {
      "EntityTypeName": "TodoListCategoriesList",
      "Id": "023e9490-xxxx-xxxx-xxxx-37841185eb0e"
    }
  ]
}

Rendere dinamica la url del sito

E' possibile fare un ulteriore passaggio, rendere dinamica anche la variabile SpSiteUrl.

Ovviamente serve un criterio, ad esempio ci si può basare sul nome del flow per cambiare la url.
Supponiamo che il flow si chiami Test Flow in PROD, mentre in DEV useremo il prefisso DEV - , quindi il nome diventerà DEV - Test Flow.

Il nome del flow lo si può ricavare tramite l'espressione
Power Automate: Flow display name
workflow()['tags/flowDisplayName']
Workflow display nameWorkflow display name

A questo punto verificando se il nome inizia per DEV - possiamo impostare una variabile Enviroment con la stringa DEV oppure PROD
Power Automate: Variabile Enviroment
if(equals(indexOf(variables('WorkflowDisplayName'),'DEV -'), 0), 'DEV', 'PROD')
Variabile EnviromentVariabile Enviroment
Ora con questa variabile possiamo impostare la url del sito nella variabile SpSiteUrl
Power Automate: Variabile SpsiteUrl dinamica
if(equals(variables('Enviroment'), 'PROD'), 'https://tenantName.sharepoint.com', 'https://tenantName.sharepoint.com/sites/dev')
E con questo il flow è completo e si adatta all'ambiente solo tramite il nome del workflow.

Quindi si può esportare un flow da DEV, reimportarlo con il nuovo nome in PROD e tutto funziona, ma...

C'è ancora una miglioria da apportare, controllare il prefisso DEV - nel nome è pratico, veloce e adattabile a qualunque flow, ma un banale errore di sintassi potrebbe, erroneamente, far lavorare il flow in produzione con conseguenze imprevedibili.

Molto meglio rafforzare il test della variabile Enviroment controllando esattamente il nome del flow di produzione, in questo modo eventuali errori di sintassi non fanno danni in quanto il flow punterà sempre a DEV.
Power Automate: Variabile Enviroment test con nome esatto
if(equals(variables('WorkflowDisplayName'),'Test Try Catch'), 'PROD', 'DEV')

Trigger

Volendo, inn caso di trigger su una lista SharePoint, la url del sito la si può ricavare dai parametri di input
tramite la formula
Power Apps
trigger()?['inputs']?['parameters']?['dataset']

Conclusione

Con queste pre-impostazioni qualunque flow Power Automate con action SharePoint Online può essere spostato da una site collection ad un altra (DEV to PROD) senza nessun intervento dell'utente se non l'azione di export e import con rename.

Nota

Il metodo esposto funziona bene in caso in cui il tenant ha un unico ambiente (Enviroment) Power Automate ovvero quello di Default
Enviroment Power AutomateEnviroment Power Automate
Nel caso in cui si ha un ambiente dedicato per la produzione, la soluzione migliore è creare i flow all'interno di una solution Power Automate ed esportare e importare la solution.

In questo caso lo scenario cambia, anziché definire all'interno di ogni singolo flow un variabile per ogni lista, e leggere i valori dinamicamente, si posso usare le variabili a livello di ambiente.
Queste variabile possono essere impostate la prima volta che si importa la solution nel nuovo ambiente e mantengono i valori anche in caso di update.
Con le solution bisognerà fare attenzione a usare solo connection reference definite all'interno, sempre impostabili durante il primo import nel nuovo ambiente.
Potrebbe interessarti anche: