Règles de sortie et fin d'étape antérieure

Quitter les règles dans le Maestro Case pour terminer les étapes tôt lorsque les conditions changent, y compris les différences par rapport aux Règles complètes et les effets du routage en aval.

Public : Intermédiaire — Automation Developers, architectes d'entreprise, architectes de solutions

Vue d'ensemble (Overview)

Dans Maestro Case, chaque étape peut se terminer de l'une des deux façons suivantes: elle termine son travail normalement via une règle Complète, ou elle se termine tôt via une règle de sortie. Les règles de sortie agissent comme des déclencheurs - elles raccourcissent une étape au moment où les conditions changent d'une manière qui rend la continuité du traitement inutile ou incorrecte. Il est essentiel de comprendre la différence entre ces deux mécanismes pour concevoir des plans de cas qui gèrent proprement les chemins heureux 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 aide à comprendre comment elles commencent et progressent. 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 avec réponses
Règle d’entrée	Quand cette étape doit-elle s’activer?
Compléter la règle	Quand cette étape est-elle terminée?
Exit Rule	Quand cette étape doit-elle s'arrêter plus tôt?
Re-entry Rule	Quand un cas doit-il revenir ici pour révision?

Une étape passe de Disponible à Actif lorsque sa règle d'entrée est évaluée comme vrai. 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 Complète 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 suivante, en fonction de l'action de la règle.

Qu'est-ce qu'une règle complète?

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

Considérez la Règle complète comme la réponse à: « Cette étape a-t-elle fait son travail?»

Une règle complète typique ressemble à:

WHEN event("AllRequiredTasksDone")

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

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

Lorsqu’une règle complète se déclenche:

• L'étape passe à l'é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 (passer par la règle d'entrée de l'étape suivante, attendre la sélection manuelle, revenir à l'origine ou terminer l'incident) et évalue les règles d'entrée pour les étapes suivantes.

Les règles complètes représentent le résultat attendu et conçu. L’étape a été exécutée, le travail s’est produit et le résultat est prêt pour la suite.

Qu'est-ce qu'une règle de sortie — le « déclencheur»?

Une règle de sortie définit une condition de résiliation anticipée. Il se déclenche lorsque quelque chose change à mi-parcours, ce qui rend le traitement continu inutile, invalide ou contre-productif. 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 complète.

Considérez la Règle de sortie comme la réponse à: « A-t-il changé qui signifie que cette étape doit s’arrêter maintenant?»

Le terme « déclencheur» décrit précisément ce comportement. En ingénierie électronique, un déclencheur coupe l'alimentation dès qu'il détecte une condition dangereux, sans attendre que le circuit termine son 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 le traitement ultérieur incorrect ou invalidant.

Une règle de sortie type ressemble à:

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false

La clause saisir peut écouter soit un événement interne émis par le cycle de vie du cas (une tâche se termine, une entrée ou une sortie d'étape, une modification de champ d'entité, un SLA allant at-risk ou breached), soit un événement externe provenant de l'extérieur du (un webhook de connecteur, un déclenchement de minuterie, un incident enfant qui se termine, un appel d'API direct). Les règles de sortie écoutent le plus souvent les événements internes de complétion des tâches et le champ Entité de cas met à jour ces tâches.

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 qui n'avait pas encore écrit sa sortie, est enregistrée comme Terminée et son travail partiel est supprimé.
• 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, revenir à l'origine) et évalue la prochaine action, comme il le ferait après une complétion normale.
• L'incident ne se termine pas nécessairement: il peut acheminer vers une étape différente, un chemin secondaire (d'exception), ou l' agent du gestionnaire 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é, les valeurs de l'entité du 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 de cas et dans la gestion des instances de cas.

En quoi ils diffèrent

La comparaison suivante résume la distinction essentielle entre les règles complètes et les règles de sortie:

Cote	Compléter la règle	Exit Rule
Objectif	Marque l’étape comme terminée lorsque le travail est terminé	Termine l’étape tôt lorsque les conditions changent
Quand il se déclenche	Une fois que les tâches requises sont terminées et ont produit une sortie valide	Dès qu’une condition surveillée devient vraie, quelle que soit la progression de la tâche
Relation avec les tâches	Attend la fin des tâches	N’attend pas — interrompt les tâches en cours d’exécution
Représente	Le résultat normal attendu	Un scénario anormal, conditionnel ou de raccourci
État de l’étape après	Terminé	Résilié (départ antérieure)
Et ensuite	Case Manager évalue l'étape suivante en fonction des données du cas	Case Manager évalue l'étape suivante en fonction des données du cas

Les deux chemins — achèvement normal et sortie tôt — entraînent le 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 moment où l’étape s’est terminée, et non dans ce qui se passe ensuite.

Remarque :

Une étape peut avoir à la fois une Règle de remplissage et une Règle de sortie définies. Au moment de l’exécution, la première condition qui devient vraie détermine la façon dont l’étape se termine. Ils ne s'excluent pas mutuellement dans la configuration — ils s'excluent mutuellement dans l'exécution.

Importance des règles de sortie

Sans règles de sortie, les plans de cas devront gérer chaque exception après qu'une étape termine tout son travail. Cela entraîne plusieurs problèmes:

• Efforts perdus. Les tâches se continuent d'être exécutées même lorsque leurs résultats ne sont pas pertinents. Par exemple, une étape d’enquête peut passer des heures à envoyer un inspection de champ et à analyser les photos d’une réclamation dont la politique a déjà été trouvée non valide.
• Routage retardé. L’incident ne peut pas être déplacé vers le chemin d’exception correct tant que l’étape actuelle n’est pas entièrement terminée, ce qui ajoute une latence inutile à la résolution globale de l’incident.
• Règles complètes complexes. Sans mécanisme de sortie distinct, la règle Complète doit tenir compte à la fois des terminaisons normales et normales, ce qui facilite 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 « arrêt». La Règle complète reste simple et décrit la réussite. La Règle de sortie décrit les conditions dans lesquelles la réussite n'est plus possible ou pertinente.

Étapes requises et sortie précoce

Une étape marquée comme requise doit se terminer dans l'état Terminé pour que le cas réponde à la règle standard Cas terminé. Lorsqu'une règle de sortie se déclenche à une étape requise, l'étape se termine dans un état Terminé — non Terminé — de sorte qu'il ne contribue pas à la vérification « toutes les étapes requises terminées».

Cela signifie qu’une règle de sortie à une étape requise doit toujours être associée à l’une des éléments suivants, sinon le cas sera bloqué (l’étape requise n’est jamais terminée, aucune étape en aval n’est configurée pour la récupérer):

Appariement	Mode de fonctionnement	Quand l'utiliser
Prise en charge de l’étape en aval	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 à la clôture. La règle de sortie arrête simplement le travail perdue.	La plupart des chemins d’exception — par exemple, Refusé, Suspendre, Retrait. L'incident se poursuit, il se poursuit simplement à un autre endroit.
Action de la règle de sortie = quitter le cas	L’action de la règle de sortie met fin directement au cas. Aucune étape en aval n’est requise.	La sortie tôt signifie que le cas n'a pas de suite significative - par exemple, la politique n'est pas invalide, le requérant a été retiré ou la fraude a été confirmée.

Pour une étape facultative , une sortie précoce est autonome - l'incident peut toujours se terminer sans elle.

Modèles de règles de sortie courants

La base de connaissances et le matériel du cours L300 décrivent plusieurs modèles récurrents pour lesquels les règles de sortie apportent une valeur importante.

Modèle 1: précondition non valide

Une tâche au début de l’étape découvrez qu’une précondition de base est fausse. Il n’y a aucune raison pour que les tâches restantes soient exécutées.

Exemple - Étape d’entrée FNP:

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

Si la politique du requérant n’est pas valide, il n’y a aucun point à extraire les détails de la revendication ou à créer un numéro de revendication. La règle de sortie met immédiatement fin à l'étape d'entrée. Étant donné que la politique n'est pas valide, le cas n'a pas de suite significative, de sorte que l'action est Exit the case — le cas se termine et un hook de fermeture en aval peut envoyer la notification de refus.

Modèle 2: rejet à mi-étape

