Workflow

I workflow trasformano una colonna Status in un motore di processo strutturato. Invece di lasciare che chiunque cambi liberamente lo status di una riga in qualsiasi momento, definisci esattamente quali transizioni sono consentite, chi può attivarle, quali condizioni devono essere soddisfatte e cosa succede automaticamente dopo che una transizione è completata. Questo rende i boards Copera paragonabili a strumenti di processo dedicati come Jira o ServiceNow — integrati direttamente nel tuo spazio di lavoro.

Abilitare un workflow

I workflow si configurano individualmente per colonna Status. Per abilitarne uno:

1. Apri il board e vai alla tabella che contiene la colonna Status che vuoi controllare.
2. Fai clic sull'intestazione della colonna per aprire le impostazioni della colonna.
3. Attiva lo switch Workflow.
4. Compare l'editor visuale del workflow — una canvas che mostra ogni status come nodo e ogni transizione consentita come freccia diretta tra i nodi.
5. Imposta un Initial Status — lo status con cui partono le nuove righe quando vengono create.

suggerimento

Quando attivi per la prima volta la modalità workflow, Copera offre modelli predefiniti per processi comuni come Software Development (Backlog → In Progress → Code Review → QA → Done), IT Service Desk, HR Onboarding e Content Approval. Applicare un modello popola status e transizioni per te, dandoti un solido punto di partenza da personalizzare.

Transizioni di status

Una transizione definisce un percorso consentito tra due status. Senza una transizione definita, il cambio di status è bloccato.

Transizioni con nome

Ogni transizione può avere un nome visualizzato che compare nell'interfaccia quando gli utenti scelgono cosa fare dopo — ad esempio, "Start Review," "Approve," o "Send Back for Revisions." Nomi chiari aiutano i membri del team a capire cosa significa ogni azione nel contesto del processo.

Transizioni specifiche

Una transizione specifica collega un particolare status a un altro. Le disegni sull'editor visuale trascinando da un nodo status a un altro. Ad esempio, collegare "To Do" direttamente a "In Review" crea una transizione che consente solo quel percorso.

Transizioni globali

Una transizione globale origina da qualsiasi status e va a un target specifico. Sono utili per azioni che possono sempre accadere indipendentemente da dove si trova una riga nel processo — ad esempio, una transizione "Cancel" che sposta la riga a "Cancelled" da ovunque si trovi, o una transizione "Escalate" che funziona in qualsiasi fase.

Toggle "From Any Status"

Puoi convertire qualsiasi transizione specifica in una globale direttamente dall'editor visuale. Quando fai clic su un bordo di transizione e apri il pannello laterale, spunta la checkbox "From any status". Questo imposta la sorgente su "Any Status" e il bordo diventa tratteggiato, indicando visivamente che la transizione è raggiungibile da tutti gli status. Togli la spunta per ripristinare lo status di origine specifico originale.

È particolarmente utile quando durante la progettazione del workflow ti rendi conto che una transizione come "Cancel" o "Close" dovrebbe essere disponibile da ogni fase — non devi disegnare manualmente bordi individuali da ogni status.

nota

Gli utenti possono sempre cancellare un valore di status (impostarlo a vuoto) indipendentemente dalle regole del workflow. È intenzionale: cancellare uno status non conta come transizione e non viene mai bloccato.

Se la riga non ha ancora uno status corrente (prima assegnazione dopo la creazione), qualsiasi status consentito può essere impostato liberamente. La validazione del workflow si applica solo quando si passa da uno status definito a un altro.

Condizioni — Chi può eseguire una transizione

Le condizioni controllano quali utenti possono attivare una data transizione. Tutte le condizioni su una singola transizione usano logica AND — l'utente deve soddisfare ogni condizione elencata.

Tipo di condizione	Descrizione
Role	L'utente deve avere uno dei ruoli board specificati.
User	L'utente deve essere in un elenco specifico di persone nominate.
Team	L'utente deve appartenere a uno dei team specificati nello spazio di lavoro.
Row Owner	Solo l'utente che ha creato la riga può attivare questa transizione.
Assignee	Solo gli utenti attualmente assegnati alla riga (in una colonna Users) possono attivarla.

nota

Gli admin del board aggirano i controlli sulle condizioni — possono attivare qualsiasi transizione indipendentemente dalle condizioni. Tuttavia, gli admin non sono esenti dai validator. I requisiti sui dati valgono per tutti.

