Règles de sortie et fin de l’étape précoce

Règles de sortie dans Maestro Case pour mettre fin aux étapes prématurément lorsque les conditions changent, y compris les différences par rapport aux règles d'achèvement et les effets de routage en aval.

Audience : intermédiaire - Automation Developers, architectes métier, architectes de solutions

Vue d'ensemble (Overview)

Dans Maestro Case, chaque étape peut se terminer des deux manières suivantes : elle termine son travail normalement via une règle d'achèvement ou elle se termine prématurément via une règle de sortie. Les règles de sortie agissent comme des disjoncteurs ; elles coupent une étape au moment où les conditions changent de manière à rendre la poursuite du traitement inutile ou incorrect. Comprendre la différence entre ces deux mécanismes est essentiel pour concevoir des plans de cas qui gèrent proprement à la fois les chemins nominaux et les chemins d'exception.

Le cycle de vie de l'étape en bref

Avant d'examiner la façon dont les étapes se terminent, il est utile de comprendre comment elles commencent et leur progression. Chaque étape d'un plan de cas est régie par un ensemble de types de règles qui contrôlent son cycle de vie :

Type de règle	Question à laquelle elle répond
Règle d’entrée	Quand cette étape doit-elle s'activer ?
Règle d'achèvement	Quand cette étape est-elle terminée ?
Règle de sortie	Quand cette étape doit-elle se terminer rapidement ?
Type de relance	Quand un cas doit-il revenir ici pour une révision ?

Une étape passe de Disponible à Active lorsque sa règle d'entrée est évaluée comme vraie. Une fois actives, les tâches de l'étape commencent à s'exécuter en fonction de leurs propres règles d'entrée (pour les tâches pilotées par des événements) ou de leur position dans la séquence. L'étape reste active jusqu'à ce que la règle d'achèvement ou la règle de sortie se déclenche, selon la première éventualité. Les deux résultats amènent le gestionnaire de cas à évaluer l'étape à suivre en fonction de l'action de la règle.

Qu'est-ce qu'une règle d'achèvement ?

Une règle d'achèvement définit la condition de fin normale pour une étape. Elle se déclenche lorsque l'étape a accompli ce pour quoi elle a été conçue. Dans la plupart des cas, la règle d'achèvement évalue si toutes les tâches requises ont terminé et produit une sortie valide.

Pensez à la règle d'achèvement comme à la réponse à : « Cette étape a-t-elle fait sa tâche ? »

Une règle d'achèvement typique ressemble à ceci :

WHEN event("AllRequiredTasksDone")

Ou, pour les étapes où un résultat de données spécifique compte :

WHEN event("AdjusterDecisionMade")
  IF adjusterDecision != null

Lorsqu'une règle d'achèvement se déclenche :

• L'étape passe à un état Terminé.
• Toutes les sorties de tâche sont conservées dans l'entité de cas [Bientôt disponible].
• Le gestionnaire de cas applique l'action de la règle (avancer selon la règle d'entrée de l'étape suivante, attendre la sélection manuelle, retour à l'origine ou terminer le cas) et évalue les règles d'entrée pour les étapes suivantes.

Les règles d'achèvement représentent le résultat attendu et conçu. L'étape s'est exécutée, le travail s'est produit et le résultat est prêt pour tout ce qui vient ensuite.

Qu'est-ce qu'une règle de sortie - le « disjoncteur » ?

Une règle de sortie définit une condition de fin précoce. Elle se déclenche lorsque quelque chose change à mi-étape, ce qui rend la poursuite du traitement inutile, non valide ou contre-productive. Lorsqu'une règle de sortie se déclenche, l'étape se termine immédiatement - les tâches en cours d'exécution s'arrêtent et l'étape se termine sans satisfaire à sa règle d'achèvement.

Pensez à la règle de sortie comme à la réponse à : « Est-ce que quelque chose a changé signifiant que cette étape doit s'arrêter maintenant ? »

