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

# Blueprints de casos - Assignació i contingut del cas

> Configura com s'assignen, escalen, transfereixen i es mostren els casos d'una categoria a Didit, i instal·la els quatre presets integrats.

Una política de revisió, representada com a blueprint a l’API, defineix els requisits per a una categoria de cas.
Gestiona les polítiques a **Gestió de casos > Assignació > Polítiques de revisió**.
Els casos desen la versió de la política vigent quan s’obren, de manera que les edicions posteriors no canvien sense avisar una revisió en curs.
L’editor envia la versió que tenia oberta quan la desis.
Si un altre revisor ha publicat una versió més nova, el desament retorna un conflicte i el teu esborrany es manté obert.
Revisa la política més recent abans d’aplicar de nou els teus canvis.
Les integracions de l’API poden enviar `expected_version` amb una actualització de la política per a la mateixa protecció; una versió obsoleta retorna `409` sense canviar la política.

***

## Configuració general

| Configuració | Descripció |
| - | - |
| **Nom** | Fins a 24 caràcters |
| **Descripció** | Opcional, text lliure |
| **Qui gestiona els casos** | Grup d’assignataris, obligatori, com a mínim un membre ("Pick at least one assignee") |
| **Assignació** | **Manualment**, o **Automàticament** |
| **Transferència de casos** | Interruptor; quan està activat, els casos es poden moure a un altre blueprint actiu de la mateixa aplicació |
| **Escalat** | Interruptor més un selector de blueprint de destinació |
| **Revisió a 4 ulls** | Associació amb un blueprint verificador, vegeu [Revisió a 4 ulls](https://docs.didit.me/ca/console/case-management/four-eyes.md) |
| **Requereix una nota de resolució** | Interruptor; quan està activat, la nota del diàleg Resol esdevé obligatòria |
| **Termini predeterminat** | Termini opcional en hores per als casos nous; un termini explícit del cas té prioritat |

### Assignació automàtica

L’assignació automàtica selecciona un revisor autoritzat amb menys casos actius a tota l’organització, fins a la capacitat configurada.
Els agents en línia tenen preferència quan n’hi ha de disponibles; en cas contrari, els agents fora de línia elegibles poden rebre casos.
Quan tots els revisors elegibles han arribat a la capacitat, el cas queda sense assignar.
Resoldre un cas o que un agent es connecti pot fer sortir un cas de la cua quan hi ha capacitat disponible.

### Escalat i transferència

L’escalat mou un cas a un blueprint de destinació fix (la seva cua, la seva configuració de contingut) en una sola acció. La transferència de casos, en canvi, permet a un agent triar qualsevol blueprint actiu de la mateixa aplicació per moure-hi un cas. Totes dues opcions queden amagades a la pàgina del cas tret que el blueprint actual les habiliti, i el servidor les bloqueja (400) si s’intenten mentre estan desactivades.

Un blueprint no pot fer-se referència a si mateix com a destinació d’escalat ni com a verificador de la revisió a 4 ulls.

### Fonts connectades

La barra lateral dreta d’un blueprint mostra:

* **Fonts de creació de casos**: configuracions AML, regles de transaccions i nodes de flux de treball que actualment encaminen casos nous cap a ell, amb dreceres a cadascun.
* **Rep escalacions de**: altres blueprints amb una destinació d’escalat que apunta cap aquí.

## Desar i publicar canvis de política

**Desa l’esborrany** emmagatzema els canvis sense afectar els casos nous ni els existents.
Una política nova queda sense publicar i no es pot seleccionar per a un cas ni per a una regla d’encaminament fins que triïs **Publica**.
En tornar a obrir l’editor es restaura l’esborrany desat.
**Publica** està disponible quan els canvis actuals ja s’han desat.
Publicar aplica aquesta versió als casos nous; els casos existents conserven els requisits de revisió que ja havien acceptat.
**Historial de versions** registra cada configuració publicada, l’hora de publicació i la persona que la va publicar, quan es coneix.
Les polítiques creades abans que existís l’historial de versions tenen la seva línia base actual registrada en la següent publicació.
**Descarta l’esborrany** requereix confirmació i torna l’editor a la configuració publicada.
Descartar un esborrany mai publicat l’elimina.

Els desaments d’esborrany i la comprovació de publicació verifiquen tant la versió publicada com la revisió de l’esborrany.
Si algú altre canvia qualsevol de les dues, el servidor retorna `409` i el teu editor obert conserva els canvis no desats.
Un esborrany basat en una política publicada anterior s’ha de revisar contra la política vigent abans de publicar-lo.
Les actualitzacions directes amb `PATCH` de l’API continuen sent publicacions immediates i també es registren a l’historial de versions.

### Esborranys de regles d’encaminament

Les regles d’encaminament fan servir les mateixes accions **Desa l’esborrany**, **Publica**, **Descarta l’esborrany** i **Historial de versions**.
Desar un esborrany no canvia la regla usada per a l’assignació automàtica ni la vista prèvia de la regla publicada.
Els canvis no publicats s’han de desar abans de poder-se publicar.
La publicació comprova que la política de revisió i l’equip seleccionats continuen actius i pertanyen a la mateixa aplicació.
Si un altre editor canvia la regla o el seu esborrany, l’operació retorna un conflicte i conserva els canvis més recents.
Les regles noves fan servir primer **Desa l’esborrany** i resten inactives fins que **Publica** crea la versió 1.
Per a les integracions de l’API, estableix `publish=false` en crear una política o una regla d’encaminament per fer servir aquest cicle de vida.
Si s’omet l’opció, es manté la creació immediata per a les integracions existents.

## Biblioteca de preconfiguracions

Instal·la qualsevol de les quatre preconfiguracions integrades des de la galeria de preconfiguracions de polítiques de revisió. Instal·lar copia la preconfiguració a la teva aplicació com a blueprint totalment editable; després pots canviar qualsevol configuració lliurement sense afectar el catàleg. La instal·lació és idempotent per preconfiguració, de manera que tornar a instal·lar una preconfiguració ja instal·lada no fa res.

| Preconfiguració | Contingut del cas |
| - | - |
| **Coincidència de cribratge** | Control AML (financer + identitat), identitat (informació personal, visió general de risc) |
| **Investigació AML** | Control AML (financer), identitat (informació personal, informació de contacte, visió general de risc, documents PoI) |
| **Activitat sospitosa** | Identitat (informació personal, visió general de risc, documents PoI), financer (mètodes de pagament, transaccions) |
| **Revisió KYC** | Identitat (tots els camps), resum de la verificació |

Cap de les preconfiguracions preconfigura l’assignació, l’escalat, la revisió a 4 ulls ni la transferència: aquestes decisions d’encaminament sempre les prens tu per a cada blueprint.

## Contingut del cas

La pestanya **Contingut del cas** controla quines pestanyes i camps apareixen a la pàgina del cas, en sis seccions que es poden activar i desactivar:

| Secció | Camps |
| - | - |
| **Llista de verificació** | Activar, fer opcional per a la resolució, i la llista d'elements de la llista de verificació, consulteu [Llista de verificació](https://docs.didit.me/ca/console/case-management/checklist.md) |
| **Control AML** | Informació financera d'AML, informació d'identitat d'AML |
| **Identitat** | Informació personal, etiquetes de sol·licitant, informació de contacte, resum de risc, documents acreditatius de la identitat, documents acreditatius del domicili |
| **Verificacions** | Resum de verificacions |
| **Informes** | Informes de la UIF |
| **Dades i fonts financeres** | Mètodes de pagament, transaccions financeres |

Un blueprint sense cap secció activada continua mostrant la pestanya de visió general del cas, però sense els blocs de contingut addicionals.

> [!TIP]
>
> Utilitzeu un termini per defecte de la política per donar als casos nous una finestra de revisió coherent.
> Els revisors encara poden actualitzar la prioritat i la data límit d'un cas individual.
> Editar la política no canvia els terminis dels casos existents.

## Eliminar un blueprint

Eliminar un blueprint sempre es fa correctament i no afecta els seus casos: els casos existents conserven la referència al blueprint, i la seva configuració (seccions de contingut, escalat, transferència, parella de 4 ulls) continua aplicant-se-hi. Un blueprint eliminat deixa d'aparèixer a les llistes de blueprints i ja no es pot triar com a destinació d'una transferència. Si s'elimina un blueprint del creador mentre una de les seves resolucions està pendent d'aprovació de 4 ulls, una resolució rebutjada deixa el cas al blueprint del revisor en lloc de retornar-lo.

Per retirar un blueprint de manera ordenada, transferiu els seus casos actius a un altre blueprint abans d'eliminar-lo.


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