Introducción a Maestro Case

Conceptos de casos de Maestro para trabajos de larga duración y con muchas excepciones, incluidos casos de uso de gestión de casos, superficies de herramientas y componentes de diseño básicos.

	Caso de Maestro	Maestro BPMN	Flujo de Maestro
El contenido se aplica a	✅	❌	❌

Información general

Maestro Case orquesta un trabajo de larga duración e impulsado por objetivos sobre una situación específica: un caso. Un caso contiene datos, reglas, tareas e historial para impulsar un resultado auditable, como un reembolso, una decisión de reclamación o el cierre de una investigación. Mientras que Maestro BPMN sobresale en la orquestación estructurada y secuencial, Maestro Case aborda escenarios con muchas excepciones, no lineales y dependientes del juicio humano y del agente de IA en puntos de decisión clave.

Este documento presenta Maestro Case como una capacidad distinta en Maestro, repasa los casos de uso empresarial que resuelve y cuándo elegirlo en lugar de Maestro BPMN, te ofrece un recorrido por el conjunto de herramientas con el que trabajarás y establece los conceptos fundamentales que necesitas para comprender antes de crear tu primer caso de agente.

Audiencia: Principiante a intermedio: arquitectos de soluciones, analistas de negocio y desarrolladores que evalúan o comienzan con Maestro Case.

Por qué gestionar casos

La automatización de procesos tradicional funciona mejor cuando el flujo de trabajo es predecible y repetible. Sin embargo, muchos escenarios empresariales no son así. Pueden durar días o semanas, involucrar a varios equipos y requerir decisiones que no pueden automatizarse por completo. En estas situaciones, las excepciones no son raras: se esperan.

La gestión de casos aborda este desafío proporcionando estructura sin rigidez. Permite que la automatización y la IA gestionen el trabajo rutinario o repetible, al tiempo que permite a los humanos intervenir cuando se requieren decisiones de juicio o políticas.

Puntos problemáticos que resuelve la gestión de casos

Punto problemático	Cómo lo aborda la gestión de casos
Sin construcción de casos persistente o seguimiento del ciclo de vida	Introduce una entidad de caso [Próximamente] con ciclo de vida completo, estado e historial
Sin modelado de etapas nativas	Añade un lienzo de etapa visual para definir etapas y transiciones secuenciales
Sin transición en tiempo de diseño o reingreso dirigido	Habilita las transiciones de etapa basadas en reglas y el reingreso a la tarea exacta dentro de una etapa anterior
SLA limitado y control de escalada	Admite el seguimiento de SLA en niveles de caso, etapa y tarea, con reglas de escalada y pausa/reanudar
No hay experiencia unificada para asistentes sociales y gestores	Ofrece la aplicación de casos para colaboración, gestión de tareas y visibilidad
Sin flexibilidad para el trabajo ad-hoc	Permite la creación de tareas ad-hoc en runtime para excepciones o revisiones adicionales

Cuándo utilizar la gestión de casos

La gestión de casos es más eficaz cuando el trabajo no se puede definir completamente por adelantado. Estos escenarios a menudo implican varias etapas, puntos de decisión frecuentes y colaboración entre diferentes grupos de usuarios o sistemas. El progreso no solo depende de completar las tareas, sino de evaluar los resultados y decidir qué debe suceder a continuación.

Escenarios empresariales

Escenario	Por qué gestionar casos
Reclamaciones de seguro	De larga duración, multiparte (reclamante, ajustador, inspector), excepciones frecuentes (documentos faltantes, disputas), impulsado por SLA
Disputas y devoluciones de cargo	Intercambio entre partes, recopilación de pruebas, rutas de escalada, progresión no lineal
Originación y suscripción de préstamos	Múltiples etapas de revisión (crédito, cumplimiento, suscripción), rutas condicionales basadas en puntuaciones de riesgo, requisitos reglamentarios
Corrección KYC/AML	Recopilación de documentos en etapas, puntos de decisión reglamentarios, requisitos de seguimiento de auditoría
Escaladas y quejas de clientes	Resolución escalonada, reingreso cuando una solución no se mantiene, compromisos de SLA, transferencias de varios equipos
Excepciones de cumplimiento de pedidos	Pedidos pendientes, envíos parciales, devoluciones: coordinación multisistema con seguimiento de SLA
Investigaciones y remisiones del sector público	Aprobaciones ad-hoc, coordinación entre departamentos, enrutamiento dependiente de políticas
Incorporación de proveedores	Verificación en varias etapas (legal, cumplimiento, finanzas), etapas condicionales basadas en el tipo de proveedor, colección de documentos