Le terme « disjoncteur » capture ce comportement avec précision. En génie électrique, un disjoncteur coupe l'alimentation à l'instant où il détecte une condition dangereuse ; il n'attend pas que le circuit termine le travail prévu. Les règles de sortie fonctionnent de la même manière : elles interrompent une étape au moment où une condition rend la poursuite du traitement incorrecte ou inutile.

Une règle de sortie typique ressemble à ceci :

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false

La clause WHEN peut écouter soit un événement interne émis par le cycle de vie du cas (l'achèvement d'une tâche, l'entrée ou la sortie d'une étape, une modification d'un champ d'entité, un SLA en cours de at-risk ou breached) ou un événement externe arrivant de l'extérieur du cas (un webhook de connecteur, un minuteur se déclenchant, l'achèvement d'un cas enfant, un appel d'API direct). Les règles de sortie écoutent le plus souvent les événements internes d'achèvement de tâche et les mises à jour du champ d'entité du cas que ces tâches produisent.

Lorsqu'une règle de sortie se déclenche :

• L'étape se termine immédiatement, quelle que soit la progression de la tâche.
• Les tâches en cours d'exécution dans l'étape s'arrêtent. Les sorties de tâche qui ont déjà été écrites dans l'entité de cas sont conservées ; toute tâche qui était en cours d'exécution, mais n'avait pas encore écrit sa sortie est enregistrée comme Terminée et son travail partiel est ignoré.
• Le gestionnaire de cas applique l'action de la règle (le même ensemble que Terminer : terminer ou quitter le cas, attendre la sélection manuelle, retour à l'origine) et évalue ce qu'il faut faire ensuite, comme il le ferait après un achèvement normal.
• Le cas ne se termine pas nécessairement - il peut être acheminé vers une autre étape, un chemin secondaire (exception), ou l'agent de gestion de cas peut décider de l'action suivante lorsqu'aucune règle déterministe ne couvre la situation.
• La sortie précoce est enregistrée dans la piste d'audit du cas : la règle de déclenchement, l'événement WHEN qui l'a déclenchée, les valeurs de l'entité de cas qui ont satisfait à la clause IF, l'action entreprise et la liste des tâches terminées. L'entrée apparaît dans la chronologie de l'application du cas et dans la gestion des instances de cas.

Comment elles diffèrent

La comparaison suivante résume la distinction fondamentale entre les règles d'achèvement et les règles de sortie :

Cote	Règle d'achèvement	Règle de sortie
Objectif	Marque l'étape comme terminée lorsque le travail est terminé	Termine l'étape tôt lorsque les conditions changent
Lorsqu'elle se déclenche	Après l'achèvement des tâches requises et la production d'une sortie valide	Dès qu'une condition surveillée devient vraie, quelle que soit la progression de la tâche
Relation aux tâches	Attend que les tâches se terminent	N'attend pas - interrompt les tâches en cours d'exécution
Représente	Le résultat normal et attendu	Un scénario anormal, conditionnel ou de raccourci
État de l'étape après	Terminé	Terminé (sortie précoce)
Ce qui se passe ensuite	Le gestionnaire de cas évalue l'étape suivante en fonction des données du cas	Le gestionnaire de cas évalue l'étape suivante en fonction des données du cas

Les deux chemins (achèvement normal et sortie précoce) mènent au même comportement en aval : le gestionnaire de cas lit l'état actuel de l'entité de cas et détermine l'étape à activer ensuite. La différence réside dans le pourquoi et le quand l'étape s'est terminée, et non dans ce qui se passe par la suite.

Remarque :

Une seule étape peut avoir à la fois une règle d'achèvement et une règle de sortie définies. Lors du runtime, la condition qui devient vraie en premier détermine la façon dont l'étape se termine. Elles ne sont pas mutuellement exclusives dans la configuration - elles sont mutuellement exclusives dans l'exécution.

