> ## 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.

# Blueprint dei casi - Assegnazione e contenuto dei casi

> Configura come una categoria di casi viene assegnata, escalata, trasferita e visualizzata in Didit, e installa i quattro preset integrati.

A review policy, rappresentata come blueprint nell'API, definisce i requisiti per una categoria di caso.
Gestisci le policy in **Gestione dei casi > Assegnazione > Review policies**.
I casi salvano la versione della policy in vigore al momento dell'apertura, quindi le modifiche successive non alterano silenziosamente una revisione in corso.
L'editor invia la versione che hai aperto quando salvi.
Se un altro revisore ha pubblicato una versione più recente, il salvataggio restituisce un conflitto e la tua bozza resta aperta.
Controlla la policy più recente prima di applicare di nuovo le tue modifiche.
Le integrazioni API possono inviare `expected_version` con un aggiornamento della policy per la stessa protezione; una versione obsoleta restituisce `409` senza modificare la policy.

***

## Impostazioni generali

| Impostazione | Descrizione |
| - | - |
| **Nome** | Fino a 24 caratteri |
| **Descrizione** | Facoltativa, testo libero |
| **Chi gestisce i casi** | Pool di assegnatari, obbligatorio, con almeno un membro ("Seleziona almeno un assegnatario") |
| **Assegnazione** | **Manualmente**, oppure **Automaticamente** |
| **Trasferimento del caso** | Interruttore; se attivo, i casi possono passare a un altro blueprint attivo della stessa applicazione |
| **Escalation** | Interruttore più un menu di selezione del blueprint di destinazione |
| **Revisione a 4 occhi** | Abbina a un blueprint verificatore, vedi [Revisione a 4 occhi](https://docs.didit.me/it/console/case-management/four-eyes.md) |
| **Richiedi nota di risoluzione** | Interruttore; se attivo, la nota della finestra di risoluzione diventa obbligatoria |
| **Scadenza predefinita** | Scadenza facoltativa, in ore, per i nuovi casi; una scadenza esplicita del caso ha la precedenza |

### Assegnazione automatica

L'assegnazione automatica seleziona un revisore autorizzato con il minor numero di casi attivi in tutta l'organizzazione, fino alla capacità configurata.
Gli operatori online hanno la precedenza quando disponibili; altrimenti, gli operatori offline idonei possono ricevere casi.
Quando tutti i revisori idonei hanno raggiunto la capacità massima, il caso resta non assegnato.
La risoluzione di un caso oppure l'accesso online di un operatore può prelevare un caso in coda quando la capacità è disponibile.

### Escalation e trasferimento

L'escalation sposta un caso verso un blueprint di destinazione fisso (la sua coda, la sua configurazione dei contenuti) con una sola azione. Il trasferimento del caso, invece, permette a un operatore di scegliere qualsiasi blueprint attivo della stessa applicazione in cui spostare il caso. Entrambe le opzioni sono nascoste nella pagina del caso, a meno che il blueprint corrente non le abiliti, e il server le blocca (400) se vengono tentate mentre sono disattivate.

Un blueprint non può fare riferimento a se stesso come propria destinazione di escalation o come verificatore della revisione a 4 occhi.

### Fonti collegate

La colonna destra di un blueprint elenca:

* **Fonti di creazione dei casi**: configurazioni AML, regole sulle transazioni e nodi del workflow che attualmente instradano nuovi casi al suo interno, con scorciatoie verso ciascuno di essi.
* **Riceve escalation da**: altri blueprint la cui destinazione di escalation punta qui.

## Salvare e pubblicare le modifiche alle policy

**Salva bozza** memorizza le tue modifiche senza influire sui casi nuovi o esistenti.
Una nuova policy resta non pubblicata e non può essere selezionata per un caso o per una regola di instradamento finché non scegli **Pubblica**.
Riaprendo l'editor viene ripristinata la bozza salvata.
**Pubblica** diventa disponibile dopo che le modifiche correnti sono state salvate.
La pubblicazione applica quella versione ai nuovi casi; i casi esistenti mantengono i requisiti di revisione già accettati.
**Cronologia versioni** registra ogni configurazione pubblicata, l'ora di pubblicazione e chi l'ha pubblicata, quando è noto.
Le policy create prima della disponibilità della cronologia delle versioni hanno la loro base attuale registrata alla pubblicazione successiva.
**Scarta bozza** richiede una conferma e riporta l'editor alla configurazione pubblicata.
Scartare una bozza mai pubblicata la elimina.

Il salvataggio della bozza e il controllo di pubblicazione verificano sia la versione pubblicata sia la revisione della bozza.
Se qualcun altro modifica una delle due, il server restituisce `409` e il tuo editor aperto conserva le modifiche non salvate.
Una bozza basata su una policy pubblicata più vecchia deve essere controllata rispetto alla policy attuale prima della pubblicazione.
Gli aggiornamenti `PATCH` diretti via API restano pubblicazioni immediate e vengono anch'essi registrati nella cronologia delle versioni.

### Bozze delle regole di instradamento

Le regole di instradamento usano le stesse azioni **Salva bozza**, **Pubblica**, **Scarta bozza** e **Cronologia versioni**.
Salvare una bozza non modifica la regola usata per l'assegnazione automatica né l'anteprima della regola pubblicata.
Le modifiche non pubblicate devono essere salvate prima di poter essere pubblicate.
La pubblicazione verifica che la policy di revisione e il team selezionati siano ancora attivi e appartengano alla stessa applicazione.
Se un altro editor modifica la regola o la sua bozza, l'operazione restituisce un conflitto e conserva il lavoro più recente.
Le nuove regole usano prima **Salva bozza** e restano inattive finché **Pubblica** non crea la versione 1.
Per le integrazioni API, imposta `publish=false` quando crei una policy o una regola di instradamento per usare questo ciclo di vita.
Omettere l'opzione mantiene la creazione immediata per le integrazioni esistenti.

## Libreria dei preset

Installa uno qualsiasi dei quattro preset integrati dalla galleria dei preset delle policy di revisione. L'installazione copia il preset nella tua applicazione come blueprint completamente modificabile: puoi poi cambiare liberamente qualsiasi impostazione senza influire sul catalogo. L'installazione è idempotente per preset, quindi reinstallare un preset già installato è un'operazione senza effetti.

| Preset | Contenuto del caso |
| - | - |
| **Screening hit** | Controllo AML (finanziario + identità), identità (informazioni personali, panoramica del rischio) |
| **Indagine AML** | Controllo AML (finanziario), identità (informazioni personali, informazioni di contatto, panoramica del rischio, documenti PoI) |
| **Attività sospetta** | Identità (informazioni personali, panoramica del rischio, documenti PoI), finanziario (metodi di pagamento, transazioni) |
| **Revisione KYC** | Identità (tutti i campi), riepilogo della verifica |

Nessuno dei preset preconfigura assegnazione, escalation, revisione a 4 occhi o trasferimento: queste decisioni di instradamento spettano sempre a te, blueprint per blueprint.

## Contenuto del caso

La scheda **Contenuto del caso** controlla quali schede e campi compaiono nella pagina del caso, in sei sezioni attivabili:

| Sezione | Campi |
| - | - |
| **Checklist** | Abilitazione, rendere facoltativa la checklist per la risoluzione e l'elenco delle voci della checklist, vedi [Checklist](https://docs.didit.me/it/console/case-management/checklist.md) |
| **Controllo AML** | Informazioni AML finanziarie, informazioni AML sull'identità |
| **Identità** | Informazioni personali, tag del richiedente, informazioni di contatto, panoramica del rischio, documenti di prova dell'identità, documenti di prova di residenza |
| **Verifiche** | Riepilogo delle verifiche |
| **Reportistica** | Report FIU |
| **Dati e fonti finanziarie** | Metodi di pagamento, transazioni finanziarie |

Un blueprint senza sezioni attive mostra comunque la scheda Panoramica del caso, senza i blocchi di contenuto aggiuntivi.

> [!TIP]
>
> Usa una scadenza predefinita della policy per dare ai nuovi casi una finestra di revisione uniforme.
> I revisori possono comunque aggiornare la priorità e la scadenza di un singolo caso.
> Modificare la policy non cambia le scadenze dei casi esistenti.

## Eliminazione di un blueprint

L'eliminazione di un blueprint va sempre a buon fine e non incide sui suoi casi: i casi esistenti mantengono il riferimento al blueprint, e le sue impostazioni (sezioni del contenuto, escalation, trasferimento, abbinamento secondo il principio dei quattro occhi) continuano ad applicarsi a essi. Un blueprint eliminato non compare più negli elenchi dei blueprint e non può più essere scelto come destinazione di un trasferimento. Se un blueprint di tipo maker viene eliminato mentre una delle sue risoluzioni è in attesa di approvazione secondo il principio dei quattro occhi, una risoluzione rifiutata lascia il caso sul blueprint di tipo checker invece di riportarlo indietro.

Per dismettere un blueprint in modo ordinato, trasferisci i suoi casi attivi a un altro blueprint prima di eliminarlo.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.