La gestión de casos añade valor cuando

• El trabajo es de larga duración : abarca horas, días o semanas en lugar de segundos.
• El proceso tiene muchas excepciones : el siguiente paso depende de lo que acaba de suceder, y ningún diagrama de flujo único captura todas las rutas.
• Están involucrados varios roles y sistemas : asistentes sociales, gestores, agentes de IA e integraciones externas contribuyen.
• El seguimiento y la escalada de SLA son fundamentales: los plazos importan y las infracciones deben desencadenar acciones específicas.
• Se requieren registros de auditoría : cada decisión, cambio de datos y transición debe registrarse.
• Los bucles de reingreso y revisión son comunes: los casos vuelven con frecuencia a etapas anteriores para correcciones o investigación adicional.

No se requiere la gestión de casos cuando

No todos los procesos necesitan gestión de casos. Si un proceso es de corta duración, predecible y sigue la misma secuencia cada vez, un BPMN de Maestro suele ser más simple y más eficiente.

Nota:

Prueba rápida: si el siguiente paso depende de lo que acaba de suceder y ningún diagrama de flujo puede capturar todas las rutas, considera la gestión de casos. Si el proceso sigue la misma ruta cada vez, utiliza Maestro BPMN.

Fundaciones compartidas

Ambos tipos de proyectos reutilizan los mismos servicios y tipos de tareas de UiPath Platform:

• Flujos de trabajo de RPA para la automatización de IU en sistemas heredados.
• Flujos de trabajo e integraciones de API para operaciones de sistema a sistema.
• Agentes de IA (UiPath o externo) para tareas no deterministas.
• Tareas humanas a través de aplicaciones de acción para formularios, aprobaciones y revisiones.
• Data Fabric para la gestión de datos empresariales y la conectividad de datos.
• Studio Web como entorno de diseño.

Principales diferencias

Dimensión	Maestro BPMN	Caso de Maestro
Estructura de trabajo	Secuencia definida de pasos modelados en notación BPMN	Etapas con nombre con transiciones basadas en reglas; la ruta de runtime se determina dinámicamente
Ciclo de vida	Normalmente de corta a media duración; sigue un flujo predeterminado	Duradero y orientado a objetivos; evoluciona a medida que se dispone de nueva información
Flujo no lineal	Posible a través de puertas de enlace y bucles BPMN, pero complejo de modelar para escenarios altamente variables	Soporte integrado para reingreso, etapas secundarias, reglas de omisión y tareas ad-hoc
Modelo de datos	Variables de proceso en el ámbito de la instancia	Variables de caso en el ámbito de la instancia + Entidad de caso persistente [Próximamente] : un registro empresarial central escrito que todas las etapas, tareas y condiciones leen y escriben
SLA y escaladas	No modelado de forma nativa en el nivel de proceso	Construcciones de primera clase tanto a nivel de caso como a nivel de etapa, con reglas de escalada de riesgo e incumplimiento
Experiencia del usuario	Supervisado a través de la pestaña Supervisión de Maestro para operadores	Aplicación de casos dedicada para usuarios empresariales (lista de casos, vista de detalles, bandeja de entrada de tareas) y gestión de instancias de casos para operadores
Acceso basado en roles	Permisos de plataforma estándar	Personas conscientes de la etapa : define quién puede ver y actuar dentro de cada etapa
Trabajo ad-hoc	No compatible; todos los pasos se definen en tiempo de diseño	Compatible: el gestor de casos o un usuario humano puede crear tareas en runtime

Un caso puede invocar un BPMN de Maestro como uno de sus tipos de tareas, y un BPMN de Maestro puede invocar un caso como uno de sus tipos de tareas, lo que hace que los dos tipos de proyectos sean complementarios en lugar de competir. Usa Maestro BPMN para subprocesos bien definidos y Maestro Case como capa de orquestación externa cuando el flujo general es dinámico.

