El ciclo de vida de Maestro Case: del desencadenador de eventos a la experiencia de la aplicación

Ciclo de vida de Maestro Case desde los desencadenadores de eventos a través de los datos de la entidad del caso, las reglas del plan del caso, las decisiones del gestor de casos, la ejecución de tareas y las experiencias de la aplicación de casos.

Información general

Un caso es un objeto empresarial de larga duración (una reclamación, disputa, investigación, préstamo) que supera a cualquier tarea o sesión y se mueve de forma no lineal a través de etapas a medida que se acumulan datos y decisiones. Maestro Case impulsa ese ciclo de vida de principio a fin: un evento crea el caso, un plan de caso define las posibles etapas y las reglas que rigen las transiciones, el gestor de casos decide qué sucede a continuación utilizando la orquestación de reglas primero con el agente de Case Manager alternativo, y el caso La aplicación expone el trabajo en vivo a los usuarios empresariales.

Este documento rastrea los datos a través de cada capa de la pila: desencadenadores → Entidad de caso [Próximamente] → Plan de caso → Gestor de casos → tareas → experiencia de runtime, para que puedas formar un modelo mental preciso antes de diseñar tu primer plan de caso.

Audiencia: de intermedio a avanzado: Automation Developers, Arquitectos de soluciones, Arquitectos empresariales

Por qué entender la pila completa

Maestro Case no es una característica única. Es un sistema coordinado de definiciones en tiempo de diseño (plan de caso, entidad de caso [Próximamente], etapas, tareas, reglas) y motores de tiempo de ejecución (Gestor de casos, aplicación de casos, gestión de instancias de casos). Comprender el ciclo de vida completo te ayuda a:

• Diseña planes de casos sólidos que tengan en cuenta la naturaleza no lineal del trabajo del mundo real.
• Evita errores comunes como la secuenciación de etapas rígida, la propiedad de campo poco clara o la falta de lógica de reentrada.
• Comunícate entre roles : desde el desarrollador que modela las etapas en Studio Web hasta el asistente social que completa tareas en la aplicación de casos.

Arquitectura de un vistazo

La pila de Maestro Case consta de cinco capas. Los datos fluyen hacia abajo desde los orígenes de eventos a través de la orquestación y la ejecución, y emergen hacia arriba en la experiencia del usuario empresarial.

Las siguientes secciones recorren cada capa en el orden en que viajan los datos.

Capa 1: desencadenadores de eventos (cómo comienza un caso)

Los desencadenadores de eventos son los puntos de entrada que crean una instancia de caso e hidratan la entidad del caso [Próximamente] con datos iniciales. Un solo plan de caso puede definir varios desencadenadores para que el mismo tipo de caso pueda originarse desde diferentes canales.

Origen del desencadenador	Descripción	Ejemplo
Entidad de Data Fabric	Se mostrará un mensaje "Fila creada" en una entidad de Data Fabric o VDO inicia el caso. Los campos de entidad se convierten en campos de caso.	Una nueva fila en una entidad Reclamaciones de hogar crea un caso de seguro de propiedad.
Esperar al conector	Un evento del conector de Integration Service (llamada a la API, webhook, mensaje) inicia el caso. La carga útil de la API se trata como la entidad del caso.	Un mensaje de canal de Microsoft Teams desencadena una etapa Retirado.
Portal/Formulario	Un usuario envía datos a través de un formulario web.	Un empleado envía un informe de gastos a través de un portal de autoservicio.
Correo electrónico	Se analiza un correo electrónico entrante y sus datos se asignan a campos de entidad.	Un correo electrónico de recibo reenviado crea un nuevo elemento de línea de reclamación.
API	Un sistema externo llama al punto final de creación de casos.	Un sistema ERP desencadena un caso de reclamación en un evento de política.
Programado	Un desencadenador basado en el tiempo crea o realiza un seguimiento de los casos.	Un trabajo diario crea casos de seguimiento para elementos obsoletos.

Cada desencadenador asigna sus datos entrantes a los campos de la entidad del caso. Esta asignación inicial, a veces llamada hidratación , determina los datos que están disponibles para cada etapa, tarea y condición de transición posteriores.

