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.