Pourquoi les règles de sortie sont importantes

Sans règles de sortie, les plans de cas devraient gérer chaque exception après qu'une étape a terminé tout son travail. Cela conduit à plusieurs problèmes :

• Effort gaspillé. Les tâches continuent de s'exécuter même lorsque leurs résultats ne sont pas pertinents. Par exemple, une étape d'enquête peut passer des heures à envoyer un inspecteur de terrain et à analyser les photos d'une réclamation dont la police a déjà été jugée non valide.
• Routage différé. Le cas ne peut pas passer au chemin d'exception correct tant que l'étape actuelle ne se termine pas entièrement, ce qui ajoute une latence inutile à la résolution globale du cas.
• Règles d'achèvement complexes. Sans mécanisme de sortie distinct, la règle d'achèvement doit tenir compte des fins normales et anormales, ce qui rend plus difficile la lecture, la maintenance et le débogage.

Les règles de sortie résolvent ces problèmes en séparant le signal « terminé » du signal d'« arrêt ». La règle d'achèvement reste simple - elle décrit le succès. La règle de sortie décrit les conditions dans lesquelles le succès n'est plus possible ou pertinent.

Étapes requises et sortie précoce

Une étape marquée comme requise doit se terminer dans un état Terminé pour que le cas satisfasse une règle d'achèvement normale du cas. Lorsqu'une règle de sortie se déclenche sur une étape requise, l'étape se termine dans un état Abandonné - et non Terminé - elle ne contribue donc pas à la vérification « toutes les étapes requises sont terminées ».

Cela signifie qu'une règle de sortie sur une étape requise doit toujours s'associer à l'un des éléments suivants, sinon le cas restera bloqué (étape requise jamais terminée, aucune étape en aval configurée pour le récupérer) :

Couplage	Mode de fonctionnement	Quand l'utiliser
L'étape en aval prend le relais	La règle d'entrée d'une étape distincte se déclenche sur le même événement (souvent une étape secondaire avec interrupting = true) et conduit le cas vers la fermeture. La règle de sortie arrête simplement le travail gaspillé.	La plupart des chemins d'exception - par exemple, Refusé, Suspension pour fraude, Retiré. Le cas continue, il continue simplement ailleurs.
Action de la règle de sortie = Quitter le cas	L'action de la règle de sortie met directement fin au cas. Aucune étape en aval n'est requise.	La sortie précoce signifie que le cas n'a aucune suite significative ; par exemple, la police est non valide, le demandeur s'est retiré ou la fraude a été confirmée.

Pour une étape facultative, une sortie précoce suffit en soi ; le cas peut toujours se terminer sans elle.

Modèles de règles de sortie courants

La base de connaissances et le matériel de cours L300 décrivent plusieurs modèles récurrents où les règles de sortie fournissent une valeur significative.

Modèle 1 : précondition non valide

Une tâche au début de l'étape découvre qu'une précondition de base est fausse. Il n'y a aucune raison pour que les tâches restantes s'exécutent.

Exemple - Étape d'admission FNOL :

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false
  ACTION Exit the case

Si la police d'assurance du demandeur n'est pas valide, il est inutile d'extraire les détails de la réclamation ou de créer un numéro de réclamation.La règle de sortie met immédiatement fin à l'étape d'admission. Étant donné que la police est non valide, le cas n'a aucune poursuite significative, l'action est donc Quitter le cas - le cas se termine et un crochet de fermeture en aval peut envoyer la notification de refus.

Modèle 2 : rejet à mi-étape

Une tâche de prise de décision dans l'étape produit un résultat négatif qui invalide l'objectif de l'étape.

Exemple - Étape d'évaluation :

WHEN AdjusterDecisionMade event arrives
  IF adjusterDecision == "deny"
  ACTION advance