Agentic-first por diseño

La gestión de casos es la forma adecuada para el trabajo de larga duración y con muchas excepciones, pero por sí sola, sigue dependiendo de los trabajadores del conocimiento humanos para realizar la mayoría de las decisiones de enrutamiento y juicio. Maestro Case es agéntico primero y nativo de IA: los agentes de IA son participantes de primera clase en el caso y operan en dos niveles distintos:

• Como trabajadores de tareas dentro de las etapas : categorizar datos, marcar anomalías, extraer campos de documentos, redactar respuestas, verificar políticas. Cada agente se ejecuta dentro de una tarea, lee lo que necesita de la entidad del caso [Próximamente] , hace su trabajo y escribe sus resultados.
• Como orquestador del propio caso , el agente de Case Manager dirige el caso desde la creación hasta el cierre, tomando decisiones tanto a nivel de etapa como de tarea: qué etapa activar a continuación, qué tareas ejecutar dentro de esa etapa, cuando una tarea o etapa es completarse o debe salir antes, y cuándo escalar. Funciona junto con reglas deterministas cuando existen, y razona sobre datos de casos y políticas cuando no existen.

Esto colapsa el cuello de botella tradicional de confiar únicamente en los trabajadores del conocimiento humanos para tomar decisiones de enrutamiento, manejar excepciones y hacer avanzar los casos. Los humanos intervienen cuando la política, el juicio o la responsabilidad lo requieren, no porque el caso no pueda avanzar sin ellos.

Conjunto de herramientas Maestro Case

Maestro Case abarca el ciclo de vida del caso de extremo a extremo a través de tres superficies complementarias:

Diseñador de planes de casos (Studio Web)

Para quién es: desarrolladores de automatización y arquitectos empresariales.

Úsalo para crear o actualizar un plan de caso: etapas, transiciones, SLA, escaladas y acceso a nivel de etapa. Adjunta implementaciones a tareas (humanas, RPA, API, agente de IA, proceso de agente, caso secundario). Asignar entradas y salidas y establecer el comportamiento de reingreso. El resultado es un plan de caso versionado listo para publicar e implementar.

Gestión de instancias de casos (Maestro)

Para quién es: operadores de procesos, gestores de incidentes y propietarios de procesos.

Úsalo para operar casos en ejecución con controles de ciclo de vida (Pausar, Reanudar, Cancelar, Migrar) y auditoría completa. Resuelva incidentes reintentando tareas fallidas o migrando instancias a versiones más recientes del plan de caso. Usa insights en vivo, mapas de calor y Process Mining para detectar cuellos de botella y aportar mejoras al diseño.

Aplicación de casos (Maestro)

Para quién es: asistentes sociales y gestores de casos.

Úselo para ver todos los casos, detalles de casos (línea de tiempo, datos de casos, tareas humanas) y realizar acciones rápidas como Completar y Reabrir. La aplicación de casos es un espacio de trabajo obstinado y centrado en casos: listas, detalles, tareas y vistas de SLA. Los formularios de tareas humanas se siguen creando con aplicaciones de acción y las tareas de casos hacen referencia a ellos.

La aplicación de casos viene en dos opciones:

Opción	Descripción	Cuándo usarlo
Aplicación de casos lista para usar	Un espacio de trabajo de casos prediseñado y sin código que se envía con Maestro Case. Las listas, las vistas de detalles, la bandeja de entrada de tareas y las vistas de SLA se configuran automáticamente desde tu plan de caso y entidad.	El valor predeterminado: utilízalo para operaciones rápidas de casos sin escribir ningún código.
Aplicación de caso codificada personalizada	Una aplicación de casos a medida que creas utilizando el SDK de TypeScript de código profesional. Te permite crear vistas, diseños y flujos de trabajo personalizados sobre el mismo runtime de caso.	Cuando necesitas una IU más allá de lo que expone la aplicación lista para usar: espacios de trabajo de marca, paneles personalizados o experiencias de casos específicos de dominio.

Nota:

La aplicación de casos es distinta de UiPath Apps. La aplicación de casos está diseñada específicamente para operaciones de casos. UiPath Apps es un creador de código bajo de propósito general para aplicaciones empresariales totalmente personalizadas o compuestas. Utilice la aplicación de casos para operaciones rápidas de casos; utiliza UiPath Apps cuando necesites una IU a medida más allá de las operaciones de casos.

Conceptos básicos

Comprender los siguientes conceptos es esencial antes de diseñar un caso de Agentic.

Caso y clave del caso

Un caso representa una situación empresarial del mundo real que debe resolverse: una reclamación, una disputa, una investigación. A diferencia de una instancia de proceso tradicional, un caso evoluciona con el tiempo a medida que se dispone de nueva información y se toman decisiones.

Cada caso se identifica de forma única mediante una clave de caso:

TipodeClave	Descripción	Ejemplo
Clave del sistema	Generado automáticamente por Maestro en la creación de casos	HC-1234, CLM-00891
Clave externa (definida por el cliente)	Un ID anterior pasado en la creación para que el mismo caso del mundo real se reconozca en todas las herramientas	Número de caso de CRM, número de póliza, ID de pedido de ERP

Utilice claves externas cuando el caso se origine en otro sistema (CRM, ERP, herramienta de emisión de tickets) para que los humanos y las integraciones puedan correlacionar el caso en todas las herramientas sin mantener una tabla de asignación independiente.

Entidad de caso

La entidad de caso [Próximamente] es el registro empresarial persistente y mecanografiado en el centro de cada caso. Es la única fuente de verdad de la que leen y escriben las etapas, tareas y condiciones de transición a lo largo del ciclo de vida del caso.

Cada proyecto de caso también incluye dos objetos de datos adicionales listos para usar:

• Documentos del caso : archivos adjuntos y archivos asociados con el caso (recibos, fotos, contratos).
• Comentarios del caso : notas, anotaciones y comunicaciones añadidas por los asistentes sociales y los gestores durante el tiempo de ejecución.

Los tres objetos comparten un campo de sistema caseID inmutable generado en la creación del caso.

Puedes incorporar la entidad del caso a Maestro Case de tres maneras:

Origen	Descripción	Cuándo usarlo
Objeto nativo de Data Fabric	Habilite la alternancia de entidad de caso en su proyecto de caso, que crea y vincula automáticamente una entidad de caso nativa de Data Fabric a su caso	Nuevos procesos en los que eres el propietario del modelo de datos
Sistema de registro a través de VDO	Registre un origen externo como objeto de datos virtual (VDO) en Data Fabric, habilite la alternancia de entidad de caso y establezca una relación entre el VDO y la entidad de caso en Data Fabric	Los datos de la entidad se encuentran en un sistema externo y desea hacer referencia a ellos sin duplicarlos
Sistema de registro a través del desencadenador de casos	Pasar los datos existentes en el desencadenador de creación de casos (por ejemplo, a través de un conector API); los campos se convierten en campos de caso disponibles a lo largo del caso	Integraciones ligeras en las que hidratas el caso en el momento de la creación

Estados

Las etapas son las fases nombradas de 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 condición completa de la etapa.

Etapas primarias frente a secundarias

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 condición de entrada configurada; ambas son válidas.	Se muestran como nodos de etapa central en la línea de tiempo de la aplicación de caso: estas son las etapas que los asistentes sociales ven como el ciclo de vida principal.
Etapa secundaria	Excepción o rutas alternativas que pueden ocurrir en cualquier momento durante el caso (por ejemplo, Solicitar información, Denegado, Retirado, Cancelado).	Sin bordes entrantes : al alternar una etapa como secundaria , se eliminan. La etapa se alcanza solo cuando su condición de entrada se evalúa como verdadera, y puede activarse cada vez que eso suceda, independientemente de dónde se encuentre el caso actualmente.	No forma parte de la línea de tiempo de la etapa principal. Aparecen por separado cuando están activos (por ejemplo, como indicador de ruta de excepción), ya que pueden activarse en cualquier punto.

En otras palabras, marcar una etapa como secundaria significa: no me conecte al ciclo de vida principal: me activaré cuando se cumpla mi condición de entrada. Esto es lo que permite que un caso salte a Solicitar información a mitad de la revisión, o a Retirado desde cualquier lugar, sin que el diseñador tenga que dibujar bordes de cada fuente posible.

Atributos de etapa

Cada etapa define:

• Condición de entrada : cuándo comienza esta etapa.
• Condición completa : lo que debe ser verdadero para marcar la etapa como completada y avanzar.
• Condición de salida : cuándo abandonar la etapa antes de tiempo (por ejemplo, escenarios de rescate o reenrutamiento).
• Condición de reingreso : cómo las rutas de reelaboración o retorno al origen vuelven aquí.
• SLA y escaladas de etapa : hora de vencimiento, umbrales de advertencia y destinatarios de notificación y correo electrónico de escalada.

Las etapas se pueden marcar como necesarias u opcionales. Un caso no puede completarse hasta que se hayan completado todas las etapas necesarias. Las etapas opcionales se activan solo cuando se cumplen sus condiciones de entrada y se pueden omitir sin bloquear el caso.

Etapas paralelas

Varias etapas pueden estar activas en el mismo caso al mismo tiempo. Por ejemplo, una etapa de Comunicación con el cliente puede ejecutarse junto con la suscripción mientras la liquidación se prepara en segundo plano. Las reglas de entrada controlan si las etapas se ejecutan en paralelo o en secuencia.

Tareas

Una tarea es una unidad de trabajo dentro de una etapa.

Tipos de tareas

Maestro Case admite los siguientes tipos de tareas:

Tipo de tarea	Descripción
Acción humana	Formularios, aprobaciones y aclaraciones asignados a una persona
Flujo de trabajo de RPA	Automatización de IU para sistemas heredados, extracción y reconciliación
Flujo de trabajo de API	Operaciones de sistema a sistema a través de flujo de trabajo
Ejecutar conector	Invocar una actividad de conector (por ejemplo, enviar notificación, crear registro en sistema externo)
Agente IA (UiPath)	Razonamiento autónomo sobre los datos para el trabajo basado en juicios
Agente externo	Agente de IA de terceros invocado a través de la API
Proceso agéntico de Maestro	Un proceso BPMN de varios pasos invocado como tarea
Caso secundario	Otro caso se genera como un caso secundario con su propio ciclo de vida
Esperar temporizador	Pausar hasta que transcurra una duración o se alcance una fecha objetivo
Esperar el evento del conector	Pausar hasta que llegue un evento externo a través de un conector

Modos de ejecución

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

Modo de ejecución	Comportamiento	Ejemplo
Secuencial	La tarea se ejecuta en un orden definido dentro de la etapa. Una secuencia también puede incluir ramas paralelas que se abren en abanico y se vuelven a unir antes del siguiente paso.	En una etapa de suscripción : Verify income → (Run credit check ∥ Pull employment history) → Calculate DTI → Generate decision
Impulsado por eventos	La tarea tiene una regla de entrada y se activa cada vez que el evento hace que la evaluación de la regla sea verdadera, incluso si la etapa está en pleno vuelo o la secuencia ya ha superado ese punto. Puede activarse más de una vez si el evento se repite.	En una etapa de Procesamiento de reclamaciones : Request additional documents se activa CUANDO una tarea de verificación marca la falta de un documento SI Documents.Missing == true , sin importar en qué etapa de la secuencia se encuentre actualmente
Ad-hoc	La tarea se define en el plan del caso, pero solo se inicia cuando un usuario la desencadena manualmente en runtime. Las tareas ad-hoc pueden ser de cualquier tipo de tarea enumerado anteriormente.	En una etapa de Escalada al cliente : Escalate to supervisor o Add fraud review : iniciada por el asistente social a juicio

Varias tareas pueden estar activas en la misma etapa al mismo tiempo. Las ramas secuenciales pueden desplegarse en rutas paralelas y volver a unirse antes del siguiente paso. Las tareas impulsadas por eventos se activan independientemente de la secuencia y con frecuencia se ejecutan en paralelo con cualquier otra cosa que esté en vuelo, incluidas varias instancias de la misma tarea impulsada por eventos que se activan simultáneamente si su evento desencadenador se repite. Las tareas ad-hoc pueden iniciarse en cualquier momento junto con las tareas en ejecución.

