.svg)
La serie “PowerPlatform Pills” di 4wardPRO è dedicata alla piattaforma Power Platform, progettata per fornire soluzioni intelligenti e flessibili per affrontare le sfide aziendali.
In questa serie, esploreremo diverse funzionalità e tecniche avanzate per massimizzare il potenziale di Power Platform.
La Power Platform di Microsoft offre un ecosistema integrato di strumenti, tra cui Power Apps, Power Automate e Power BI, progettati per semplificare e potenziare la creazione di soluzioni aziendali personalizzate.
“PowerPlatform Pills” è stata pensata per fornire approfondimenti dettagliati e una guida pratica su argomenti chiave, dedicati a un pubblico di sviluppatori, con differenti livelli di esperienza nella piattaforma.
Il primo articolo della serie "Child Flow" è disponibile qui. Il secondo, "How to debug", è disponibile qui.
Con questo terzo articolo, preparati a esplorare le profondità della Power Platform con noi, arricchendo le tue competenze e scoprendo nuovi modi per ottimizzare i processi di sviluppo.
In questo articolo, mostro come delegare le attività di un flow a un account di servizio con privilegi di scrittura, invece che all’utente che ha avviato il flow. Questa funzionalità può essere utile per semplificare i processi e risolvere i problemi di permessi.
Quando si esegue un flow da un'applicazione Power App, la "chiamata" viene solitamente "trattata" come manuale, quindi, il flow si avvale della connessione dell'utente che ha aperto l'App. Questa modalità è utile in molte situazioni, ma in altre... potrebbe essere restrittiva.
Use case
Poniamo l'esempio che l'user in sessione sia un utente con privilegi di sola lettura sul db, ma nel flow abbia l'esigenza di scrivere o modificare un dato su una tabella (master). Nel mio scenario, la richiesta di un task da parte dell'utente(reader) deve passare allo stato di "approvata".
Bhe in questo scenario la scrittura e il flow vi falliranno perché non avrete i privilegi adeguati a eseguire l'aggiornamento sulla master table. In questa situazione, la scrittura e il flusso non funzioneranno perché non avrete i permessi necessari per fare l'aggiornamento sulla tabella principale.
La soluzione più utilizzata (A) è la creazione di un ruolo apposito da assegnare alle utenze che richiedono questa "speciale autorizzazione"; dal punto di vista stilistico è corretto, ma in ogni caso avrai un permesso di scrittura che servirà solo in situazioni eccezionali... a me personalmente non piace molto.
In alternativa, esiste una soluzione (B) che utilizza il trigger V2 di PowerApps:
Nel menu "Details" del flow si attiverà una funzionalità interessante che permette di indicare sui vari connettori del flusso, con quale utenza "eseguire" quel connettore specifico. Questa attività è applicabile dal menu "Run Only user":
E attiverà una sezione di configurazione delle connessioni in uso, sulle quali applicare una delega:
A questo punto, sul connettore che "scrive" sul db, basterà impostare l'esecuzione con l' account di servizio (con gli opportuni privilegi RW), invece che con quello che ha avviato la procedura.
