> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Gestione dei casi - Casi e ciclo di vita > Apri, lavora e risolvi casi di indagine legati a un singolo utente o azienda con viste salvate, scadenze SLA e azioni in blocco di Didit. Case Management è il centro di indagine della Console Didit. Ogni riscontro AML, ogni verifica segnalata o ogni transazione sospetta può diventare un **caso** su cui il tuo team di compliance lavora dall'apertura alla risoluzione, con un registro di audit completo. *** ## Ciclo di vita Un caso attraversa esattamente tre stati: | Stato | Significato | | - | - | | `Open` | In fase di indagine attiva | | `Awaiting user` | In pausa mentre vengono raccolte ulteriori informazioni dall'utente verificato | | `Resolved` | Indagine completata, con una risoluzione registrata | Per risolvere un caso è necessaria una risoluzione: | Risoluzione | Significato | | - | - | | `False positive` | L'attività era legittima | | `Valid threat` | Attività sospetta o fraudolenta confermata | Ogni caso ha inoltre una **priorità** (`Low`, `Medium`, `High`, predefinita `Medium`) e una **data di scadenza** facoltativa che guida l'ordinamento per SLA e i flag di ritardo. > [!NOTE] > > Non esistono `Under review`, `On hold`, `Pending approval`, né una gravità `Critical` o un asse di tipo di caso. Il ciclo di vita è volutamente fisso, per mantenere analisi, SLA e permessi univoci per ogni caso, indipendentemente da come è stato creato. ## Un soggetto per caso Ogni caso è associato a **esattamente un** utente o a **una sola** azienda. Non puoi mescolare soggetti in un unico caso, e non puoi collegare una sessione, una sessione aziendale o una transazione che appartiene a un soggetto diverso da quello del caso: in tal caso viene restituito un errore esplicito. Questo mantiene ogni pagina del caso focalizzata: la scheda del soggetto, la panoramica del rischio, i documenti e i dati finanziari descrivono tutti la stessa persona o azienda oggetto dell'indagine. Per esaminare una seconda entità, apri (o crea) un caso separato. ## Contesto della fonte Fraud Check Creando un caso da una sessione Fraud Check si conservano il suo ID di controllo, l'ID della richiesta e la sezione aperta dal revisore. La scheda della fonte registra anche lo stato di analisi della sessione al momento della creazione del caso. La decisione sul caso e la decisione sulla fonte restano separate. I client API possono fornire `source_context` con `check_id`, `request_id` e `source_section` quando creano un caso. Includi tale richiesta come voce `session` in `links`. Il controllo e la sessione collegata devono appartenere all'applicazione selezionata e appartenere l'uno all'altra. L'API legge da sola lo stato di analisi e, in questo contesto, rifiuta i campi di stato, raccomandazione o tipo di fonte forniti dal chiamante. ## Elenchi Case Management mantiene **Casi**, **Panoramica** e **Assegnazione** disponibili nella navigazione superiore. Lo spazio di lavoro Casi offre le viste per stato **Aperti**, **In attesa dell'utente**, **Risolti** e **Tutti**. Aprendo un caso, la coda dei casi resta affiancata ai suoi dettagli su desktop. Su mobile, usa il breadcrumb per tornare alla coda. La ricerca corrisponde a nome o ID del soggetto, tag, numero del caso, titolo del caso, ID della sessione collegata e ID della transazione collegata, così puoi incollare un UUID di sessione o di transazione e arrivare direttamente al suo caso. Chip di filtro: **Blueprint**, **Creata**, **Fonte**, **Assegnatario**, **Tag**, più **Aggiungi filtro** per **Priorità** e **Scadenza**. Colonne: Creazione (data e autore), Dettagli del caso (titolo), Stato, Blueprint, Soggetto (nome e ID), Tag del soggetto, Assegnatario, Priorità e Data di scadenza, con altre disponibili scorrendo orizzontalmente e tramite la configurazione delle colonne. ### Ordinamento e SLA Ordina per **Creato il** (predefinito) o per **Data di scadenza**. Ordinando per data di scadenza, i casi in ritardo compaiono per primi: un caso è in ritardo quando la sua data di scadenza è passata mentre è ancora Aperto o In attesa dell'utente, e viene mostrato con un chip rosso di scadenza. ### Viste salvate Salva la combinazione corrente di filtri e colonne come vista con nome usando **Salva vista**, passa da una vista all'altra con **Seleziona una vista** e reimposta con **Cancella filtri**. Le viste sono personali e vengono conservate allo stesso modo delle altre preferenze delle tabelle della console. ### Azioni di massa Seleziona più casi per: * **Assegna a** un operatore. Tutti i casi selezionati devono condividere lo stesso blueprint: la console avvisa prima dell'invio se non è così. * **Imposta stato** su In attesa dell'utente, Riapri o Risolvi (con una risoluzione e una nota facoltativa). Ogni caso viene valutato in modo indipendente: un caso bloccato da una checklist incompleta o da una nota obbligatoria mancante viene segnalato singolarmente, senza far fallire il resto del batch. ### Esportazioni Il menu dell'elenco offre due esportazioni CSV, consegnate tramite la [pagina Report](https://docs.didit.me/it/console/export-pdf-csv.md): * **Report di tutti i casi**, una riga per caso con stato, risoluzione, priorità, tag, transazioni collegate e l'ultimo report FIU inviato. * **Report SLA**, metriche temporali per caso: ore fino all'assegnazione, ore fino alla risoluzione, flag di ritardo e flag di SLA rispettato. ## Azioni sul soggetto e nuovi tentativi La scheda del soggetto permette ai revisori autorizzati di modificare lo stato del soggetto, aggiungere tag, aggiungere una nota interna o inserire il soggetto nella blocklist. Queste azioni sono separate dalla risoluzione del caso. La sezione **Azioni sul soggetto** registra ogni azione richiesta come **Applicata** o **Fallita** e indica il suo revisore e l'orario. Usa **Riprova azione** per ritentare un'azione fallita dopo aver verificato lo stato attuale del soggetto. Un'azione già applicata non viene eseguita di nuovo quando la sua richiesta viene ritentata. I client API dovrebbero inviare un `client_reference` univoco con ogni richiesta all'endpoint `entity-actions/` del caso. Mantieni lo stesso riferimento e lo stesso input quando ritenti una richiesta dopo un errore di connessione. Un input modificato con lo stesso riferimento restituisce `409`. Quando un riferimento è fornito, controlla `receipt.status`: una risposta `200` può contenere una ricevuta fallita, il che significa che l'azione non è stata applicata. Ritentare una richiesta fallita richiede `retry: true`, oppure una chiamata al suo endpoint `action-receipts/{receipt_uuid}/retry/`. L'endpoint della cronologia restituisce al massimo 20 ricevute per pagina e fornisce `next_offset` per ottenere risultati aggiuntivi. I client API esistenti che omettono `client_reference` mantengono il loro comportamento di risposta precedente. ## Tag Aggiungi tag a un caso dalla sua intestazione (**Aggiungi tag**) per raggruppare indagini correlate, oppure filtra e cerca per tag dall'elenco. Le modifiche ai tag vengono registrate nella cronologia del caso. ## Pagine correlate > [card] [Creazione di casi](https://docs.didit.me/it/console/case-management/creating-cases.md) > > Ogni punto di ingresso: utenti, aziende, sessioni, transazioni e connettori automatici. > [card] [Blueprint](https://docs.didit.me/it/console/case-management/blueprints.md) > > Configura assegnazione, escalation, trasferimento e contenuto della pagina del caso. > [card] [Checklist](https://docs.didit.me/it/console/case-management/checklist.md) > > Subordina la risoluzione ai passaggi di indagine obbligatori. > [card] [Revisione a 4 occhi](https://docs.didit.me/it/console/case-management/four-eyes.md) > > Approvazione da parte di chi effettua la modifica e di chi la verifica per le risoluzioni sensibili. ## Messaggi al cliente Usa **Invia messaggio** per visualizzare in anteprima una richiesta predefinita o un aggiornamento della revisione destinato a un contatto verificato. Consulta [Messaggi al cliente](https://docs.didit.me/it/console/case-management/customer-messages.md) per gli stati di consegna, le risposte sicure e il workflow API. ## Discussione e note fissate Apri la discussione tramite il pulsante accanto allo stato del caso per consultare le note senza interrompere l'indagine. Usa il menu di una nota per rispondere o fissarla. Le note fissate compaiono per prime, e le risposte mostrano un breve estratto della nota originale. Le modifiche relative al fissaggio delle note vengono registrate nell'attività del caso e non modificano le decisioni della fonte. La conferma dell'eliminazione rimuove in modo permanente la nota e l'estratto della nota citato nelle risposte. Le risposte restano disponibili. Gli allegati vengono eliminati, a meno che un'altra nota ne faccia ancora uso. I client API possono fornire un UUID `client_reference` quando aggiungono una nota. Un nuovo tentativo senza modifiche restituisce la nota esistente senza duplicare le notifiche. Riutilizzare quel riferimento per contenuti modificati o per una nota eliminata restituisce `409`. Fornisci `reply_to` per fare riferimento a una nota attiva nello stesso caso, e aggiorna `is_pinned` tramite l'endpoint `PATCH` della nota. ## Verifica di un'indagine esistente La finestra di dialogo condivisa Crea caso verifica la presenza di indagini esistenti per l'utente, l'azienda o la fonte collegata selezionata. Apri un caso esistente per continuare a esaminarlo. I casi chiusi restano visibili, così puoi aprirli e decidere se riaprirli. Per creare un'indagine separata, inserisci un motivo per trattarla come un incidente diverso. Il motivo viene salvato con il nuovo caso e mostrato nella sua panoramica. La console ricontrolla i duplicati quando invii, inclusi i casi creati da un altro revisore mentre la finestra di dialogo era aperta. Le integrazioni API possono consultare `POST .../cases/duplicates/` e impostare `review_duplicates=true` alla creazione del caso. Quando viene trovata un'indagine esistente, la creazione restituisce `409`, a meno che non sia fornito `separate_incident_reason`. L'endpoint di revisione dei duplicati restituisce fino a 20 casi per pagina, con `next_offset` per ottenere altri risultati. Le integrazioni API esistenti che omettono l'opzione mantengono il comportamento attuale di creazione. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.