Ejecutar solo una vez

Cuando se vuelve a entrar en una etapa, puedes controlar qué tareas deben volver a ejecutarse utilizando el indicador ejecutar solo una vez en cada tarea:

• Ejecutar solo una vez = true : la tarea se omite al volver a entrar. Su salida anterior se conserva y la tarea no se vuelve a ejecutar.
• Ejecutar solo una vez = falso (predeterminado) : la tarea se restablece y se ejecuta de nuevo cada vez que se vuelve a entrar en la etapa, produciendo una nueva salida.

Ejemplo: en una etapa de recopilación de documentos , la tarea Send document checklist to customer está marcada como ejecutada solo una vez : no quieres volver a enviar un correo electrónico al cliente cada vez que la etapa se vuelve a abrir por un motivo diferente. La tarea Validate documents se deja con el valor predeterminado para que cada nuevo envío se valide de nuevo.

Configuración de otra tarea

Cada tarea también admite entradas y salidas asignadas a la entidad del caso.

Reglas

Las reglas controlan el movimiento del ciclo de vida y son el mecanismo que hace que la gestión de casos no sea lineal. 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, no en una programación de sondeo o secuencia fija.

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) : la 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 se establecen en uno de tres niveles: caso, etapa o tarea.

Reglas a nivel de caso

Regla	Propósito	Ejemplo
Caso completado	Marcar todo el caso como completado (resultado correcto).	CUANDO se completan todas las etapas necesarias SI Outcome == "Approved"
Salida de caso	Terminar el caso antes de que alcance la finalización normal (cancelar, retirar, fraude).	CUANDO Application.Status cambia SI Application.Status == "Withdrawn"

Reglas a nivel de etapa

Regla	Propósito	Ejemplo
entry	Gate cuando comienza la etapa.	CUANDO Application.Submitted el evento llega SI Application.Type == "Mortgage" && Documents.Count > 0
Completar	Decide cuándo finaliza la etapa normalmente.	CUANDO cualquier tarea de la etapa se completa SI todas las tareas necesarias son Done y UnderwritingDecision != null
Salir	Salga de la etapa antes de tiempo, incluso si está incompleta.	CUANDO UnderwritingDecision cambia SI UnderwritingDecision == "Reject"
Reingresar	Vuelve a una etapa completada anteriormente para una revisión controlada.	CUANDO Verification.Result cambia SI Verification.Result == "Failed" && DocsComplete == false

Las reglas de entrada llevan un conmutador de interrupción que controla lo que sucede con otras etapas activas cuando la regla de entrada se evalúa como verdadera:

• Interrumpiendo = true : se sale automáticamente de todas las etapas actualmente activas y el caso se fuerza a entrar en la etapa de nueva entrada. Utilízalo para rutas de excepción duras como Retirado o Retención de fraude que deben hacerse cargo del caso de inmediato.
• Interrumpiendo = falso : la nueva etapa se activa junto con cualquier etapa activa existente. El caso puede tener varias etapas ejecutándose en paralelo.

Los valores predeterminados difieren según el tipo de etapa: las etapas primarias se establecen de forma predeterminada en interrupción = falso (unirse en paralelo: la progresión normal del trabajo). Las etapas secundarias tienen el valor predeterminado de interrupción = true (se hace cargo del caso, ya que las etapas secundarias representan rutas de excepción o alternativas). Ambos valores predeterminados pueden anularse por etapa.

Las reglas Completar y Salir también incluyen una acción que determina lo que sucede con el caso una vez finalizada la etapa:

• Completar el caso / Salir del caso : finalizar o cancelar el caso desde aquí.
• Esperar a la selección manual : pausa y deja que un usuario elija la siguiente etapa.
• Volver al origen : dirige el caso de vuelta a la etapa que activó originalmente este.

Reglas a nivel de tarea

Regla	Propósito	Ejemplo
entry	Puerta cuando una tarea se inicia dentro de una etapa. 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.	CUANDO una tarea de verificación marca la falta de un documento SI Documents.Missing == true

