Quando si accede alle liste SharePoint Online da Power Automate come in questo caso
Get Items
Get 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 lista
Guid 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
SpSiteUrl
SpSiteUrl
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 ListId
Variabile 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 GUID
Resolve 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 name
Workflow 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 Enviroment
Variabile 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 Automate
Enviroment 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.
Tags:
Power Automate28 SharePoint Online75 SharePoint498
Potrebbe interessarti anche: