Code, turni e assenze: come si distribuisce il lavoro

In FortiSOAR l’assegnazione non è un campo che qualcuno compila: è una catena che il motore valuta a ogni creazione o aggiornamento di record. L’alert nasce, una regola di coda lo cattura, la coda decide a chi darlo, il turno filtra chi è realmente disponibile in quel momento, il calendario delle assenze toglie di mezzo chi è in ferie. Se un anello salta, il campo assegnatario resta vuoto in silenzio e te ne accorgi quando il record ha sforato la sua Response Due Date.

Il prerequisito che fa perdere il punto: il modulo deve essere Queueable

Alerts, Incidents e Tasks sono marcati Queueable di serie. Qualsiasi altro modulo, Events compreso o uno custom, non compare nemmeno nella lista Module Types del wizard finché non lo rendi tale: Settings, sezione Application Editor, Modules, selezioni il modulo, in Additional Setting spunti Queueable, poi Save e Publish. Serve un ruolo con CRUD sul modulo Application. Il passo che salta più spesso è Publish: senza pubblicazione la modifica non è attiva e il modulo resta assente dall’elenco, il che ti fa cercare l’errore nella coda invece che nel Module Editor.

Il secondo prerequisito è invisibile dalla GUI delle code. Ogni team che aggiungi come owner di una coda deve essere collegato all’appliance «Playbook»: se non lo è, l’assegnazione della coda non funziona per quel team. Stessa logica per i moduli custom, dove all’appliance Playbook va assegnato un ruolo con i permessi appropriati su quel modulo. Sui permessi utente: per gestire code e turni servono Create, Read, Update e Delete su Queues e Shifts più Read su People; per sola lettura basta Read sui tre moduli. Read su Security non è obbligatorio ma conviene, perché è ciò che ti permette di aggiungere interi team come owner e poi come membri in un colpo solo.

Nota storica utile: la vecchia pagina Queue Management è deprecata dalla 7.2.0 perché non supportava le assegnazioni automatiche. La funzione da usare, e da citare all’esame, è Assignment.

Regole di coda, priorità e uscita automatica

Il wizard ha quattro schermate: Queue Definition, Define Rules, Queue Members, User Assignment. Nelle regole scegli il record type e l’azione: per default la regola è sull’azione Creation. Se imposti Updated devi anche popolare «Select Record Fields to Monitor For Updates», ed è qui che si perde il punto: se il campo non è nell’elenco dei campi monitorati, la regola non scatta mai, nemmeno quando le condizioni sarebbero soddisfatte.

Ogni coda ha un valore in «Set Priority For When Multiple Queues Match Their Conditions», default Very Low. Serve solo quando un record soddisfa le regole di più code: vince quella con priorità più alta. Se lasci tutte le code a Very Low e poi ti chiedi perché un alert finisce ogni volta nella coda sbagliata, la risposta è questa.

I criteri di uscita si configurano altrove e con un raggio d’azione diverso: sulla pagina Queue Management, icona Settings, scheda Automatic Queue Exit Criteria. Sono definiti per modulo e rimuovono il record da tutte le code di quel modulo, non dalla singola coda. Anche qui vale la regola dei campi monitorati. La scheda Assignment Fields decide quale campo è l’assegnatario per ogni modulo queueable, e Grid Display Settings decide solo l’aspetto delle card.

Turni: generazione, fallback e handover

Generate Shifts chiede nome, Start Time in formato 24 ore, Timezone, Duration in ore e minuti separati, Days Of The Week (Monday-Friday di default), Starting On e «# Of Weeks To Generate». Genera record concreti, non una regola ricorrente: se generi 26 settimane, alla 27esima non esiste più alcun turno e da quel momento decide il fallback.

Il fallback è il punto più interrogabile dell’intero task. In User Assignment scegli fra Assign to Queue Lead, Round Robin e Assign to Nobody. Attivando l’assegnazione basata sui turni, le opzioni di ripiego non sono le stesse nei due casi: con Assign to Queue Lead puoi indicare solo Nobody (leave blank) oppure Current Shift Lead, quando il queue lead non è in turno; con Round Robin puoi indicare Nobody (leave blank), Queue Lead oppure Current Shift Lead. Chi risponde «le stesse tre opzioni» perde il punto intero.

L’handover non avviene da solo allo scoccare del cambio turno: si lancia con Initiate Shift Handover, scegliendo il turno di partenza, quello di destinazione e il destinatario fra Shift Manager, Round Robin e Nobody. Le condizioni per modulo contano soltanto se hai spuntato «Include in handover» su quella riga. Il campo «Only Include Records Created In The» limita l’età dei record e il commento che scrivi finisce davvero nei record riassegnati, quindi usalo come traccia.

Assenze: funzionano solo con il round robin

Leave Management esclude un analista dalle assegnazioni per la durata della sua assenza, ma opera con il metodo Round Robin. Se una coda assegna al queue lead e il lead è in ferie, i record continuano ad arrivargli: la soluzione è il fallback basato sui turni, non il calendario ferie. Servono Create, Read e Update sul modulo Leave Schedules, e Delete per cancellarle; sulle installazioni nuove dalla 7.4.1 in poi quei permessi sono già nel ruolo Full App Permissions, mentre su un sistema aggiornato da una release precedente vanno assegnati a mano.