Approvazioni disperse nelle email, file chiamati «finale-definitivo» e documenti approvati rimasti nella cartella sbagliata: molti problemi nascono nel passaggio tra le attività. Un designer visuale di flussi documentali rende espliciti questi passaggi. Il gruppo stabilisce quale evento avvia il processo, quali documenti coinvolgere, chi deve intervenire e dove deve arrivare il file.

Il Workflow Designer di Folderit opera direttamente nel sistema di gestione documentale, accanto ai file, ai permessi e alla cronologia delle versioni. Questa guida spiega il modello di base e propone due configurazioni. Gli esempi illustrano un possibile progetto; non sono resoconti di prove in produzione.

Verifica funzionale del 10 novembre 2026, sulla base dell’articolo inglese del 29 gennaio 2026. Le indicazioni tengono conto dei nomi e delle impostazioni attuali descritti nella documentazione collegata.

Che cos’è un designer di flussi documentali?

È uno strumento per rappresentare processi documentali ricorrenti su un’area di lavoro visuale, collegando eventi, condizioni e azioni. Il passaggio successivo segue regole definite, anziché dipendere dalla memoria di un collega, da un foglio di calcolo o da una lunga catena di messaggi.

Spesso la prima esigenza è ottenere un’approvazione. Tuttavia, si perde tempo anche prima e dopo la decisione: individuare la versione corretta, coinvolgere i responsabili e collocare il risultato nel posto giusto. Un designer collega queste attività. Spetta comunque all’organizzazione scegliere regole adatte al proprio lavoro e assegnare responsabilità precise.

Il modello: evento, condizioni, passaggi, esiti

Evento di avvio → Condizioni → Passaggi → Esiti è una struttura utile per progettare. Scrivete prima il processo in questa forma e poi trasferitelo nell’area visuale.

  • Evento di avvio: che cosa è successo? Per esempio, una nuova versione, lo spostamento di un elemento, una modifica ai metadati o l’aggiunta di un tag o di una condivisione.
  • Condizioni: quali elementi devono entrare nel processo? Precisate cartella, tipo di elemento, nome o valori dei metadati.
  • Passaggi: quale azione deve seguire? Attendere, spostare l’elemento oppure inviare una richiesta formale a persone definite.
  • Esiti: quale percorso corrisponde al risultato osservato? Una condizione vera non equivale a una decisione umana favorevole.

Nel normale passaggio Condition, Success significa che la condizione è vera e Failure che è falsa. Questo secondo esito non indica il rifiuto di un approvatore. Il passaggio Request action dispone invece di uscite proprie per successo, fallimento e scadenza del tempo configurato.

Quattro problemi tipici delle organizzazioni

Confusione tra versioni

Una persona approva una versione precedente mentre un’altra carica una revisione. Oppure viene approvato il file corretto, ma ne viene inviata una copia diversa. La decisione deve riferirsi alla versione effettivamente esaminata. Un nuovo caricamento non eredita automaticamente l’approvazione precedente.

Interruzioni nell’instradamento

Il documento è approvato, ma resta in Bozze, nell’area personale di qualcuno o nella cartella di un altro progetto. Una destinazione definita chiarisce dove prosegue il lavoro e riduce le domande sul suo stato.

Condivisioni poco visibili

Un nuovo accesso o un collegamento a contenuti riservati può passare inosservato. Una richiesta di controllo successiva alla condivisione rende visibile l’evento. Per stabilire l’intervento corretto occorre verificare destinatario e autorizzazioni effettive.

Tracciabilità insufficiente

Chi ha esaminato quale versione, e quando ha deciso? Cronologia delle versioni, informazioni sulle attività e registri di audit aiutano a ricostruire il percorso. Non garantiscono da soli la conformità: occorre valutare anche permessi, procedure e requisiti applicabili.

Come costruire il flusso in Folderit

Aprite Admin tools → Workflows e create un’automazione. Assegnatele un nome comprensibile e verificate lo stato Enabled. Aggiungete almeno uno Starting point con l’evento corretto e condizioni circoscritte. Un punto di avvio con nome può essere eseguito anche manualmente dal menu Workflow di un elemento.

Gli eventi documentati comprendono File version added, Item moved, modifica dei metadati, Tag added, Share added e Request responded. Scegliete quello che corrisponde al passaggio desiderato. La ricezione di una risposta non dimostra che l’intera approvazione sia conclusa.

Le condizioni comprendono tipo, nome, posizione, metadati e Requests completed. Distinguete la cartella stessa dai suoi contenuti. Stabilite se il perimetro include solo quella cartella, tutte le sottocartelle o un numero limitato di livelli. Una regola troppo ampia può produrre molte attività inutili.

Schermata storica del designer di flussi Folderit con interfaccia inglese e passaggi collegati nell’area di lavoro
Schermata originale del designer di flussi, con interfaccia inglese di una versione precedente. I nomi e le impostazioni attuali sono nella documentazione collegata.

I passaggi documentati sono Condition, Delay, Move, Run automation, Send reminder, Wait for event e Request action. La schermata precedente usa ancora Resolution per le attività formali; il nome attuale è Request action.

Questi passaggi permettono di verificare condizioni, attendere, spostare elementi, avviare un’altra automazione salvata e inviare richieste. Non configurano automaticamente calcoli, classificazione dei documenti o scelta dei responsabili per reparto. Tali esigenze richiedono regole e capacità verificate, oppure un’integrazione specifica.

