- Introducción
- Primeros pasos
- Modelado de procesos con BPMN
- Comprender el modelado del proceso
- Abrir el lienzo de modelado
- Modelar tu proceso
- Alinear y conectar elementos BPMN
- Autopilot para Maestro (vista previa)
- Repositorio de procesos
- Modelado de procesos con Gestión de casos
- Diseñar un esquema de entidad de caso persistente
- Definición de claves de caso (sistema frente a externo)
- Establecimiento de contratos de E/S de tareas y reescritura
- Reglas de salida y terminación temprana
- Modelado de etapas primarias y secundarias
- Desencadenar un caso desde Data Fabric
- Implementar personas y permisos a nivel de etapa
- Establecer SLA y reglas de escalada automatizadas
- Configurar un bucle de revisión (reingreso)
- Gestionar instancias de casos activos: pausar, migrar y reintentar
- Diccionario de componentes de gestión de casos de Maestro
- Process modeling with Flow
- Primeros pasos
- Conceptos básicos
- Node reference
- Build guides
- Mejores prácticas
- Referencia
- Implementación del proceso
- Depuración
- Simular
- Publicar y actualizar procesos de agente
- Escenarios de implementación comunes
- Extracción y validación de documentos
- Operaciones de proceso
- Supervisión de procesos
- Optimización de procesos
- Información de referencia
Audiencia: intermedia: Automation Developers, Arquitectos empresariales, Arquitectos de soluciones
Información general
En Maestro Case, cada etapa puede terminar de una de dos maneras: finaliza su trabajo normalmente a través de una regla Completa o termina temprano a través de una regla de salida. Las reglas de salida actúan como interruptores automáticos : acortan una etapa en el momento en que las condiciones cambian de una manera que hace que el procesamiento continuo sea innecesario o incorrecto. Comprender la diferencia entre estos dos mecanismos es esencial para diseñar planes de casos que gestionen tanto las rutas felices como las rutas de excepción de forma limpia.
El ciclo de vida de la etapa en resumen
Antes de examinar cómo terminan las etapas, es útil comprender cómo comienzan y progresan. Cada etapa de un plan de caso se rige por un conjunto de tipos de reglas que controlan su ciclo de vida:
| Tipo de regla | Pregunta que responde |
|---|---|
| Regla de entrada | ¿Cuándo debe activarse esta etapa? |
| Regla completa | ¿Cuándo finaliza esta etapa? |
| Exit Rule | ¿Cuándo debería rescatarse esta etapa antes de tiempo? |
| Re-entry Rule | ¿Cuándo debe volver un caso aquí para su revisión? |
Una etapa pasa de Disponible a Activa cuando su Regla de entrada se evalúa como verdadera. Una vez activas, las tareas de la etapa comienzan a ejecutarse según sus propias reglas de entrada (para tareas impulsadas por eventos) o su posición en la secuencia. La etapa permanece activa hasta que se activa la regla Completar o la Regla de salida, lo que ocurra primero. Ambos resultados hacen que el gestor de casos evalúe en qué etapa entrar a continuación, en función de la acción de la regla.
¿Qué es una regla completa?
Una regla completa define la condición de finalización normal para una etapa. Se activa cuando la etapa ha logrado aquello para lo que fue diseñada. En la mayoría de los casos, la regla Completa evalúa si todas las tareas necesarias han finalizado y producido una salida válida.
Piensa en la regla Completa como la respuesta a: "¿Esta etapa ha hecho su trabajo?"
Una regla completa típica se ve así:
WHEN event("AllRequiredTasksDone")
WHEN event("AllRequiredTasksDone")
O, para etapas en las que importa un resultado de datos específico:
WHEN event("AdjusterDecisionMade")
IF adjusterDecision != null
WHEN event("AdjusterDecisionMade")
IF adjusterDecision != null
Cuando se activa una regla completa:
- La etapa pasa a un estado Completado .
- Todas las salidas de la tarea se conservan en la Entidad del caso [Próximamente].
- El gestor de casos aplica la acción de la regla (avanzar según la regla de entrada de la siguiente etapa, esperar la selección manual, volver al origen o completar el caso) y evalúa las reglas de entrada para las etapas posteriores.
Las reglas completas representan el resultado esperado y diseñado. La etapa se ejecutó, el trabajo se realizó y el resultado está listo para lo que venga a continuación.
¿Qué es una regla de salida: el "disyuntor"?
Una regla de salida define una condición de finalización anticipada. Se activa cuando algo cambia en mitad de la etapa que hace que el procesamiento continuo sea innecesario, no válido o contraproducente. Cuando se desencadena una regla de salida, la etapa finaliza inmediatamente : las tareas en ejecución se detienen y la etapa finaliza sin cumplir su regla Completar.
Piensa en la regla de salida como la respuesta a: "¿Ha cambiado algo que significa que esta etapa debe detenerse ahora?"
El término "disyuntor" captura este comportamiento con precisión. En ingeniería eléctrica, un disyuntor corta la alimentación en el instante en que detecta una condición peligrosa: no espera a que el circuito termine su trabajo previsto. Las reglas de salida funcionan de la misma manera: interrumpen una etapa en el momento en que una condición hace que el procesamiento posterior sea incorrecto o derrochador.
Una regla de salida típica se ve así:
WHEN PolicyCheckCompleted event arrives
IF policyValid == false
WHEN PolicyCheckCompleted event arrives
IF policyValid == false
La cláusula CUANDO puede escuchar un evento interno emitido por el ciclo de vida del caso (una tarea que se completa, una etapa que entra o sale, un cambio de campo de entidad, un SLA en marcha at-risk o breached) o un evento externo que llega desde fuera del (un webhook de conector, una activación de temporizador, una finalización de caso secundario, una llamada directa a la API). Las reglas de salida suelen escuchar eventos internos de finalización de tareas y el campo Entidad de caso actualiza esas tareas que producen.
Cuando se activa una regla de salida:
- La etapa finaliza inmediatamente, independientemente del progreso de la tarea.
- Tareas en ejecución dentro de la parada de la etapa. Las salidas de la tarea que ya se han escrito en la entidad del caso se conservan; cualquier tarea que estuviera en vuelo pero que aún no hubiera escrito su salida se registra como Terminada y su trabajo parcial se descarta.
- El Gestor de casos aplica la acción de la regla (el mismo conjunto que Completar: completar o salir del caso, esperar a la selección manual, volver al origen) y evalúa qué hacer a continuación, tal como lo haría después de una finalización normal.
- El caso no termina necesariamente: puede enrutar a una etapa diferente, una ruta secundaria (de excepción), o el agente gestor de casos puede decidir la siguiente acción cuando ninguna regla determinista cubre la situación.
- La salida temprana se registra en la pista de auditoría del caso: la regla de activación, el evento CUANDO que la desencadenó, los valores de la entidad del caso que cumplieron la cláusula SI, la acción tomada y la lista de tareas finalizadas. La entrada aparece en la línea de tiempo de la aplicación de casos y en la gestión de instancias de casos.
En qué se diferencian
La siguiente comparación resume la distinción fundamental entre reglas completas y reglas de salida:
| Dimensión | Regla completa | Exit Rule |
|---|---|---|
| Propósito | Marca la etapa como finalizada cuando se realiza el trabajo | Termina la etapa antes de tiempo cuando cambian las condiciones |
| Cuando se activa | Después de completar las tareas requeridas y producir una salida válida | Tan pronto como una condición supervisada se vuelva verdadera, independientemente del progreso de la tarea |
| Relación con las tareas | Espera a que finalicen las tareas | No espera: interrumpe las tareas en ejecución |
| Representa | El resultado normal y esperado | Un escenario anormal, condicional o de atajo |
| Estado de la etapa después de | Completado | Terminado (salida anticipada) |
| Qué sucede a continuación | El gestor de casos evalúa la siguiente etapa en función de los datos del caso | El gestor de casos evalúa la siguiente etapa en función de los datos del caso |
Ambas rutas (finalización normal y salida temprana) conducen al mismo comportamiento posterior: el Gestor de casos lee el estado actual de la entidad de caso y determina qué etapa activar a continuación. La diferencia está en por qué y cuándo terminó la etapa, no en lo que sucede después.
Una sola etapa puede tener definidas tanto una Regla completa como una Regla de salida. En runtime, la condición que se cumpla primero determina cómo termina la etapa. No son mutuamente excluyentes en la configuración: son mutuamente excluyentes en la ejecución.
Por qué importan las reglas de salida
Sin reglas de salida, los planes de casos tendrían que gestionar cada excepción después de que una etapa finalice todo su trabajo. Esto conduce a varios problemas:
- Esfuerzo desperdiciado. Las tareas continúan ejecutándose incluso cuando sus resultados son irrelevantes. Por ejemplo, una etapa de investigación puede pasar horas enviando un inspector de campo y analizando fotos para un reclamo cuya política ya se ha considerado no válida.
- Enrutamiento retrasado. El caso no puede moverse a la ruta de excepción correcta hasta que la etapa actual se complete por completo, lo que añade latencia innecesaria a la resolución general del caso.
- Reglas completas complejas. Sin un mecanismo de salida independiente, la regla Completa debe tener en cuenta tanto los finales normales como los anormales, lo que dificulta su lectura, mantenimiento y depuración.
Las reglas de salida resuelven estos problemas separando la señal de "listo" de la señal de "detener". La regla Completa es simple: describe el éxito. La regla de salida describe las condiciones en las que el éxito ya no es posible o relevante.
Etapas necesarias y salida anticipada
Una etapa marcada como necesaria debe terminar en un estado Completado para que el caso satisfaga una regla normal de Caso Completo. Cuando una regla de salida se activa en una etapa requerida, la etapa termina en un estado Terminado , no Completado , por lo que no contribuye a la comprobación de "todas las etapas requeridas completadas".
Esto significa que una regla de salida en una etapa requerida siempre debe emparejarse con una de las siguientes, de lo contrario el caso se bloqueará (la etapa requerida nunca se completa, no hay una etapa posterior configurada para recogerlo):
| Emparejamiento | Cómo funciona | Cuándo usarlo |
|---|---|---|
| La etapa posterior se hace cargo | La regla de entrada de una etapa independiente se activa en el mismo evento (a menudo una etapa secundaria con interrupting = true) y lleva el caso hacia el cierre. La regla de salida simplemente detiene el trabajo desperdiciado. | La mayoría de las rutas de excepción: por ejemplo, Denegado, Retención de fraude, Retirado. El caso continúa, simplemente continúa en otro lugar. |
| Acción de regla de salida = Salir del caso | La acción de la regla de salida finaliza el caso directamente. No se requiere ninguna etapa posterior. | La salida temprana significa que el caso no tiene una continuación significativa; por ejemplo, la política no es válida, el reclamante se retiró o se ha confirmado el fraude. |
Para una etapa opcional , una salida temprana está bien por sí sola: el caso aún puede completarse sin ella.
Patrones comunes de reglas de salida
La base de conocimientos y el material del curso L300 describen varios patrones recurrentes en los que las reglas de salida proporcionan un valor significativo.
Patrón 1: condición previa no válida
Una tarea al principio de la etapa descubre que una condición previa fundamental es falsa. No hay razón para que se ejecuten las tareas restantes.
Ejemplo: etapa de admisión de FNOL:
WHEN PolicyCheckCompleted event arrives
IF policyValid == false
ACTION Exit the case
WHEN PolicyCheckCompleted event arrives
IF policyValid == false
ACTION Exit the case
Si la póliza del reclamante no es válida, no tiene sentido extraer los detalles de la reclamación o crear un número de reclamación. La regla de salida finaliza la etapa de admisión inmediatamente. Debido a que la política no es válida, el caso no tiene una continuación significativa, por lo que la acción es Salir del caso : el caso finaliza y un enlace de cierre posterior puede enviar la notificación de denegación.
Patrón 2: rechazo en la etapa intermedia
Una tarea de toma de decisiones dentro de la etapa produce un resultado negativo que invalida el propósito de la etapa.
Ejemplo — Etapa de evaluación:
WHEN AdjusterDecisionMade event arrives
IF adjusterDecision == "deny"
ACTION advance
WHEN AdjusterDecisionMade event arrives
IF adjusterDecision == "deny"
ACTION advance
Si el ajustador niega la reclamación durante la etapa de evaluación, la etapa de liquidación nunca debe activarse. La regla de salida finaliza la evaluación antes de tiempo. La acción es avanzada : el mismo evento alcanza la regla de entrada de la etapa secundaria Denegado (que se activa en adjusterDecision == "deny", interrupting = true de forma predeterminada), y Denegado se encarga de enviar la notificación y cerrar el caso.
Patrón 3: detección de fraude o riesgo
Una comprobación automatizada descubre una señal de riesgo de alta gravedad que exige una escalada inmediata, sin pasar por la finalización normal de la etapa.
Ejemplo — Etapa de investigación:
WHEN FraudCheckCompleted event arrives
IF fraudScore > 0.9
ACTION advance
WHEN FraudCheckCompleted event arrives
IF fraudScore > 0.9
ACTION advance
Una puntuación de fraude por encima del umbral significa que el caso debe salir de la etapa de investigación inmediatamente. La acción es avanzada : una etapa secundaria de Retención de fraude (interrupting = true) se activa en el mismo evento y se hace cargo del caso. Esperar a que se complete la inspección de campo o la recuperación del informe policial sería una pérdida de tiempo y recursos.
Patrón 4: atajo de vía rápida
No todas las salidas anticipadas son negativas. Una regla de salida también puede acelerar el procesamiento cuando los datos muestran que las tareas restantes son innecesarias.
Ejemplo: etapa de revisión:
WHEN ValidationComplete event arrives
IF totalAmount < 500 AND validationResult.status == "pass"
ACTION advance
WHEN ValidationComplete event arrives
IF totalAmount < 500 AND validationResult.status == "pass"
ACTION advance
Una presentación limpia y de bajo valor no necesita la etapa de revisión completa. La regla de salida cortocircuita la etapa; la acción es avanzar , por lo que el caso procede directamente a la siguiente fase en el flujo principal. Este patrón reduce el tiempo de ciclo para los casos sencillos sin eliminar la etapa de Revisión del plan para los casos que lo necesitan.
Patrón 5: fallo del sistema externo
Una tarea de integración falla de una manera que significa que la etapa no puede producir un resultado significativo.
Ejemplo: etapa de liquidación:
WHEN PaymentProcessed event arrives
IF paymentFailed == true
ACTION Wait for manual selection
WHEN PaymentProcessed event arrives
IF paymentFailed == true
ACTION Wait for manual selection
Si el sistema de pago rechaza la transacción, continuar con la notificación al reclamante (que haría referencia a un pago exitoso) es incorrecto. La regla de salida detiene la etapa; la acción es Esperar selección manual para que un operador de proceso pueda elegir la ruta de recuperación: una etapa de reintento de pago, un canal de pago alternativo o una ruta de resolución manual.
Cómo interactúan las reglas de salida con el gestor de casos
Cuando se activa una regla de salida, el gestor de casos se hace cargo. Su comportamiento depende del mismo mecanismo que utiliza después de que finaliza cualquier etapa: aplica la acción de la regla de salida, evalúa el estado actual de la entidad del caso [Próximamente] y determina en qué etapa entrar a continuación.
Esto significa que las reglas de salida no necesitan especificar a dónde va el caso: solo especifican cuándo se detiene la etapa (y la acción describe la intención de alto nivel: avanzar, esperar al usuario, volver al origen o finalizar el caso). La lógica de enrutamiento reside en las reglas de entrada de las etapas posteriores y en la lógica de orquestación del gestor de casos (reglas deterministas primero, razonamiento del agente del gestor de casos como alternativa).
Por ejemplo, cuando la etapa de evaluación sale antes de tiempo debido a una denegación:
- La regla de salida de la etapa de evaluación se activa CUANDO el evento
AdjusterDecisionMadellega SIadjusterDecision == "deny". La etapa finaliza y las tareas en ejecución se detienen. - El mismo evento
AdjusterDecisionMadellega a todas las demás reglas cuyo CUANDO coincida con ella. La regla de entrada de la etapa secundaria DenegadaAdjusterDecisionMade( CUANDO llega SI ) seadjusterDecision == "deny"evalúa como verdadera y la etapa se activa. Como Denegado es una etapa secundaria, su regla de entrada predeterminada esinterrupting = true, por lo que se sale de cualquier otra etapa activa. - La etapa Denegado ejecuta sus tareas (enviar paquete de denegación, generar informe de auditoría). Cuando se completan todas las tareas necesarias, el caso se cierra a través de una regla de Caso Completo .
Esta separación de preocupaciones (las reglas de salida definen cuándo detenerse y las reglas de entrada definen cuándo comenzar ) mantiene el plan del caso modular y mantenible. Cada etapa solo necesita conocer sus propias reglas, no el gráfico de enrutamiento completo. El Gestor de casos nunca sondea la Entidad de caso: cada regla está impulsada por eventos y se evalúa solo cuando llega su evento CUANDO.
El agente de Case Manager sirve como alternativa cuando ninguna regla determinista cubre la situación después de una salida anticipada. Si la regla de salida se activa en circunstancias inesperadas y no coincide ninguna regla de entrada posterior, el agente razona sobre los datos de la entidad del caso y las políticas configuradas para decidir la siguiente acción, o escala a un humano si no puede determinar la ruta correcta.
Las reglas de salida son solo para la etapa. Las tareas solo tienen una regla de entrada: no hay regla Completar o de Salida en el nivel de tarea. La finalización de una tarea está determinada por el trabajo subyacente (formulario enviado, agente finalizado, RPA devuelto, etc.). Para detener el trabajo en mitad de la etapa, define la regla de salida en la propia etapa; finaliza todas las tareas en ejecución dentro de la etapa.
Directrices de diseño
Al incorporar reglas de salida en un plan de caso, ten en cuenta los siguientes principios:
- Mantén las reglas completas simples. Una regla completa debe describir la ruta feliz: "se han realizado todas las tareas necesarias" o "se ha tomado la decisión esperada". No incrustes lógica de excepción en la regla Completa.
- Usa reglas de salida para casos excepcionales. Reserva las reglas de salida para condiciones que realmente invalidan la continuación del procesamiento. No todas las ramas condicionales necesitan una regla de salida: algunas condiciones se gestionan mejor con la lógica de enrutamiento del Gestor de casos después de la finalización normal.
- Supervisa las salidas anteriores. Las reglas de salida suelen evaluar los campos escritos por las tareas anteriormente en la etapa. Diseña tu esquema de entidad de caso para que los campos que supervisa una regla de salida estén escritos por tareas específicas e identificables.
- Empareja las reglas de salida con las reglas de entrada posteriores. Una regla de salida detiene el procesamiento; una regla de entrada posterior detecta el caso y lo enruta a la ruta correcta. Diseñe estos en pares para evitar casos que finalizan una etapa pero no tienen adónde ir.
- Documenta la intención. Las reglas de salida son potentes, pero pueden ser sorprendentes para alguien que lee un plan de caso por primera vez. Utiliza nombres y comentarios claros para indicar por qué existe cada regla de salida y qué escenario maneja.
Recursos relacionados
- Etapas y reglas de etapa : referencia detallada para todos los tipos de reglas de etapa, incluidas las reglas de entrada, finalización, salida y reingreso.
- Crear un caso de reclamaciones de seguros en 30 minutos : tutorial completo para crear e implementar un plan de caso.
- Configuración del gestor de casos : cómo el gestor de casos utiliza las reglas primero y el razonamiento del agente del gestor de casos como alternativa para orquestar el ciclo de vida del caso después de que las etapas se completen o salgan.
- Información general
- El ciclo de vida de la etapa en resumen
- ¿Qué es una regla completa?
- ¿Qué es una regla de salida: el "disyuntor"?
- En qué se diferencian
- Por qué importan las reglas de salida
- Etapas necesarias y salida anticipada
- Patrones comunes de reglas de salida
- Patrón 1: condición previa no válida
- Patrón 2: rechazo en la etapa intermedia
- Patrón 3: detección de fraude o riesgo
- Patrón 4: atajo de vía rápida
- Patrón 5: fallo del sistema externo
- Cómo interactúan las reglas de salida con el gestor de casos
- Directrices de diseño
- Recursos relacionados