Si l'expert en sinistres refuse la demande pendant l'étape d'évaluation, l'étape de règlement ne doit jamais s'activer. La règle de sortie met fin à l'évaluation plus tôt. L'action est Avancé - le même événement atteint la règle d'entrée de l'étape secondaire Refusé (qui se déclenche le adjusterDecision == "deny", interrupting = true par défaut) et Refusé prend le relais pour envoyer une notification et fermer le cas.

Modèle 3 : détection de la fraude ou du risque

Une vérification automatisée découvre un signal de risque de haute gravité qui nécessite une escalade immédiate, en contournant l'achèvement normal de l'étape.

Exemple - Étape d'enquête :

WHEN FraudCheckCompleted event arrives
  IF fraudScore > 0.9
  ACTION advance

Un score de fraude supérieur au seuil signifie que le cas doit quitter immédiatement l'étape d'enquête. L'action est Avancé - une étape secondaire de Suspension pour fraude (interrupting = true) s'active lors du même événement et prend en charge le cas. Attendre la fin de l'inspection sur le terrain ou de la récupération du rapport de police ferait perdre du temps et des ressources.

Modèle 4 : raccourci rapide

Toutes les sorties précoces ne sont pas négatives. Une règle de sortie peut également accélérer le traitement lorsque les données montrent que les tâches restantes sont inutiles.

Exemple - Étape d'examen :

WHEN ValidationComplete event arrives
  IF totalAmount < 500 AND validationResult.status == "pass"
  ACTION advance

Une soumission propre et de faible valeur ne nécessite pas l'étape d'examen complète. La Règle de sortie court-circuite l'étape ; l'action est Avancé afin que le cas passe directement à la phase suivante du flux primaire. Ce modèle réduit la durée de cycle pour les cas simples sans supprimer l'étape d'examen du plan pour les cas qui en ont besoin.

Modèle 5 : défaillance du système externe

Une tâche d'intégration échoue d'une manière qui signifie que l'étape ne peut pas produire un résultat significatif.

Exemple - Étape de règlement :

WHEN PaymentProcessed event arrives
  IF paymentFailed == true
  ACTION Wait for manual selection

Si le système de paiement rejette la transaction, continuer avec la notification du demandeur (qui ferait référence à un paiement réussi) est incorrect. La règle de sortie arrête l'étape ; l'action est Attendre la sélection manuelle afin qu'un opérateur de processus puisse choisir le chemin de récupération - une étape de nouvelle tentative de paiement, un canal de paiement alternatif ou un chemin de résolution manuel.

Comment les règles de sortie interagissent avec le gestionnaire de cas

Lorsqu'une règle de sortie se déclenche, le gestionnaire de cas prend le relais. Son comportement dépend du même mécanisme qu'il utilise après la fin d'une étape : il applique l'action de la règle de sortie, évalue l'état actuel de l'entité de cas [Bientôt disponible] et détermine l'étape à suivre.

Cela signifie que les règles de sortie n'ont pas besoin de spécifier où va le cas ; elles spécifient uniquement quand l'étape s'arrête (et l'action décrit l'intention de haut niveau : avancer, attendre l'utilisateur, retour à l'origine ou mettre fin au cas). La logique de routage se trouve dans les règles d'entrée des étapes en aval et dans la logique d'orchestration du gestionnaire de cas (règles déterministes d'abord, raisonnement de l'agent de gestion des cas comme solution de secours).

Par exemple, lorsque l'étape d'évaluation se termine tôt en raison d'un refus :

1. La règle de sortie de l'étape d'évaluation se déclenche - WHEN l'événement AdjusterDecisionMade arrive IF adjusterDecision == "deny". L'étape se termine et les tâches en cours d'exécution s'arrêtent.
2. Le même événement AdjusterDecisionMade atteint toutes les autres règles dont le WHEN lui correspond. La règle d'entrée de l'étape secondaire Refusé - WHEN AdjusterDecisionMade arrive IF adjusterDecision == "deny" - évalue comme vrai et l'étape s'active. Étant donné que Refusé est une étape secondaire, sa règle d'entrée se met par défaut sur interrupting = true, de sorte que toutes les autres étapes actives sont quittées.
3. L'étape Refusé exécute ses tâches (envoyer le paquet de refus, générer un rapport d'audit). Lorsque toutes les tâches requises sont terminées, le cas se ferme via une règle d'achèvement du cas.

