> ## 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. # Gestión de casos: casos y ciclo de vida > Didit permite abrir, gestionar y resolver casos de investigación vinculados a un usuario o empresa, con vistas guardadas, SLA y acciones masivas. La gestión de casos es el centro de investigación de la Didit Console. Cualquier coincidencia AML, verificación marcada o transacción sospechosa puede convertirse en un **caso** que tu equipo de cumplimiento gestiona desde su apertura hasta su resolución, con un registro de auditoría completo. *** ## Ciclo de vida Un caso pasa exactamente por tres estados: | Estado | Significado | | - | - | | `Open` | En investigación activa | | `Awaiting user` | En pausa mientras se recopila más información del usuario verificado | | `Resolved` | Investigación completada, con una resolución registrada | Para resolver un caso es obligatorio indicar una resolución: | Resolución | Significado | | - | - | | `False positive` | La actividad era legítima | | `Valid threat` | Actividad sospechosa o fraudulenta confirmada | Cada caso tiene además una **prioridad** (`Low`, `Medium`, `High`; por defecto `Medium`) y una **fecha límite** opcional que determina la ordenación por SLA y los indicadores de casos vencidos. > [!NOTE] > > No existe ningún estado `Under review`, `On hold` ni `Pending approval`, ninguna gravedad `Critical` ni ninguna clasificación por tipo de caso. El ciclo de vida es fijo a propósito para que las analíticas, los SLA y los permisos sean inequívocos en todos los casos, independientemente de cómo se hayan creado. ## Un sujeto por caso Cada caso está vinculado a **exactamente un** usuario o una empresa. No puedes mezclar sujetos en un mismo caso ni adjuntar una sesión, una sesión de empresa o una transacción que pertenezca a un sujeto distinto del caso: si lo intentas, se devuelve un error explícito. Así cada página de caso se mantiene centrada: la tarjeta del sujeto, el resumen de riesgo, los documentos y los datos financieros describen la misma persona o empresa que se investiga en el caso. Para revisar una segunda entidad, abre (o crea) un caso independiente. ## Contexto de origen de Fraud Check Al crear un caso a partir de una sesión de Fraud Check se conservan su ID de comprobación, su ID de solicitud y la sección que abrió el revisor. La tarjeta de origen también registra el estado del analista de la sesión en el momento de crear el caso. La decisión del caso y la decisión de origen se mantienen separadas. Los clientes de la API pueden enviar `source_context` con `check_id`, `request_id` y `source_section` al crear un caso. Incluye esa solicitud como una entrada `session` en `links`. La comprobación y la sesión vinculada deben pertenecer a la aplicación seleccionada y estar relacionadas entre sí. La API lee por sí misma el estado del analista y rechaza en este contexto los campos de estado, recomendación o tipo de origen enviados por el cliente. ## Listas En la navegación superior de Gestión de casos están disponibles **Casos**, **Resumen** y **Asignación**. El espacio de trabajo de Casos ofrece las vistas de estado **Abierto**, **En espera del usuario**, **Resueltos** y **Todos**. En escritorio, al abrir un caso la cola de casos se mantiene junto a sus detalles. En el móvil, usa la ruta de navegación para volver a la cola. La búsqueda encuentra coincidencias por nombre o ID del sujeto, etiqueta, número de caso, título del caso, ID de sesión vinculada e ID de transacción vinculada, de modo que puedes pegar el UUID de una sesión o de una transacción e ir directamente a su caso. Chips de filtro: **Plantilla**, **Creada**, **Origen**, **Asignado**, **Etiqueta**, además de **Agregar filtro** para **Prioridad** y **Vencimiento**. Columnas: Creada (fecha y creador), Detalles del caso (título), Estado, Plantilla, Sujeto (nombre e ID), Etiquetas del sujeto, Asignado, Prioridad y Fecha de vencimiento, con más columnas disponibles mediante el desplazamiento horizontal y la configuración de columnas. ### Ordenación y SLA Ordena por **Fecha de creación** (por defecto) o por **Fecha de vencimiento**. Al ordenar por fecha de vencimiento, los casos vencidos aparecen primero; un caso está vencido cuando su fecha de vencimiento ha pasado y sigue en estado Abierto o En espera del usuario, y se muestra con una etiqueta de vencimiento en rojo. ### Vistas guardadas Guarda la combinación actual de filtros y columnas como una vista con nombre mediante **Guardar vista**, cambia de una vista a otra con **Seleccionar una vista** y restablece los filtros con **Borrar filtros**. Las vistas son personales y se conservan del mismo modo que las demás preferencias de tablas de la consola. ### Acciones masivas Selecciona varios casos para: * **Asignar a** un responsable. Todos los casos seleccionados deben compartir la misma plantilla; si no es así, la consola te avisa antes de enviar. * **Establecer estado** en el estado de En espera del usuario, Reabrir o Resolver (con una resolución y una nota opcional). Cada caso se evalúa de forma independiente, de modo que un caso bloqueado por una lista de comprobación incompleta o por falta de una nota obligatoria se notifica individualmente sin que falle el resto del lote. ### Exportaciones El menú de la lista ofrece dos exportaciones CSV, que se entregan a través de la [página Informes](https://docs.didit.me/es/console/export-pdf-csv.md): * **All cases report**, una fila por caso con estado, resolución, prioridad, etiquetas, transacciones vinculadas y el último informe presentado ante la FIU. * **SLA report**, métricas de tiempos por caso: horas hasta la asignación, horas hasta la resolución, y marcas de vencido y de SLA cumplido. ## Acciones sobre el sujeto y reintentos La tarjeta del sujeto permite a los revisores autorizados cambiar el estado del sujeto, añadir etiquetas, añadir una nota interna o añadir el sujeto a la lista de bloqueo. Estas acciones son independientes de la resolución del caso. La sección **Subject actions** registra cada acción solicitada como **Applied** o **Failed** e identifica a su revisor y la hora. Usa **Retry action** para reintentar una acción fallida después de revisar el sujeto actual. Una acción aplicada no se vuelve a ejecutar cuando se reintenta su solicitud. Los clientes de la API deben enviar un `client_reference` único con cada solicitud al endpoint `entity-actions/` del caso. Mantén la misma referencia y los mismos datos de entrada al reintentar una solicitud tras un error de conexión. Unos datos de entrada distintos con la misma referencia devuelven `409`. Cuando se envía una referencia, revisa `receipt.status`: una respuesta `200` puede contener un comprobante fallido, lo que significa que la acción no se aplicó. Para reintentar una solicitud fallida es necesario `retry: true` o una llamada a su endpoint `action-receipts/{receipt_uuid}/retry/`. El endpoint de historial devuelve como máximo 20 comprobantes por página y proporciona `next_offset` para obtener más resultados. Los clientes de la API existentes que omiten `client_reference` mantienen su comportamiento de respuesta anterior. ## Etiquetas Añade etiquetas a un caso desde su encabezado (**Añadir etiqueta**) para agrupar investigaciones relacionadas, o filtra y busca por etiqueta desde la lista. Los cambios en las etiquetas quedan registrados en la cronología del caso. ## Páginas relacionadas > [card] [Crear casos](https://docs.didit.me/es/console/case-management/creating-cases.md) > > Todos los puntos de entrada: usuarios, empresas, sesiones, transacciones y conectores automáticos. > [card] [Blueprints](https://docs.didit.me/es/console/case-management/blueprints.md) > > Configura la asignación, la escalada, la transferencia y el contenido de la página del caso. > [card] [Checklist](https://docs.didit.me/es/console/case-management/checklist.md) > > Condiciona la resolución a pasos de investigación obligatorios. > [card] [Revisión de 4 ojos](https://docs.didit.me/es/console/case-management/four-eyes.md) > > Aprobación maker/checker para resoluciones sensibles. ## Mensajes al cliente Usa **Enviar mensaje** para previsualizar una solicitud predeterminada o una actualización de revisión dirigida a un contacto verificado. Consulta [Mensajes al cliente](https://docs.didit.me/es/console/case-management/customer-messages.md) para conocer los estados de entrega, las respuestas seguras y el flujo de la API. ## Discusión y notas fijadas Selecciona el botón de discusión junto al estado del caso para revisar las notas sin salir de la investigación. Usa el menú de una nota para responderla o fijarla. Las notas fijadas aparecen primero, y las respuestas muestran un breve extracto de la nota a la que responden. Los cambios de fijación quedan registrados en la actividad del caso y no modifican las decisiones de origen. Al confirmar la eliminación, la nota se elimina de forma permanente y su extracto citado desaparece de las respuestas. Las respuestas en sí siguen disponibles. Los archivos adjuntos se eliminan, salvo que otra nota los siga usando. Los clientes de la API pueden indicar un UUID en `client_reference` al añadir una nota. Un reintento sin cambios devuelve la nota existente sin duplicar las notificaciones. Reutilizar esa referencia con contenido modificado o para una nota eliminada devuelve `409`. Indica `reply_to` para hacer referencia a una nota activa del mismo caso, y actualiza `is_pinned` mediante el endpoint `PATCH` de la nota. ## Comprobar si existe una investigación El diálogo compartido Crear caso comprueba si existen investigaciones para el usuario, la empresa o la fuente vinculada seleccionados. Abre un caso existente para seguir revisándolo. Los casos cerrados siguen visibles para que puedas abrirlos y decidir si reabrirlos. Para crear una investigación independiente, introduce un motivo para tratarla como un incidente distinto. El motivo se guarda con el nuevo caso y se muestra en su vista general. La consola vuelve a comprobar si hay duplicados al enviar, incluidos los casos que otro revisor haya creado mientras el diálogo estaba abierto. Las integraciones de API pueden consultar `POST .../cases/duplicates/` y establecer `review_duplicates=true` al crear el caso. Cuando se encuentra una investigación existente, la creación devuelve `409`, salvo que se indique `separate_incident_reason`. El endpoint de revisión de duplicados devuelve hasta 20 casos por página, con `next_offset` para obtener más resultados. Las integraciones de API existentes que omiten esta opción mantienen su comportamiento de creación actual. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.