Validator — Cosa deve essere vero

I validator verificano se i dati della riga soddisfano i requisiti prima che la transizione possa procedere. A differenza delle condizioni, i validator sono applicati a tutti gli utenti, inclusi gli admin.

Tipo di validator	Descrizione
Field Required / Field Not Empty	Una colonna specificata deve avere un valore. Se è vuota, la transizione è bloccata.
Field Matches	Il valore della colonna deve corrispondere a un pattern che definisci. Utile per imporre formati come numeri di riferimento o codici.

Ogni validator può mostrare un messaggio di errore personalizzato così gli utenti sanno esattamente cosa devono compilare prima che la transizione possa procedere.

Campi obbligatori

Oltre ai validator (che controllano i dati esistenti), una transizione può anche chiedere all'utente di compilare campi nel momento della transizione. Quando i campi obbligatori sono configurati, compare una finestra non appena l'utente attiva la transizione, chiedendo quei valori prima che il cambio di status sia completo.

È utile quando vuoi catturare contesto in una fase specifica — ad esempio, richiedere un campo "Rejection Reason" quando si passa a uno status "Rejected".

Cosa succede in Kanban

Quando trascini una scheda in una nuova colonna nella vista Kanban e quella transizione ha campi obbligatori, la scheda si sposta visivamente nella nuova colonna e la finestra di transizione si apre subito per raccogliere i valori mancanti. Il cambio di status si finalizza una volta che compili la finestra e confermi.

È intenzionale --- ottieni un'esperienza drag-and-drop fluida invece di essere bloccato a metà trascinamento, e il prompt assicura che le informazioni vengano catturate prima che lo spostamento sia confermato. Se chiudi la finestra senza completarla, la scheda torna alla colonna originale. (Se una transizione non è affatto consentita, trascinare la scheda semplicemente non viene accettato e torna indietro.)

Buono a sapersi

Il prompt dei campi obbligatori fa parte dell'interfaccia di Copera --- compare ogni volta che fai la transizione tramite l'app, guidandoti a compilare i dettagli giusti al momento giusto.

Se ti serve una garanzia forte che un campo non possa mai restare vuoto per una transizione (indipendentemente da come viene fatto il cambio), aggiungi un Validator di tipo Field Required o Field Not Empty a quella transizione, oppure segna il campo come Required nel comportamento per-status dei campi. I validator e le regole required per-status sono applicati a tutti, inclusi gli admin del board, quindi sono lo strumento giusto quando il requisito è una regola rigorosa di integrità dei dati piuttosto che un prompt utile.

Gate di approvazione

Le transizioni possono richiedere l'approvazione di persone designate prima che il cambio di status abbia effetto. Quando un utente attiva una transizione con approvazione abilitata, la riga passa a uno status Pending Approval mentre la richiesta di approvazione viene elaborata. Una volta risolta la richiesta (approvata o rifiutata), la riga passa allo status target o torna allo status originale.

Tipi di approvatori

Puoi designare gli approvatori in quattro modi:

• Specific Users — Individui nominati che devono rivedere la richiesta.
• Board Role — Chiunque abbia un ruolo specificato sul board (come "Manager") diventa approvatore.
• Row Owner — La persona che ha creato la riga è l'approvatore.
• Column Based — Gli approvatori vengono determinati dinamicamente in base a un valore di colonna sulla riga (vedi sotto).

Approvatori condizionali basati su colonna

L'approvazione basata su colonna ti permette di instradare le richieste di approvazione a persone diverse a seconda di un valore nella riga — senza creare transizioni o workflow separati per ogni caso.

Quando selezioni Column Based come tipo di approvatore, compaiono tre opzioni di configurazione:

1. Condition column — Scegli una colonna Dropdown (SELECT) dalla tabella. Il valore corrente di questa colonna sulla riga determina chi saranno gli approvatori.
2. Mapping table — Per ogni opzione nella colonna selezionata, assegna uno o più approvatori. Ad esempio, se la colonna "Department" ha le opzioni "RH," "Systems" e "Finance," puoi mappare ogni dipartimento al rispettivo manager.
3. Fallback approvers — Utenti opzionali che ricevono la richiesta di approvazione quando il valore della colonna della riga non corrisponde ad alcuna mappatura (o la colonna è vuota).