Cette séparation des préoccupations - les règles de sortie définissent quand effectuer un arrêt, les règles d'entrée définissent quand commencer - maintient le plan de cas modulaire et maintenable. Chaque étape doit connaître uniquement ses propres règles, et non le graphique de routage complet. Le gestionnaire de cas n'interroge jamais l'entité de cas : chaque règle est pilotée par les événements et évalue uniquement lorsque son événement WHEN arrive.

Remarque :

L'agent de gestion des cas sert de solution de secours lorsqu'aucune règle déterministe ne couvre la situation après une sortie précoce. Si la règle de sortie se déclenche dans des circonstances inattendues et qu'aucune règle d'entrée en aval ne correspond, l'agent raisonne sur les données de l'entité de cas et les stratégies configurées pour décider de l'action suivante, ou passe à un humain s'il ne peut pas déterminer le chemin correct.

Remarque :

Les règles de sortie sont uniquement relatives à l'étape. Les tâches ont une seule règle d'entrée - il n'y a aucune règle d'achèvement ou de sortie au niveau de la tâche. L'achèvement d'une tâche est déterminé par le travail sous-jacent (formulaire envoyé, agent terminé, RPA renvoyé, etc.). Pour arrêter le travail à mi-étape, définissez la règle de sortie sur l'étape elle-même ; elle met fin à toutes les tâches en cours d'exécution de l'étape.

Directives de conception

Lors de l'intégration des règles de sortie dans un plan de cas, tenez compte des principes suivants :

• Gardez les règles d'achèvement simples. Une règle d'achèvement doit décrire le scénario nominal : « toutes les tâches requises sont terminées » ou « la décision attendue a été prise ». N'intégrez pas la logique d'exception dans la règle d'achèvement.
• Utilisez les règles de sortie pour les cas exceptionnels. Réservez les règles de sortie pour les conditions qui invalident réellement la poursuite du traitement. Toutes les branches conditionnelles n'ont pas besoin d'une Règle de sortie ; certaines conditions sont mieux gérées par la logique de routage du gestionnaire de cas après l'achèvement normal.
• Surveillez les sorties en amont. Les règles de sortie évaluent généralement les champs écrits par des tâches plus tôt dans l'étape. Concevez le schéma de votre entité de cas afin que les champs qu'une règle de sortie surveille soient écrits par des tâches spécifiques et identifiables.
• Associez les règles de sortie aux règles d'entrée en aval. Une règle de sortie arrête le traitement ; une règle d'entrée en aval détecte le cas et l'achemine vers le chemin correct. Concevez-les par paires pour éviter les cas qui mettent fin à une étape, mais n'ont nulle part où aller.
• Documentez l'intention. Les règles de sortie sont puissantes, mais peuvent être surprenantes pour quelqu'un lisant un plan de cas pour la première fois. Utilisez un nommage clair et des commentaires pour indiquer pourquoi chaque règle de sortie existe et le scénario qu'elle gère.

Ressources connexes

• Étapes et règles d'étape - référence détaillée pour tous les types de règles d'étape, y compris les règles d'entrée, d'achèvement, de sortie et de renouvellement.
• Création d'un cas de réclamation d'assurance en 30 minutes - tutoriel de bout en bout pour la création et le déploiement d'un plan de cas.
• Configuration du gestionnaire de cas - comment le gestionnaire de cas utilise d'abord les règles et le raisonnement de l'agent de gestion des cas comme solution de secours pour orchestrer le cycle de vie du cas après la fin ou la sortie des étapes.