Collegare ciclo di vita e decisioni

Una struttura Bozza → In esame → Approvato → Archiviato può rendere le cartelle un riferimento per lo stato. Funziona solo se permessi, instradamento e decisioni accettate corrispondono a questi passaggi. Spostare un file in «Archiviato» non definisce da solo una conservazione a norma né una cancellazione futura.

In Request action scegliete utenti o gruppi e gestione parallela o sequenziale. Definite se l’attività richiede il completamento da parte di tutti, di un numero specifico o di una percentuale di destinatari. Configurate anche la soglia di rifiuto. Ricevere risposte non significa necessariamente raggiungere un esito positivo.

I metodi comprendono Approval, Acknowledgement, Folderit eSign, DocuSign, eID e Fill fields. Un’attività di revisione può usare un metodo personalizzato; non presumete che «Review» sia disponibile in modo identico in ogni account. Verificate disponibilità e configurazione dei metodi di firma.

Due By indica una scadenza informativa. Il parametro esplicito Timeout determina il limite temporale; il valore 0 significa assenza di timeout. Il solo superamento della data visualizzata non garantisce un’escalation. Concordate anche chi deve prendere in carico una pratica senza risposta.

Esempio 1: approvare contratti e instradare il risultato

Immaginate nuove versioni nella cartella «Contratti/In esame». Conservate due fasi operative: ottenere l’approvazione e poi instradare secondo l’esito. Un unico flusso visuale può collegarle chiaramente:

  1. Impostate File version added con condizione di tipo file e posizione limitata alla cartella di esame.
  2. Aggiungete Request action con Approval. Indicate persone dell’ufficio legale, dell’amministrazione finanziaria e della direzione. Qui i partecipanti sono scelti esplicitamente, non selezionati automaticamente dai metadati.
  3. Richiedete, per esempio, l’approvazione di tutti e tre e configurate il fallimento dopo un rifiuto. Verificate insieme le regole di completamento e di rifiuto.
  4. Collegate Success → Move ad «Approvato», Failure → Move a «Da correggere» e Timeout → Move a «Escalation».

Nell’ultimo caso, un responsabile valuta il passo successivo. È possibile separare l’instradamento in un’automazione successiva, purché le condizioni confermino completamento ed esito corretti. Non basta Request responded: l’evento può riferirsi a una sola risposta.

Provate il caricamento di una nuova versione durante una richiesta in sospeso. Evitate richieste duplicate e decidete come gestire l’esame precedente. La nuova versione necessita della decisione prevista per essa; l’approvazione della precedente non basta.

Esempio 2: verificare condivisioni in aree riservate

Un altro scenario usa Share added, limitato alla posizione e al tipo di elemento previsti. Il flusso invia una richiesta a un responsabile della sicurezza identificato. Utilizzate un metodo di revisione personalizzato, se configurato, oppure Approval.

Il responsabile controlla destinatario, collegamento e autorizzazioni reali. L’automazione reagisce dopo la creazione della condivisione. Non è un blocco preventivo degli accessi esterni, un classificatore automatico dei destinatari o una revoca automatica. Anche lo spostamento del file non dimostra che un collegamento sia disattivato. Le correzioni devono riguardare i controlli effettivi di condivisione e accesso.

Includete nelle prove una condivisione consentita e un evento fuori dall’area monitorata. Verificherete così se il controllo rispetta il perimetro concordato.

Tre errori da evitare

  • Un perimetro troppo ampio: iniziate da una cartella, un tipo di elemento e un evento necessario. Troppe richieste riducono l’attenzione.
  • Una sola regola per ogni esigenza: distinguete richiesta e instradamento dopo la decisione. Rami chiari possono bastare; automazioni separate richiedono condizioni di completamento rigorose.
  • Trascurare la destinazione: definite cartelle e permessi prima dell’attivazione. Una decisione corretta non risolve un archivio difficile da consultare.

Verifiche prima dell’utilizzo

Usate file dimostrativi riconoscibili e avvisate i partecipanti. Provate una nuova versione nel perimetro, un elemento escluso, approvazione, rifiuto, mancata risposta con timeout, nuova versione durante l’esame e indisponibilità di un revisore. Controllate attività, versione, risultato e cartella finale in ogni caso. Concordate un responsabile umano per l’escalation.

Tre domande per iniziare

Il designer serve solo alle approvazioni?

No. Anche instradamento, ciclo di vita e reazioni mirate alle modifiche sono impieghi utili. Cercate il passaggio che oggi genera errori o ritardi.

Servono competenze tecniche?

Occorre soprattutto concordare ruoli e regole. La rappresentazione visuale semplifica la costruzione, ma non sostituisce la configurazione accurata e la verifica degli esiti.

Da quale processo partire?

Scegliete un caso ricorrente: contratti, conferma di lettura delle policy, archiviazione dopo una decisione o controllo delle condivisioni. Descrivetelo come evento, condizioni, passaggi ed esiti.

Consultate la guida al Workflow Designer per le impostazioni attuali e la panoramica dei flussi documentali per i metodi. Prima della configurazione, verificate le funzionalità del piano attuale e le opzioni di firma dell’account.