> ## 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: asignación y contenido de casos > Configura en Didit cómo se asignan, escalan, transfieren y muestran los casos de una categoría, e instala los cuatro presets integrados. Una política de revisión, representada como un blueprint en la API, define los requisitos de una categoría de caso. Gestiona las políticas en **Gestión de casos > Asignación > Políticas de revisión**. Los casos guardan la versión de la política vigente en el momento de abrirse, de modo que las ediciones posteriores no cambian sin aviso una revisión en curso. Al guardar, el editor envía la versión que abrió. Si otro revisor ha publicado una versión más reciente, el guardado devuelve un conflicto y tu borrador sigue abierto. Revisa la política más reciente antes de volver a aplicar tus cambios. Las integraciones por API pueden enviar `expected_version` con una actualización de la política para obtener la misma protección; una versión desactualizada devuelve `409` sin modificar la política. *** ## Configuración general | Ajuste | Descripción | | - | - | | **Nombre** | Hasta 24 caracteres | | **Descripción** | Opcional, texto libre | | **Quién gestiona los casos** | Grupo de asignados, obligatorio, con al menos un miembro ("Pick at least one assignee") | | **Asignación** | **Manualmente** o **Automáticamente** | | **Transferencia de casos** | Interruptor; cuando está activado, los casos pueden pasar a otro blueprint activo de la misma aplicación | | **Escalado** | Interruptor más un selector de blueprint de destino | | **Revisión a 4 ojos** | Se empareja con un blueprint verificador; consulta [Revisión a 4 ojos](https://docs.didit.me/es/console/case-management/four-eyes.md) | | **Requerir nota de resolución** | Interruptor; cuando está activado, la nota del diálogo de resolución pasa a ser obligatoria | | **Plazo predeterminado** | Plazo opcional en horas para los casos nuevos; un plazo explícito del caso tiene prioridad | ### Asignación automática La asignación automática selecciona a un revisor autorizado con el menor número de casos activos en toda la organización, hasta la capacidad configurada. Se da preferencia a los responsables conectados cuando los hay; de lo contrario, los responsables desconectados que cumplan los requisitos pueden recibir casos. Cuando todos los revisores que cumplen los requisitos están al límite de su capacidad, el caso queda sin asignar. Resolver un caso o que un responsable se conecte puede asignar un caso en cola cuando hay capacidad disponible. ### Escalado y transferencia El escalado mueve un caso a un blueprint de destino fijo (su cola y su configuración de contenido) en una sola acción. La transferencia de casos, en cambio, permite a un responsable elegir cualquier blueprint activo de la misma aplicación al que mover un caso. Ambas opciones se ocultan en la página del caso salvo que el blueprint actual las habilite, y ambas se bloquean en el servidor (400) si se intentan mientras están desactivadas. Un blueprint no puede referenciarse a sí mismo como su propio destino de escalado ni como su verificador de revisión a 4 ojos. ### Fuentes conectadas El panel lateral derecho de un blueprint muestra: * **Fuentes de creación de casos**: configuraciones AML, reglas de transacciones y nodos de flujo de trabajo que actualmente dirigen casos nuevos hacia él, con accesos directos a cada uno. * **Recibe casos escalados de**: otros blueprints cuyo destino de escalado apunta a este. ## Guardar y publicar cambios en la política **Guardar borrador** almacena tus cambios sin afectar a los casos nuevos ni a los existentes. Una política nueva permanece sin publicar y no se puede seleccionar para un caso ni para una regla de enrutamiento hasta que eliges **Publicar**. Al volver a abrir el editor se restaura el borrador guardado. **Publicar** queda disponible una vez guardadas las ediciones actuales. Al publicar, esa versión se aplica a los casos nuevos; los casos existentes conservan sus requisitos de revisión aceptados. **Historial de versiones** registra cada configuración publicada, la hora de publicación y quién la publicó cuando se conoce. En las políticas creadas antes de que existiera el historial de versiones, su configuración actual se registra como base en la siguiente publicación. **Descartar borrador** requiere confirmación y devuelve el editor a la configuración publicada. Descartar un borrador que nunca se ha publicado lo elimina. Al guardar borradores y al publicar se comprueban tanto la versión publicada como la revisión del borrador. Si otra persona cambia cualquiera de las dos, el servidor devuelve `409` y tu editor abierto conserva las ediciones no guardadas. Un borrador basado en una política publicada anterior debe revisarse frente a la política actual antes de publicarse. Las actualizaciones directas con `PATCH` por API siguen siendo publicaciones inmediatas y también quedan registradas en el historial de versiones. ### Borradores de reglas de enrutamiento Las reglas de enrutamiento usan las mismas acciones **Guardar borrador**, **Publicar**, **Descartar borrador** e **Historial de versiones**. Guardar un borrador no cambia la regla utilizada para la asignación automática ni la vista previa de la regla publicada. Los cambios sin publicar deben guardarse antes de poder publicarse. La publicación comprueba que la política de revisión y el equipo seleccionados siguen activos y pertenecen a la misma aplicación. Si otro editor cambia la regla o su borrador, la operación devuelve un conflicto y conserva el trabajo más reciente. Las reglas nuevas usan primero **Guardar borrador** y permanecen inactivas hasta que **Publicar** crea la versión 1. En las integraciones por API, establece `publish=false` al crear una política o una regla de enrutamiento para usar este ciclo de vida. Si se omite la opción, se mantiene la creación inmediata para las integraciones existentes. ## Biblioteca de plantillas predefinidas Instala cualquiera de las cuatro plantillas predefinidas integradas desde la galería de plantillas de políticas de revisión. Al instalarla, la plantilla se copia en tu aplicación como un blueprint totalmente editable, y después puedes cambiar cualquier ajuste libremente sin afectar al catálogo. La instalación es idempotente por plantilla, por lo que volver a instalar una plantilla ya instalada no tiene ningún efecto. | Plantilla predefinida | Contenido del caso | | - | - | | **Screening hit** | Control AML (financiero + identidad), identidad (información personal, resumen de riesgo) | | **Investigación AML** | Control AML (financiero), identidad (información personal, información de contacto, resumen de riesgo, documentos de PoI) | | **Actividad sospechosa** | Identidad (información personal, resumen de riesgo, documentos de PoI), financiero (métodos de pago, transacciones) | | **Revisión KYC** | Identidad (todos los campos), resumen de la verificación | Ninguna de las plantillas predefinidas configura de antemano la asignación, el escalado, la revisión a 4 ojos ni la transferencia; esas decisiones de enrutamiento siempre te corresponden a ti en cada blueprint. ## Contenido del caso La pestaña **Contenido del caso** controla qué pestañas y campos aparecen en la página del caso, mediante seis secciones que se pueden activar o desactivar: | Sección | Campos | | - | - | | **Lista de verificación** | Activar, hacerla opcional para la resolución y la lista de elementos de la lista de verificación; consulta [Lista de verificación](https://docs.didit.me/es/console/case-management/checklist.md) | | **Control AML** | Información AML financiera, información AML de identidad | | **Identidad** | Información personal, etiquetas del solicitante, información de contacto, resumen de riesgo, documentos de identidad, comprobantes de domicilio | | **Verificaciones** | Resumen de verificaciones | | **Informes** | Informes para la FIU | | **Datos y fuentes financieras** | Métodos de pago, transacciones financieras | Un blueprint sin ninguna sección activada sigue mostrando la pestaña Resumen del caso, solo que sin los bloques de contenido adicionales. > [!TIP] > > Usa un plazo predeterminado en la política para dar a los nuevos casos un periodo de revisión uniforme. > Los revisores pueden seguir actualizando la prioridad y la fecha de vencimiento de un caso concreto. > Editar la política no cambia los plazos de los casos existentes. ## Eliminar un blueprint Eliminar un blueprint siempre se completa correctamente y no afecta a sus casos: los casos existentes conservan su referencia al blueprint, y su configuración (secciones de contenido, escalado, transferencia, emparejamiento de cuatro ojos) se les sigue aplicando. Un blueprint eliminado ya no aparece en las listas de blueprints y ya no se puede elegir como destino de una transferencia. Si se elimina un blueprint de creador (maker) mientras una de sus resoluciones está pendiente de aprobación conforme al principio de cuatro ojos, una resolución rechazada deja el caso en el blueprint de verificador (checker) en lugar de devolverlo. Para retirar un blueprint de forma ordenada, transfiere sus casos activos a otro blueprint antes de eliminarlo. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.