Torna al changelog

• Novità

  Nessuno resta in attesa senza che tu lo sappia

  Escalation a step. Una policy di alert è una sequenza di promemoria — email, webhook (con connector riusabile o URL manuale, firmato HMAC) o evento di sistema — ognuno dopo N minuti dall’inizio dell’attesa. La policy predefinita (già seedata per ogni tenant): email all’assegnatario dopo 30 minuti, di nuovo dopo 4 ore, poi email agli Admin dopo 24 ore, infine un evento alert.unanswered intercettabile dai flussi — così un’attesa prolungata può innescare automazioni (riassegnazione, notifica a un responsabile, apertura di un altro flusso). Ogni flusso può avere la sua policy. Da Impostazioni → Notifiche si creano policy custom (step, destinatari — assegnatario, utente specifico o ruolo —, finestra di digest) e si assegnano a singoli flussi dalle sue proprietà; senza assegnazione vale la policy predefinita del tenant. Anti-fatigue. Più promemoria per lo stesso destinatario nella stessa finestra si raggruppano in un’unica email digest, invece di una mail per ogni attività in attesa. Quiet hours. Il tenant può definire una fascia (giorni + orario) fuori dalla quale email e webhook non partono — si riprogrammano al primo orario utile; le notifiche in-app restano immediate.

• Novità

  Preso in carico, senza fare il giro dell’app

  Ack da link firmato. Ogni promemoria email/webhook porta un link "preso in carico" (firma HMAC, nessun login richiesto): un click sospende l’escalation per quell’attività. Ack dalla campanella. Le notifiche in-app relative a un alert hanno un bottone diretto per prenderle in carico senza uscire dall’interfaccia. Si risolve da sola. Completare il task o far avanzare l’item chiude automaticamente l’attesa, senza bisogno di un ack esplicito.

• Miglioramento

  Report e governo dei dati

  Tempi di risposta per operatore. In Impostazioni → Notifiche, un report mostra quante allerte sono state prese in carico/risolte e in quanto tempo, per persona. Escludi dalle statistiche. Un flusso (es. di servizio o test) può essere escluso da analytics e dashboard con un flag dedicato; nello stesso giro sono stati sistemati anche i flussi di sistema che inquinavano gli aggregati senza che l’utente lo avesse chiesto. Retention per flusso. Ogni flusso può definire dopo quanti giorni gli item completati vengono eliminati definitivamente (hard delete), per chi non vuole accumulare storico a tempo indeterminato. Filtro per cartella. Dashboard e analytics si possono restringere a una cartella (e alle sue sotto-cartelle) invece di guardare sempre tutto il tenant.