Une tâche décisionnelle au sein de 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'ajusteur refuse la demande pendant l'étape Évaluation, l'étape Règlement ne doit jamais s'activer. La règle de sortie met fin à l'évaluation tôt. L'action est avancée : le même événement atteint la règle d'entrée de l'étape secondaire Refusé (qui se déclenche sur 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 des fraudes ou des risques

Une vérification automatisée détecte un signal à risque de haute gravité qui exige une escalade immédiate, contournant l’achèvement de l’étape normale.

Exemple - Étape de l'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 immédiatement quitter l’étape d’enquête. L'action est avancée : une étape secondaire attente de fraude (interrupting = true) s'active sur le même événement et prend le cas en charge. Attendre la fin de l'inspection du champ ou de la récupération du rapport de police entraînerait une perte de temps et de 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 de révision:

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 de révision complète. La règle de sortie raccourcit l'étape; l'action est avancée , ce qui passe directement à la phase suivante dans le flux principal. Ce modèle réduit la durée du cycle pour les cas simples sans supprimer l'étape Révision 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 de 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, il est incorrect de poursuivre la notification au requérant (qui fera référence à un paiement réussi). La règle de sortie arrête l'étape; l'action est Attendre la sélection manuelle pour qu'un opérateur de processus puisse choisir le chemin de récupération — une étape de réessai 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 suivante.

Cela signifie que les règles de sortie n’ont pas besoin de spécifier où va se dérouler le cas, elles spécifient uniquement le moment où l’étape s’arrête (et l’action décrit l’intention de haut niveau: faire progresser, attendre l’utilisateur, revenir à l’origine ou mettre fin au cas). La logique de routage réside 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 en premier, raisonnement de l'agent du Gestionnaire de 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 — Quand 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 la règle « When » correspond. La règle d’entrée refusée de l’étape secondaire — AdjusterDecisionMade Quand arrive IF adjusterDecision == "deny" — est évaluée comme vraie et l’étape s’active. Étant donné que Refusé est une étape secondaire, sa règle d'entrée est définie 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 (envoi d'un paquet de refus, génération d'un rapport d'audit). Lorsque toutes les tâches requises sont terminées, le cas se ferme via une règle Cas terminé .

Cette séparation des préoccupations — Les règles de sortie définissent quand s'arrêter, les règles d'entrée définissent quand commencer — maintient le plan de cas modulaire et maintenable. Chaque étape doit uniquement connaître 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 Lorsque survient.

Remarque :

L' agent du gestionnaire de 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 politiques configurées pour décider de l'action suivante - ou fait appel à un humain s'il ne peut pas déterminer le chemin correct.

Remarque :

Les règles de sortie sont basées sur l'étape uniquement. Les tâches n'ont qu'une règle Entrée - il n'y a pas de règle Terminer ou Quitter au niveau de la tâche. L’achèvement d’une tâche est déterminé par le travail sous-jacent (formulaire soumis, agent terminé, RPA renvoyé, etc.). Pour arrêter le travail à mi-parcours, 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 dans 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 complètes simples. Une règle complète doit décrire le chemin heureux: « toutes les tâches requises ont été effectuées» ou « la décision attendue a été prise». N’intégrez pas de logique d’exception dans la Règle complète.
• Utilisez les Règles de sortie pour les exceptions exceptionnelles. Réservez les Règles de sortie pour les conditions qui invalident réellement le traitement continu. 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.
• Surveiller 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 votre schéma d'entité de cas afin que les champs surveillés par une règle de sortie soient écrits par des tâches spécifiques et identifiables.
• Associer 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 capture le cas et l'achemine vers le chemin approprié. 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 surprendre lorsqu’une personne lit un plan de cas pour la première fois. Utilisez des noms et des commentaires clairs 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ègle d'étape, y compris les règles d'entrée, de complétion, de sortie et de réentrée.
• Créer un incident de demande d'indemnisation en 30 minutes — tutoriel de bout en bout pour créer et déployer un plan d'incident.
• Configuration du gestionnaire de cas - comment le gestionnaire de cas utilise d'abord les règles et le raisonnement de l'agent du gestionnaire de cas comme solution de secours pour orchestrer le cycle de vie du cas une fois les étapes terminées ou terminées.