Vai al contenuto principale
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

​
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. 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: Un blueprint senza sezioni attive mostra comunque la scheda Panoramica del caso, senza i blocchi di contenuto aggiuntivi.
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.
Ultima modifica il 7 novembre 2026