n8n 2.46: le credenziali personali entrano nei progetti di team
Con la versione 2.46 n8n cambia il modo in cui le credenziali personali si usano nei progetti di team. Ogni esecuzione di un workflow ora agisce a nome di una persona precisa, e può usare solo le credenziali a cui quella persona ha accesso. Se in azienda più colleghi lavorano sugli stessi flussi, questa novità tocca direttamente chi può eseguire, pubblicare e vedere i dati.
Cosa cambia con n8n 2.46
Una credenziale in n8n è il pacchetto di accesso a un servizio esterno: il token di Gmail, la chiave API del gestionale, l’account Slack. Finora, per usare la propria credenziale in un progetto condiviso, bisognava prima condividerla con il progetto. Dalla 2.46.0, rilasciata il 27 ottobre, ogni membro può selezionare le proprie credenziali personali in qualsiasi progetto di team di cui fa parte, senza condividerle.
Il selettore delle credenziali ora le divide in due gruppi. Da una parte quelle disponibili a te, dall’altra quelle disponibili nel progetto. La regola di fondo è semplice. Solo il proprietario della credenziale, e chi l’ha ricevuta in condivisione diretta, può eseguire o pubblicare un workflow che la usa. Gli altri membri vedono il nome della credenziale e del suo proprietario sul nodo, ma trovano disattivati i pulsanti Execute e Publish. Il ruolo nel progetto non scavalca questa regola, e nei progetti di team vale anche per Owner e Admin dell’istanza.
Conta molto anche il concetto di utente che agisce. Un’esecuzione manuale agisce come la persona che preme Execute. Un’esecuzione automatica (da pianificazione, webhook o evento) agisce come chi ha pubblicato il workflow per ultimo. Inoltre n8n nasconde i dati delle esecuzioni che hanno usato una credenziale a cui non hai accesso, compresi quelli restituiti dai sotto workflow. I workflow già pubblicati continuano a girare senza interventi. Un dettaglio da sapere è che gli agenti AI e le integrazioni Slack e Microsoft Teams per ora accettano solo credenziali del progetto, non quelle personali.
Una nota sui tempi. Al momento in cui scrivo la 2.46 è la versione beta, mentre quella stabile è la 2.45.6. Chi aggiorna solo alle versioni stabili la vedrà arrivare nelle prossime settimane, come è successo con il durable scheduler introdotto nella 2.45.
Un esempio da un ufficio logistica
Immagina un’azienda di distribuzione con un progetto n8n chiamato Spedizioni. Dentro c’è un workflow che ogni mattina legge gli ordini dal gestionale, crea le etichette sul portale del corriere e manda un riepilogo al magazzino. Marco, il responsabile logistica, ha collegato il portale del corriere con il suo account personale. Laura, che gestisce il customer care, ogni tanto apre il workflow per lanciarlo a mano quando un cliente sollecita.
Dopo l’aggiornamento Laura vede il nodo del corriere con scritto che la credenziale appartiene a Marco, e non può né eseguire né pubblicare. Non vede nemmeno i dati delle esecuzioni passate che hanno usato quell’account. C’è poi un rischio più sottile. Se Marco ripubblica il workflow, le esecuzioni pianificate agiscono a suo nome. Se un giorno il suo account viene eliminato, il workflow perde il suo publisher e va ripubblicato da qualcun altro. La soluzione pulita è creare la credenziale del corriere dentro il progetto, oppure condividerla con il progetto. Le credenziali del progetto funzionano per tutte le esecuzioni e continuano a lavorare anche se cambiano gli accessi di chi ha pubblicato.
Il mio punto di vista
La direzione è giusta. In molte aziende che seguo le credenziali sono il punto debole delle automazioni. Un collega collega il suo account per fare prima, il flusso va in produzione e nessuno ricorda più a nome di chi gira. Legare ogni esecuzione a una persona e rendere visibile chi possiede cosa porta ordine, e nascondere i dati delle esecuzioni a chi non ha l’accesso è una tutela concreta per la privacy di clienti e fornitori.
I limiti però ci sono. Il primo è pratico. Chi oggi lancia a mano workflow costruiti da altri si troverà dei pulsanti disattivati, e se nessuno lo avvisa la prima reazione sarà pensare a un guasto. Il secondo è organizzativo. La possibilità di usare credenziali personali senza condividerle è comoda, ma rischia di moltiplicare i flussi che dipendono da una sola persona. Per un processo che deve girare tutti i giorni, la credenziale dovrebbe stare nel progetto, non nello spazio personale di qualcuno. Il terzo riguarda gli agenti AI, che per ora restano fuori da questo modello e richiedono comunque credenziali di progetto.
Cosa fare prima di aggiornare
Il mio consiglio è fare un giro di ricognizione prima che la versione diventi stabile. Per ogni progetto di team, apri la scheda Sharing delle credenziali e guarda quali risultano solo in visualizzazione, perché indicano un workflow che dipende dall’account personale di qualcuno. Poi controlla chi ha pubblicato per ultimo i workflow pianificati più importanti e chiediti se quella persona sarà ancora lì tra un anno. Infine avvisa chi esegue i flussi a mano che potrebbe trovare Execute disattivato, e spiega come passare a una credenziale propria. Quanti dei tuoi workflow in produzione girano oggi con l’account di un singolo collega?
Se in azienda più persone lavorano su n8n e vuoi che sappiano gestire progetti, ruoli e credenziali senza bloccarsi a vicenda, scrivimi. Dai un’occhiata ai percorsi di formazione e costruiamo insieme quello adatto al tuo team.