Nota:

Un plan de caso puede tener más de un desencadenador. Por ejemplo, un caso de reclamaciones de seguros puede aceptar envíos de un portal, un analizador de correo electrónico y una API de transcripción de llamadas telefónicas, todos asignados a la misma entidad AutoInsuranceClaim.

Capa 2: la entidad del caso (única fuente de verdad)

La entidad de caso [Próximamente] es el objeto de datos estructurado y persistente en el centro de cada instancia de caso. Vive durante toda la vida del caso y sirve como la única fuente de verdad de la que leen y escriben todas las etapas, tareas y condiciones de transición.

Objetos de datos listos para usar

Cada proyecto de caso crea automáticamente tres objetos de datos:

Objeto	Propósito
Entidad del caso	El modelo de datos empresariales central. Contiene datos estructurados utilizados por condiciones y tareas.
Documentos del caso	Archivos adjuntos y archivos asociados al caso (recibos, fotos, contratos).
Comentarios del caso	Notas, anotaciones y comunicaciones añadidas por los participantes a lo largo del ciclo de vida.

Los tres comparten un campo de sistema caseID inmutable que se genera automáticamente en la creación de casos y vincula todos los datos del caso.

Cómo llegan los datos a la entidad

Origen	Mecanismo
Nativo de Data Fabric (recomendado)	Crea una entidad empresarial en Data Fabric y vincúlala al caso.
VDO en Data Fabric	Registra un origen de datos externo como objeto de datos virtual y vincula el VDO.
Carga útil del desencadenador de casos	Pasar datos a través del desencadenador (por ejemplo, un conector API). Los campos de carga útil se convierten en campos de caso.

Por qué importa una entidad central

• Independencia de la tarea : no es necesario que las tareas se conozcan entre sí. Cada tarea lee y escribe en la entidad a través de asignaciones de entrada/salida.
• Contexto de orquestación : el Gestor de casos evalúa las reglas de transición en función de los campos de entidad. Cuando una tarea escribe adjusterDecision = "approve" de nuevo en la entidad, las reglas de entrada posteriores que hacen referencia a adjusterDecision se evalúan inmediatamente.
• Pista de auditoría : cada cambio en la entidad se realiza un seguimiento con quién, cuándo y qué cambió.
• Fuente única de verdad : no hay ambigüedad sobre el estado actual del caso para cualquier participante o sistema.

El patrón de reescritura

El patrón de reescritura es el mecanismo principal para mover datos a través de un caso:

1. Una tarea lee campos específicos de la entidad de caso a través de la asignación de entrada.
2. La tarea realiza su trabajo (validación, razonamiento de agente, revisión humana, extracción de RPA).
3. La tarea escribe sus resultados en la entidad del caso a través de la asignación de salida.
4. Los valores de entidad actualizados hacen que las reglas de transición se vuelvan a evaluar, lo que puede activar la siguiente etapa o tarea.

Task A writes → Case Entity updates → Rules evaluate → Next stage activates

Este patrón mantiene las tareas desacopladas. Un mensaje "Política de validación" del conector y una tarea "Analizar fotos" la tarea del agente no se comunica directamente. En cambio, cada uno enriquece la entidad, y el Gestor de casos lee la entidad para decidir qué sucede a continuación.

Nota:

Diseña tu esquema de entidad para que cada campo esté escrito exactamente por una tarea. Si varias tareas escriben en el mismo campo, el último escritor gana y los datos anteriores se pierden. Utiliza campos de espacio de nombres (por ejemplo, validation.result frente a categorization.result) para evitar colisiones.

Capa 3: el plan del caso (proyecto en tiempo de diseño)

El plan del caso es el proyecto visual que creas en Studio Web. Define las posibles fases por las que puede moverse un caso y las reglas que rigen las transiciones. A diferencia de un flujo de trabajo lineal, un plan de caso no prescribe una única ruta fija. La ruta real se determina en runtime en función de los datos y las decisiones.

Un plan de caso consta de cuatro elementos:

• Desencadenadores de eventos : los eventos que crean o influyen en una instancia de caso (descritos en la Capa 1).
• Etapas : las fases nombradas del caso.
• Tareas : los elementos de trabajo dentro de cada etapa.
• Reglas : las definiciones CUANDO/SI/ACCIÓN que rigen la entrada, finalización, salida y reingreso de etapas y tareas.

Estados

Las etapas son las fases principales por las que se mueve un caso, por ejemplo, Admisión, Revisión, Acuerdo, Cierre. Una etapa es, en efecto, una colección de tareas que hacen avanzar el caso hacia la regla completa de la etapa. Maestro Case admite dos tipos de etapas:

Tipo de etapa	Propósito	Cómo se alcanza	Visibilidad en la aplicación de casos
Etapa primaria	La progresión esperada del caso (por ejemplo, Admisión → Revisión → Acuerdo → Cierre).	Se puede introducir a través de bordes desde una etapa anterior en el lienzo, o por su regla de entrada configurada.	Se muestran como nodos de etapa central en la línea de tiempo de la aplicación de caso: el ciclo de vida principal que ven los asistentes sociales.
Etapa secundaria	Excepción o rutas alternativas que pueden ocurrir en cualquier momento (por ejemplo, Pendiente con el cliente, Denegado, Retirado).	Sin bordes entrantes : al alternar secundarios se eliminan. Solo se alcanza cuando su regla de entrada se evalúa como verdadera y puede activarse en cualquier punto del caso.	Aparece por separado cuando está activo (no forma parte de la línea de tiempo principal).

Cada etapa define:

• Regla de entrada : cuando se activa la etapa. Lleva un conmutador de interrupción que controla el comportamiento de toma de control. Valores predeterminados: etapas principales = false (paralelo); etapas secundarias = true (toma de control).
• Regla completa : el final normal (por ejemplo, cuando se realizan las tareas requeridas). Realiza una acción (completar/salir del caso, esperar a la selección manual, volver al origen).
• Regla de salida : un rescate temprano cuando el procesamiento continuo no tiene sentido. Incluye las mismas opciones de acción que la regla completa.
• Regla de reentrada : cómo la revisión devuelve el caso a una etapa previamente completada.
• SLA de etapa y escaladas : hora de vencimiento, umbrales de advertencia y destinatarios de la escalada.

Las etapas pueden marcarse como obligatorias u opcionales. Un caso no puede cerrarse hasta que se hayan completado todas las etapas necesarias. Las etapas opcionales se activan solo cuando se cumplen sus reglas de entrada y el caso puede cerrarse sin ellas.

Varias etapas pueden estar activas en el mismo caso al mismo tiempo. Si las etapas se ejecutan en paralelo o en secuencia se controla mediante reglas de entrada y su alternancia de interrupción.

Tareas

Una tarea es una unidad de trabajo discreta dentro de una etapa. Cada tarea tiene un tipo que determina cómo se realiza el trabajo:

Tipo de tarea	Lo que hace
Acción humana	Presenta un formulario, aprobación o revisión a una persona en la aplicación de caso.
Agente IA (UiPath)	Invoca un agente de IA de UiPath para el razonamiento autónomo sobre los datos.
Agente externo	Llama a un agente de IA de terceros fuera de UiPath (por ejemplo, a través de la API).
Flujo de trabajo de RPA	Desencadena un UiPath Robot para la automatización de IU en sistemas heredados.
Flujo de trabajo de API	Llama a un sistema externo a través de una solicitud de API personalizada.
Ejecutar conector	Llama a un sistema externo a través de un conector de Integration Service prediseñado o personalizado.
Proceso agéntico de Maestro	Invoca un BPMN de Maestro como una tarea, con su propia orquestación, y devuelve un resultado al caso principal.
Caso secundario	Genera una definición de caso independiente como secundaria, vinculada al principal a través de caseID.
Esperar temporizador	Se detiene hasta que transcurre una duración o se alcanza una fecha objetivo.
Esperar el evento del conector	Se detiene hasta que llega un evento externo a través de un conector.

Independientemente de su tipo, cada tarea se ejecuta en uno de los tres modos de ejecución que determinan cuándo se inicia:

• Secuencial : la tarea se ejecuta en un orden definido dentro de la etapa. Las secuencias pueden incluir ramas paralelas que se abren en abanico y se vuelven a unir.
• Impulsada por eventos : la tarea tiene una regla de entrada y se activa cada vez que el evento hace que la regla se evalúe como verdadera. Puede activarse varias veces si el evento se repite.
• Ad-hoc : la tarea se define en el plan del caso, pero solo se inicia cuando un usuario la desencadena manualmente en runtime.

Varias tareas pueden estar activas en la misma etapa al mismo tiempo : ramas paralelas secuenciales, tareas impulsadas por eventos que se activan independientemente de la secuencia y tareas ad-hoc lanzadas junto con el trabajo en ejecución.

Cada tarea está configurada con:

• Entradas/Salidas : asignadas a y desde la entidad del caso [Próximamente] .
• Indicador obligatorio : determina si la etapa principal debe esperar a esta tarea.
• Regla de entrada : necesaria para tareas impulsadas por eventos; opcional para tareas secuenciales y ad-hoc (donde actúa como guardia).
• Ejecutar solo una vez : si true, la tarea se omite al volver a entrar en la etapa y se conserva su salida anterior; si false (predeterminado), la tarea se vuelve a ejecutar en cada reingreso, produciendo una nueva salida.
• Asignación y SLA : para acciones humanas, quién debe hacer el trabajo y cuándo vence.

Reglas

Las reglas son el mecanismo que controla el movimiento del ciclo de vida. Siguen el patrón CMMN (Modelo y Notación de Gestión de Casos) y están impulsadas por eventos : una regla se activa solo cuando se produce un evento relevante en el caso. Cada regla tiene tres partes:

• CUANDO : el evento que desencadena la evaluación. Los eventos son de dos tipos:
  • Eventos internos emitidos por el propio ciclo de vida del caso: CaseCreated, StageEntered, StageCompleted, StageExited, TaskCompleted, CaseSlaAtRisk, CaseSlaBreached, StageSlaAtRisk, StageSlaBreached y cambios en la entidad del caso campos escritos por tareas.
  • Eventos externos que llegan desde fuera del caso: eventos del conector de Integration Service (webhooks, mensajes de cola), activaciones de temporizador, finalización o salida de casos secundarios y llamadas directas a la API al caso.
• SI (opcional) : una condición sobre la entidad del caso que también debe ser verdadera para que la regla surta efecto. Si se omite, la regla se activa en cada evento WHEN coincidente.
• ACCIÓN : lo que hace la regla cuando se activa (iniciar una etapa, completar una etapa, salir de una etapa, completar el caso, etc.).

Las reglas tienen un ámbito de uno de tres niveles:

Ámbito	Tipos de reglas	Propósito
Caso	Caso completo, salida de caso	Finalizar o cancelar el caso.
Estado	Entrada, Completo, Salida, Reingreso	Controla la activación de la etapa, la finalización normal, el rescate temprano y la revisión. Las reglas de entrada a etapa llevan un conmutador de interrupción ; Las reglas Completar y Salir llevan a cabo una acción (completar/salir del caso, esperar a la selección manual, volver al origen).
Tarea	entry	Gate cuando se inicia una tarea. Lo utilizan las tareas impulsadas por eventos para desencadenar un evento desencadenador y, opcionalmente, las tareas secuenciales o ad-hoc para proteger la ejecución.

La distinción entre Salir y Completar en el nivel de etapa es importante. Una regla Completa se activa cuando el trabajo finaliza normalmente. Una regla de salida se activa cuando un cambio en los datos hace innecesario el procesamiento continuo: actúa como un interruptor automático. Ambos dan como resultado que el Gestor de casos aplique la acción de la regla y evalúe lo que sucede a continuación.

Capa 4: el gestor de casos (orquestación de runtime)

El Gestor de casos es el orquestador impulsado por eventos de cada caso. Impulsa las decisiones del ciclo de vida (qué etapa activar a continuación, qué tareas iniciar, cuándo una etapa debe completarse o salir antes de tiempo y cuándo escalar) en función de los eventos que llegan al caso.

Se orquesta utilizando dos métodos complementarios:

1. Reglas (primarias) : reglas CMMN deterministas definidas en el plan del caso. Para cada punto de decisión, el gestor de casos evalúa primero las reglas aplicables. Si una regla resuelve la decisión, se toma. Esto mantiene las rutas felices de alto volumen predecibles, auditables y económicas.
2. Razonamiento del agente (alternativa) : cuando ninguna regla cubre la situación (un vacío, una excepción o una decisión de juicio), el agente gestor de casos razona sobre la entidad del caso, el plan del caso y las políticas configuradas para elegir la siguiente acción. Esto permite que los casos sigan moviéndose sin escalar a un humano por cada rama descubierta.

Cómo procesa un evento el gestor de casos

La siguiente secuencia se repite a lo largo de la vida del caso:

1. Evento recibido : se activa un desencadenador, se completa una tarea, cambia un campo de entidad de caso, llega un evento de temporizador o conector, o una etapa transiciona.
2. Evaluación de reglas : el gestor de casos evalúa todas las reglas aplicables a nivel de caso, etapa y tarea cuyo CUÁNDO coincida con el evento y cuya condición SI (si está presente) se mantiene. Se aplican las acciones de regla coincidentes (activar una etapa, completar una etapa, salir de una etapa, etc.).
3. Alternativa del agente : para las decisiones no cubiertas por una regla determinista, el agente gestor de casos razona sobre el estado del caso y las políticas para elegir la siguiente acción.
4. Actualización de estado : transición de etapas y tareas; la entidad del caso se actualiza; pueden emitirse nuevos eventos, desencadenando el siguiente ciclo.
5. Finalización de caso : cuando se activa una regla de salida Caso completo o Caso (o el agente decide que el caso ha terminado), el caso se cierra.

Las reglas y el agente trabajan juntos

Las reglas cubren lo predecible: "Si el ajustador lo aprueba y el importe es inferior a 50 000 $, introduzca la liquidación"; El agente cubre lo impredecible: un documento que falta sin una ruta de política clara, un patrón de fraude de caso límite o una combinación inusual de condiciones. El gestor de casos siempre prueba las reglas primero y recurre al agente solo cuando las reglas no coinciden.

Configuración del agente de Case Manager

El agente de Case Manager está configurado con:

• Un modelo (el LLM que impulsa el agente).
• Una solicitud de usuario (políticas, restricciones e instrucciones de comportamiento).
• Herramientas (acciones que puede realizar el agente, como mover una etapa, escalar o actualizar la entidad).
• Contexto (acumulado automáticamente a partir del historial de ejecución, resultados de tareas y cambios de entidad).
• Una política de escalada (condiciones en las que el agente escala a un humano en lugar de actuar de forma autónoma).

Nota:

Cuando ni las reglas ni el agente del gestor de casos pueden resolver una decisión, debido a datos ambiguos, políticas en conflicto o un escenario fuera de la autoridad del agente, el gestor de casos escala a un humano a través del perfil configurado.

Capa 5: la experiencia de runtime

En runtime, dos interfaces exponen datos de casos y controles a diferentes audiencias.

Aplicación de casos (para usuarios empresariales)

La aplicación de casos es el espacio de trabajo orientado al usuario empresarial donde los trabajadores de casos y los gestores de casos interactúan con instancias de casos en vivo. Aparece:

• Lista de casos : una vista filtrable de todas las instancias de casos con indicadores de estado, prioridad y SLA (en buen camino, en riesgo, incumplido).
• Vista de detalles del caso : la etapa actual, los datos de la entidad del caso, los estados de las tareas, la línea de tiempo de los eventos y el seguimiento de auditoría completo.
• Bandeja de entrada de tareas (Mi trabajo) : tareas humanas pendientes de acción: formularios, aprobaciones, revisiones.
• Acciones rápidas : acciones contextuales basadas en el rol y la etapa actual: completar, reabrir, reasignar, escalar, añadir notas.

La aplicación de casos viene en dos opciones: una aplicación de casos lista para usar (un espacio de trabajo prediseñado y sin código que se envía con Maestro Case) y una aplicación de casos codificada personalizada (creada con el SDK de TypeScript de código profesional para vistas y flujos de trabajo personalizados). La aplicación lista para usar es configurable en tiempo de diseño: en Studio Web, selecciona Configurar aplicación de caso en la configuración de Maestro Case para definir el título del caso y el diseño de detalles del caso.

