Governance dell'assistenza: conservazione, mascheramento, casi sensibili, permessi per canale, policy dei file, cronologia degli accessi e richieste dati del richiedente

La governance dell'assistenza si trova in Impostazioni → Governance dell'assistenza. È lo strato specifico dell'assistenza sopra la sicurezza della piattaforma: isolamento a livello di riga, ruoli e permessi, la traccia di audit, il log degli accessi sensibili e gli strumenti sulla privacy esistono

La governance dell'assistenza si trova in Impostazioni → Governance dell'assistenza. È lo strato specifico dell'assistenza sopra la sicurezza della piattaforma: isolamento a livello di riga, ruoli e permessi, la traccia di audit, il log degli accessi sensibili e gli strumenti sulla privacy esistono già. Questa schermata governa che cosa succede ai casi, ai messaggi, agli allegati e alle persone che li gestiscono. Tutto nasce vuoto: senza nulla configurato, l'assistenza funziona esattamente come prima.

Permessi granulari Quattro permessi sono stati aggiunti alla matrice dei ruoli (Impostazioni → Ruoli e permessi): ticket_internal_note (vedere e scrivere note interne), ticket_message (eliminare un messaggio per tutti), ticket_sensitive (aprire un caso marcato come sensibile, e marcarlo o smarcarlo) e ticket_pii (vedere i dati personali nei messaggi senza mascheramento). Ogni ruolo che poteva leggere i casi ha conservato il diritto di vedere le note interne, così nessuno perde nulla il primo giorno; chi amministra può ora toglierlo dai ruoli dei partner esterni o delle API. I tenant che non usano ancora ruoli e permessi non sono limitati da queste celle.

Conservazione per classe di dato Una policy di conservazione dice per quanto tempo un caso risolto mantiene i suoi dati, per classe: il caso stesso, i messaggi del cliente, le note interne, gli allegati e le risposte di soddisfazione. Il conto alla rovescia inizia quando il caso viene risolto; i casi aperti non vengono mai toccati, per quanto vecchi. Ogni policy sceglie tra anonimizzare (la riga resta, i dati personali come e-mail, nome, telefono, documento e numeri di carta vengono rimossi, così le metriche di volume e di SLA sopravvivono) ed eliminare. Gli allegati possono solo essere eliminati. La scansione notturna applica le policy a lotti e registra ogni passaggio in un registro che non può essere modificato; la scheda Conservazione mostra il registro e permette a chi amministra di eseguire subito la scansione per questo workspace. Le classi senza policy sono mostrate come non dichiarate, mai date per scontate come conservate per sempre di proposito.

Mascheramento nella conversazione Le regole di mascheramento decidono che cosa viene nascosto nei messaggi del caso per le persone senza il permesso ticket_pii. Esistono tre tipi: dati personali (e-mail, telefono, codici fiscali, numeri di carta, usando gli stessi rilevatori che proteggono i prompt dell'IA), importi finanziari ancorati a una valuta, e pattern personalizzati che scrivi tu (un formato di numero di conto, un codice d'ordine). Ogni regola si applica ai messaggi del cliente, alle note interne o a entrambi, e sostituisce la corrispondenza con un segnaposto a tua scelta. La scheda elenca quali ruoli vedono tutto prima che tu crei la prima regola, e mostra in anteprima l'effetto di una regola su un testo di esempio. Le persone con il permesso vedono sempre il testo originale.

Casi sensibili Chiunque abbia il permesso ticket_sensitive può marcare un caso come sensibile dall'intestazione del caso nella console, con un motivo facoltativo. Da quel momento solo le persone con quel permesso possono aprirlo; a tutti gli altri viene mostrato un rifiuto esplicito. Ogni apertura viene registrata nel log degli accessi sensibili (chi, quando, quale caso), deduplicata per persona ogni dieci minuti così gli aggiornamenti della pagina non gonfiano la traccia. Marcare e smarcare vengono registrati come eventi di sicurezza nella traccia di audit, che chi amministra non può disattivare.

Permessi per canale Per impostazione predefinita, chiunque possa rispondere può farlo su ogni canale. Nella scheda Canali, chi amministra abilita ruoli specifici su un canale. La prima riga scritta per un canale lo chiude a tutti gli altri: da quel momento solo i ruoli elencati possono rispondere lì. I canali senza righe restano aperti. Il server lo applica a ogni risposta, qualunque sia la schermata.

Policy dei file Una policy per workspace: estensioni consentite (se l'elenco non è vuoto, passano solo queste), estensioni bloccate (sempre rifiutate, anche se consentite altrove), un limite di dimensione per file inferiore ai 25 MB della piattaforma, e se la policy si applica anche agli allegati che arrivano via e-mail o portale. Non c'è scansione antivirus; la policy riguarda tipi e dimensioni dei file.

Cronologia degli accessi La scheda Accessi mostra chi ha effettuato l'accesso, quando, da quale indirizzo e dispositivo, e i tentativi di password falliti per i membri di questo workspace. L'autenticazione vera e propria è gestita dal provider di identità; questo è uno specchio di ciò che il server vede, una riga per sessione, conservata in una tabella che non può essere modificata.

Richieste dati del richiedente Quando un cliente chiede una copia dei propri dati o la cancellazione, usa la scheda Richieste dati con il suo indirizzo e-mail. Se esiste un contatto con quell'e-mail, l'esportazione e l'anonimizzazione usano gli stessi strumenti sulla privacy del record di contatto e coprono messaggi, risposte di soddisfazione, conversazioni parallele, attività, elementi di bacheca e allegati. Se non esiste un contatto (un richiedente che ha solo scritto senza mai diventarlo), i casi, i messaggi e le risposte di soddisfazione trovati con quell'e-mail vengono esportati o anonimizzati direttamente. L'anonimizzazione è irreversibile, richiede un motivo e viene registrata come evento di sicurezza.

Apri questo articolo dentro il sistema →