Esempio — Approvazione dipartimentale multi-livello:

Supponi di avere una colonna "Department" con le opzioni RH, Systems e Finance. Puoi configurare due transizioni:

• Open → In Review: Approvazione basata su colonna su "Department" — mappa RH al Manager A, Systems al Manager B
• In Review → Done: Approvazione basata su colonna su "Department" — mappa RH al Director X, Systems al Director Y

Ogni transizione risolve in modo indipendente l'approvatore corretto per il dipartimento della riga. Questo crea un flusso di approvazione multi-livello in cui i manager di dipartimento approvano per primi e poi i director di dipartimento.

suggerimento

Il richiedente (la persona che ha attivato la transizione) è automaticamente escluso dall'elenco degli approvatori, anche se corrisponde alla mappatura. Una persona non può approvare la propria richiesta.

Policy di approvazione

Policy	Comportamento
ANY_ONE	Il primo approvatore che agisce (approva o rifiuta) risolve la richiesta per tutti.
ALL	Ogni approvatore designato deve approvare. Un singolo rifiuto rifiuta l'intera richiesta.

Status Pending Approval

Quando l'approvazione è abilitata su una transizione, il sistema crea automaticamente un'opzione di status Pending Approval sulla colonna. È uno status reale — non uno stato interno nascosto — il che significa che funziona senza problemi con ogni funzionalità di Copera:

• Filtri: Filtra la tabella per vedere solo le righe in attesa di approvazione.
• Vista Kanban: Compare automaticamente una colonna "Pending Approval", raggruppando tutte le righe in attesa di decisioni.
• Timer SLA: Configura condizioni SLA per avviare il timing quando una riga entra nello status pending e metterlo in pausa quando esce.
• Automazioni: Crea automazioni che si attivano quando lo status di una riga passa a "Pending Approval" (ad esempio, auto-assegnare un reviewer o inviare una notifica personalizzata).
• Visibilità e regole di campo per-status: Configura override di visibilità e comportamento dei campi specificamente per lo stato pending.

Lo status pending compare nell'editor visuale come nodo distinto con bordo ambra e icona a clessidra, così è facile identificarlo nel grafo del workflow.

nota

Gli status pending approval sono gestiti dal sistema. Non possono essere rinominati o eliminati manualmente — vengono creati quando abiliti l'approvazione su una transizione e ripuliti automaticamente quando la disabiliti.

Come funziona il flusso:

1. Un utente attiva una transizione che richiede approvazione (ad es. Open → In Review).
2. La riga passa immediatamente allo status Pending Approval.
3. Gli approvatori designati ricevono una notifica.
4. Se approvata: la riga passa allo status target (In Review).
5. Se rifiutata: la riga passa allo status di rifiuto configurato, o torna allo status originale (Open) se non ne è impostato nessuno.

Se hai più transizioni con approvazione abilitata, ognuna ottiene il proprio status pending (ad es. "Pending: Manager Approval" e "Pending: Director Approval"), così puoi distinguere le diverse fasi di approvazione.

Gestione del rifiuto

Quando una transizione viene rifiutata, puoi configurare cosa succede alla riga:

• Spostarla a uno status specifico (ad esempio, uno status "Rejected" o "Needs Revision").
• Se non è configurato alcuno status di rifiuto, la riga torna allo status in cui si trovava prima che l'approvazione fosse attivata.

Notifiche

Sia il richiedente sia gli approvatori designati ricevono notifiche in-app e via email. Gli approvatori vengono avvisati quando una nuova richiesta di approvazione li aspetta; il richiedente viene avvisato quando la sua richiesta è approvata o rifiutata.

Commenti sulle decisioni di approvazione

Gli approvatori possono aggiungere un commento insieme alla decisione. Puoi configurare una transizione per richiedere un commento in caso di rifiuto, garantendo che il feedback sia sempre documentato.

nota

Solo una richiesta di approvazione per riga per colonna Status può essere pending alla volta. Se una richiesta è già pending, non può essere attivata nessuna nuova transizione finché non viene risolta o annullata.

Funzioni post-transizione