Una sola definición de plan de caso genera una aplicación de caso que gestiona miles de instancias de casos individuales, cada una en un punto diferente de su ciclo de vida.

Gestión de instancias de casos (para operadores)

Gestión de instancias de casos es la consola de operaciones de Maestro donde los operadores de procesos supervisan el estado de todos los casos en ejecución e intervienen cuando surgen problemas.

Acción del operador	Descripción
Pausar	Detener temporalmente un caso en ejecución. Los temporizadores de SLA se ponen en pausa. No se activa ninguna tarea hasta que se reanude.
Reanudar	Reiniciar un caso en pausa. Los temporizadores de SLA se reanudan desde donde se detuvieron.
Cancelar	Terminar un caso de forma permanente. Todas las tareas en ejecución se detienen.
Migrar	Mueva una instancia de caso en vivo a una versión más reciente del plan del caso después de una corrección o actualización, conservando el estado y los datos actuales.
Reintentar	Vuelve a ejecutar una tarea o transición fallida para recuperarte de errores transitorios.

Cuando un caso entra en estado de error (falla una tarea, se agota el tiempo de espera de una integración o el caso se bloquea), se convierte en un incidente de caso. Los operadores utilizan la consola de gestión de instancias para diagnosticar y resolver incidentes con las acciones anteriores.

Nota:

• La aplicación de casos es para usuarios empresariales (trabajadores de casos, gestores) que trabajan en casos individuales.
• La gestión de instancias de casos es para operadores de procesos que supervisan el estado del sistema e intervienen cuando las cosas van mal.

Seguimiento de datos de extremo a extremo: un tutorial

Para concretar el ciclo de vida, considera un caso de reclamaciones de seguro de propiedad:

1. Se activa el desencadenador de eventos. Se crea una nueva fila en una entidad de Data Fabric de reclamaciones de inicio. El desencadenador asigna campos de entidad (número de póliza, nombre del reclamante, descripción de la pérdida) en la entidad del caso [Próximamente] y crea una instancia de caso con la clave HO-1234.

2. El Gestor de casos activa la primera etapa. La regla de entrada para la admisión se evalúa como verdadera (CUANDO llegue el evento CaseCreated ). La etapa se activa.

3. Las tareas se ejecutan dentro de Admisión. Una tarea de extracción (Agente AI) procesa los detalles de la reclamación. Una tarea de búsqueda (Ejecutar conector) verifica la política. Un agente de detección de anomalías comprueba las reclamaciones históricas. Cada tarea escribe los resultados en la entidad del caso.

4. La admisión se completa, la revisión se activa. Cuando todas las tareas de admisión necesarias finalizan y validationPassed == true, se activa la regla Admisión completa . El gestor de casos evalúa las reglas de entrada para las siguientes etapas y activa Revisión.

5. Tareas de revisión ejecutadas. Un conector de comprobación de cobertura, una tarea de verificación de oficial de reclamaciones humano y un agente de auditoría producen salidas. El oficial de reclamaciones escribe decision = "Approve" de nuevo en la entidad.

6. Enrutamiento condicional en Revisión. Las reglas Revisión completa y Salida evalúan el campo decision . Si "Approve", se activa la regla Completo y el caso pasa a Acuerdo. Si "Reject", la regla de salida se activa y dirige el caso a la etapa secundaria Denegado . Si "Claim is missing key incident reports", la regla de reingreso envía el caso de nuevo a Admisión, volviendo a ejecutar solo las tareas cuya runOnlyOnce es false (por ejemplo, el robot de informes de incidentes y el agente de anomalías).

7. Se ejecutan las tareas de liquidación. Un proceso de cumplimiento, un proceso de liquidación y un agente de comunicaciones gestionan el pago y las notificaciones. Cada uno escribe de nuevo en la entidad.