Debido a que las reglas están impulsadas por eventos, el caso no ejecuta una secuencia fija: las etapas y tareas se activan, se completan, salen o se vuelven a abrir cada vez que llega su evento CUANDO llega y la condición SI (si está presente) se evalúa como verdadera en la entidad del caso actual. La reejecución de tareas en el reingreso al escenario está controlada por el indicador de ejecutar solo una vez descrito en la sección Tareas anterior.

Gestor de casos

El Gestor de casos es el orquestador de un caso: el agente que impulsa las decisiones del ciclo de vida en función de los eventos. Decide qué etapa activar a continuación, qué tareas iniciar, cuándo una etapa debe completarse o salir antes de tiempo, y cuándo escalar.

Se orquesta utilizando dos métodos complementarios:

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

Para impulsar un caso, el agente gestor de casos debe ajustarse a un contrato de entrada/salida definido que especifica qué estado del caso, eventos y políticas puede leer, y qué decisiones de etapa/tarea puede emitir. Consulta el contrato del agente de Case Manager para obtener la especificación completa.

SLA y escaladas

Define los SLA y las reglas de escalado tanto en el caso como en la etapa:

• SLA a nivel de caso : objetivo de resolución general (por ejemplo, resolver en 48 horas).
• SLA a nivel de etapa : plazo de vencimiento localizado (por ejemplo, revisión en 24 horas).
• Estado de SLA : encaminado, en riesgo o incumplido. Estos estados aparecen como insignias en las listas de casos y las vistas de detalles.
• Escaladas : reglas que se activan cuando un SLA está en riesgo o se infringe (por ejemplo, reasignar, notificar a la gestión, crear un marcador de prioridad).
• Pausar/Reanudar : los temporizadores de SLA pueden pausarse cuando el caso espera una entrada externa y reanudarse cuando se puede volver a accionar.

Personas del caso

Maestro Case aplica el acceso consciente de la etapa a través de personas para que las personas adecuadas vean y actúen en el momento adecuado:

Una Persona de caso es una abstracción en tiempo de diseño que representa un rol dentro de un tipo de caso (por ejemplo, Agente de admisión, Ajustador, Supervisor). Las personas desvinculan las necesidades de acceso de un caso de la estructura de identidad de la organización, lo que hace que las definiciones de casos sean portátiles entre organizaciones y tenants.

• En el momento del diseño, el diseñador de casos crea personas y ámbitos para cada una de ellas en etapas específicas.
• En el momento de la implementación, un administrador vincula cada perfil a usuarios o grupos de usuarios, por lo que el mismo tipo de caso puede tener diferentes ámbitos en diferentes entornos.
• En runtime, el sistema resuelve los perfiles del usuario y aplica el ámbito de la etapa en consecuencia. Un usuario con varias personas obtiene la unión de ámbitos de etapa.

Por ejemplo, un caso de Procesamiento de préstamos podría definir:

Persona	Aplicación	Verificación	Suscripción	Desembolso
Oficial de préstamos	Sí
Analista de verificación		Sí
Asegurador			Sí
Gerente de sucursal	Sí	Sí	Sí	Sí

Las tareas dentro de una etapa se asignan a un perfil, no a un usuario específico. El sistema resuelve el perfil a rol/grupo a usuarios en tiempo de ejecución para determinar la visibilidad y asignación de tareas.

Nota:

Próximamente se admitirán los roles de usuario de casos completos y el acceso.

Facturación y consumibles

Maestro Case sigue la misma facturación que Maestro. El trabajo que se ejecuta dentro de un caso consume los consumibles nativos de los tipos de tareas que utilizas: agentes de IA, flujos de trabajo de RPA, flujos de trabajo de API o conectores IS.

Próximos pasos

• Crea tu primer proyecto de Maestro Case : un tutorial paso a paso que guía la creación, implementación y prueba de un caso de reclamaciones de seguros de propiedad desde cero.
• Referencia de construcciones básicas : referencia detallada para cada construcción de Maestro Case: entidad de caso [Próximamente] , etapas, tareas, condiciones de transición, SLA y personas.
• Cómo configurar las transiciones de etapa y el reingreso : una guía práctica para modelar flujos de casos no lineales con condiciones de entrada, salida y reingreso.