Le funzioni post-transizione sono azioni che si eseguono automaticamente dopo che una transizione si completa con successo (incluso dopo che un'approvazione è concessa, se applicabile). Girano senza alcuna interazione dell'utente.

Funzione	Descrizione
Set Field	Imposta una colonna a un valore statico specifico.
Copy Field	Copia il valore da una colonna in un'altra colonna sulla stessa riga.
Set Current Date	Scrive la data e l'ora correnti in una colonna date — utile per timestampare quando è avvenuta una transizione.
Assign Current User	Aggiunge l'utente che ha attivato la transizione a una colonna Users.
Assign User	Aggiunge una o più persone specifiche a una colonna Users.
Clear Field	Rimuove del tutto il valore da una colonna.
Send Notification	Invia una notifica in-app a utenti specifici con un messaggio personalizzato.
Webhook	Invia una richiesta HTTP (POST, PUT o PATCH) a un URL esterno, abilitando l'integrazione con sistemi di terze parti.

Puoi aggiungere più post-function a una singola transizione e si eseguono nell'ordine in cui sono elencate.

Visibilità per-status

Puoi controllare quali utenti possono vedere le righe in base allo status corrente della riga. Si configura facendo clic su un nodo status nell'editor visuale e aprendo il suo pannello di impostazioni.

Impostazione di visibilità	Descrizione
Role-based	Solo gli utenti con ruoli board specifici possono vedere le righe in questo status.
User-based	Solo utenti nominati specifici possono vedere le righe in questo status.
Owner Can View	Il creatore della riga vede sempre le proprie righe, anche se le regole di visibilità le escluderebbero altrimenti. Abilitato di default.
Assignee Can View	Gli utenti assegnati alla riga la vedono sempre. Abilitato di default.

nota

Gli admin del board vedono sempre tutte le righe indipendentemente dalle regole di visibilità. Le impostazioni di visibilità si applicano solo ai membri regolari e agli ospiti.

Comportamento dei campi per-status

Quando una riga è in un dato status, puoi sovrascrivere come si comportano i singoli campi. Si configura anche dal pannello di impostazioni del nodo status.

Comportamento	Descrizione
Editable	Comportamento normale — il campo può essere letto e modificato. È il default.
Read-only	Il campo è visibile ma non può essere modificato. Gli admin possono comunque modificare i campi read-only.
Required	Il campo deve avere un valore. È applicato a tutti gli utenti inclusi gli admin — è una regola di integrità dei dati, non una restrizione di permesso.
Hidden	Il campo non è visibile ai non-admin ed è escluso dalle risposte API. Gli admin possono comunque vedere e modificare i campi hidden.

Timer SLA

Le transizioni di status del workflow possono avviare, mettere in pausa e fermare automaticamente le colonne timer SLA. Quando una riga entra o esce da status specifici, il timer risponde di conseguenza — abilitando il tracciamento automatico di quanto tempo il lavoro trascorre in ogni fase. Vedi la pagina Tracciamento SLA per i dettagli completi di configurazione.

Consigli

• Parti semplice. Abilita il workflow con poche transizioni di base, poi aggiungi condizioni, validator e gate di approvazione man mano che il processo matura.
• Usa l'editor visuale per mappare il processo. Disegna il flusso sulla canvas prima di aggiungere regole — è molto più facile individuare lacune e loop visivamente.
• Le transizioni globali sono ottime per le eccezioni. Azioni "Cancel," "Escalate" o "Emergency Close" che dovrebbero essere sempre disponibili da qualsiasi status funzionano perfettamente come transizioni globali (from ANY).
• Combina i gate di approvazione con la visibilità per-status. Sposta una riga in uno status "Pending Review" che solo i reviewer possono vedere e richiedi la loro approvazione prima che avanzi. Questo crea un processo di review sicuro e auditabile.
• Usa le post-function per aggiornamenti ripetitivi. Timestampa automaticamente i completamenti, assegna la persona che ha chiuso un ticket e cancella i campi temporanei — senza che nessuno debba ricordarsi di farlo a mano.
• Prova con una riga di esempio. Prima di rilasciare un workflow a tutto il team, percorri il processo con una riga di test per verificare che ogni transizione, condizione e approvazione si comporti come previsto.

Prossimi passi

• Esplora le Automazioni per regole event-driven "quando succede questo, fai quello" che completano le transizioni del workflow.
• Consulta i Permessi del board per capire come i ruoli del board interagiscono con le condizioni del workflow.
• Scopri i Tipi di campo per capire quali tipi di colonna funzionano con validator e post-function.