8. Caso cerrado. Cuando se completan todas las etapas necesarias, el caso alcanza un estado terminal. Se conserva la pista de auditoría completa: cada ejecución de tarea, cambio de entidad, decisión y marca de tiempo.

9. A lo largo del ciclo de vida, un asistente social ve las tareas asignadas en la bandeja de entrada Mi trabajo de la aplicación de casos. Un gestor de casos supervisa la cartera, reasigna tareas y gestiona las escaladas. Un operador observa incidentes en la consola de gestión de instancias de casos.

SLA y escaladas a lo largo del ciclo de vida

Los SLA añaden una dimensión de tiempo al ciclo de vida:

Nivel de SLA	Ámbito	Ejemplo
SLA a nivel de caso	Objetivo general desde la creación hasta el cierre.	Resolver en 48 horas.
SLA a nivel de etapa	Hora de vencimiento localizada para una etapa específica.	Complete la revisión en 24 horas.

Los estados de SLA ( en buen camino, en riesgo e incumplido ) aparecen como insignias en las vistas de lista y detalle de la aplicación de casos. Las reglas de escalado se desencadenan automáticamente:

• En riesgo : el SLA se está acercando a su límite. Notifica al propietario y al supervisor del caso.
• Incumplido : se ha superado el SLA. Reasignar a un trabajador sénior o escalar a la dirección.
• Pausar/Reanudar : los temporizadores de SLA no se pausan automáticamente. Un caso en espera de una entrada externa sigue acumulando tiempo de SLA hasta que un operador pausa explícitamente la instancia del caso.

Roles de usuario en el ciclo de vida

Maestro Case aplica el acceso consciente de la etapa para que las personas adecuadas vean y actúen en el momento adecuado.

Rol	Responsabilidad
Asistente social	Completa tareas humanas y actualiza los campos permitidos dentro de las etapas a las que tiene acceso. Ve el trabajo asignado en Mi trabajo.
Gestor de casos	Supervisa una cartera. Puede reasignar, escalar y (según política) volver a abrir. Puede realizar acciones en el nivel de etapa como pausar y reanudar.

Para cada etapa, el Plan del caso define qué personas pueden ver y cuáles pueden actuar (completar tareas, reasignar, escalar, pausar). Las tareas heredan la configuración de la etapa, pero pueden restringir aún más a los asignados.

Nota:

Los roles de usuario de casos completos y los controles de acceso a nivel de etapa aún no están disponibles.

Principios arquitectónicos clave

Principio	Explicación
Agente primero	Los agentes de IA son participantes de primera clase, tanto como trabajadores de tareas dentro de las etapas como como el agente gestor de casos que orquesta todo el caso. Los humanos intervienen solo cuando la política o el juicio lo requieren.
No lineal por diseño	Las reglas de reingreso, las etapas secundarias, las tareas impulsadas por eventos y las tareas ad-hoc permiten que los casos sigan la ruta que dictan los datos, no una secuencia rígida.
Centrado en la entidad	La entidad de caso [Próximamente] es la única fuente de verdad. Las tareas son productores y consumidores desacoplados de datos de entidad.
Reglas primero, agente segundo	Las reglas CMMN deterministas manejan las rutas felices de alto volumen. El agente de Case Manager gestiona las excepciones y la ambigüedad, y escala a humanos cuando ni las reglas ni el agente pueden decidir.
Separación entre tiempo de diseño y tiempo de ejecución	El plan del caso es lo que se diseña en Studio Web. La aplicación de caso y la consola de gestión de instancias son lo que los usuarios empresariales y operadores utilizan todos los días. Un solo plan de caso sirve a miles de instancias de casos.

Recursos relacionados

• Conceptos básicos en Maestro Case : definiciones de referencia para claves de caso, entidades, etapas, tareas, reglas y SLA.
• Descripción general del Diseñador de planes de casos : cómo modelar planes de casos en Studio Web.
• Configurar reglas de etapa : orientación detallada sobre las reglas de entrada, finalización, salida y reingreso.
• Descripción general de la aplicación de caso : lo que ven los usuarios empresariales y cómo configurar el diseño de la aplicación de caso.
• Gestión de instancias de casos : acciones del operador para supervisión, resolución de incidentes y migración en vivo.