Présentation de Maestro Case

Concepts de Maestro Case pour les tâches de longue durée et lourdes d'exceptions, y compris les cas d'utilisation de la gestion des cas, les surface d'outils et les composants de conception de base.

	Cas Maestro	BPMN Maestro	Flux Maestro
Le contenu s'applique à	✅	❌	❌

Vue d'ensemble (Overview)

Maestro Case orchestre un travail de longue durée et axé sur des objectifs sur une situation spécifique, un cas. Un cas contient des données, des règles, des tâches et l'historique pour générer un résultat auditable tel qu'un remboursement, une décision de demande d'indemnisation ou une fermeture d'enquête. Lorsque Maestro BPMN excelle à l'orchestration structurée et séquentielle, Maestro Case répond aux scénarios qui contiennent beaucoup d'exceptions, non linéaires et dépendent du jugement de l'agent humain et d'IA aux points de décision clés.

Ce document présente Maestro Case en tant que capacité distincte dans Maestro, présente les cas d'utilisation métier qu'il résout et quand le choisir plutôt que Maestro BPMN, vous donne une visite de l'ensemble d'outils avec lesquels vous travaillerez et présente les concepts fondamentaux que vous devez comprendre avant de créer votre premier cas agentique.

Audience : débutant à intermédiaire - architectes de solutions, analystes métier et développeurs qui évaluent ou commencent avec Maestro Case.

Pourquoi la gestion des cas

L'automatisation des processus traditionnels fonctionne mieux lorsque le flux de travail est prévisible et répétable. Cependant, de nombreux scénarios métier ne sont pas comme cela. Ils peuvent s'étendre sur des jours ou des semaines, impliquer plusieurs équipes et nécessiter des décisions qui ne peuvent pas être entièrement automatisées. Dans ces situations, les exceptions ne sont pas rares ; elles sont attendues.

La gestion des cas répond à ce défi en fournissant une structure sans rigidité. Il permet à l'automatisation et à l'IA de gérer le travail de routine ou répétable, tout en permettant aux humains d'intervenir lorsque des décisions de jugement ou de stratégie sont requises.

Points de difficulté que la gestion des cas résout

Point de blocage	Comment la gestion des cas le résout
Aucune construction de cas persistante ou suivi du cycle de vie	Présente une entité de cas [Bientôt disponible] avec un cycle de vie complet, un état et un historique
Aucune modélisation d'étape native	Ajoute une zone de dessin d'étape visuelle pour définir les étapes séquentielles et les transitions
Aucune transition au moment de la conception ou renouvellement ciblé	Permet les transitions d'étape basées sur des règles et le renouvellement à la tâche exacte dans une étape précédente
Contrôle limité du SLA et de l'escalade	Prend en charge le suivi des SLA aux niveaux du cas, de l'étape et de la tâche, avec des règles d'escalade et de pause/reprise
Aucune expérience unifiée pour les responsables de cas et les responsables	Fournit l'application du cas pour la collaboration, la gestion des tâches et la visibilité
Aucune flexibilité pour le travail ad hoc	Permet la création de tâches ad hoc de runtime pour les exceptions ou les examens supplémentaires

Quand utiliser la gestion des cas

La gestion des cas est plus efficace lorsque le travail ne peut pas être entièrement défini dès le départ. Ces scénarios impliquent souvent plusieurs étapes, des points de décision fréquents et une collaboration entre différents groupes d'utilisateurs ou systèmes. La progression dépend non seulement de l'achèvement des tâches, mais de l'évaluation des résultats et de la décision de ce qui doit se produire ensuite.

Scénarios métier

Scénario	Pourquoi la gestion des cas
Réclamations d'assurance	Longue durée, multipartite (demandeur, expert en sinistres, inspecteur), exceptions fréquentes (documents manquants, litiges), piloté par SLA
Litiges et rétrofacturations	Aller-retour entre les parties, collecte de preuves, chemins d'escalade, progression non linéaire
Octroi et souscription de prêts	Plusieurs étapes d'examen (crédit, conformité, souscription), chemins conditionnels basés sur les scores de risque, les exigences réglementaires
Remédiation KYC/AML	Collecte de documents à toutes les étapes, points de décision réglementaires, exigences de la piste d'audit
Escalades et plaintes de clients	Résolution à plusieurs niveaux, renouvellement lorsqu'un correctif ne tient pas, engagements SLA, transferts entre plusieurs équipes
Exceptions d'exécution des commandes	Commandes en attente, expéditions partielles, retours - coordination multi-systèmes avec suivi des SLA
Enquêtes et signalements dans le secteur public	Approbations ad hoc, coordination inter-départements, routage basé sur les stratégies
Intégration du fournisseur	Vérification en plusieurs étapes (juridique, conformité, finance), étapes conditionnelles en fonction du type de fournisseur, collecte de documents

La gestion des cas ajoute de la valeur lorsque

• Le travail est de longue durée - il s'étend sur des heures, des jours ou des semaines plutôt que des secondes.
• Le processus contient beaucoup d'exceptions- l'étape suivante dépend de ce qui vient de se produire et aucun flowchart ne capture chaque chemin.
• Plusieurs rôles et systèmes sont impliqués - les responsables de cas, les gestionnaires, les agents d'IA et les intégrations externes contribuent tous.
• Le suivi et l'escalade des SLA sont critiques - les échéances comptent et les violations doivent déclencher des actions spécifiques.
• Les pistes d'audit sont requises - chaque décision, modification de données et transition doit être enregistrée.
• Les boucles de renouvellement et de révision sont courantes - les cas reviennent fréquemment à des étapes antérieures pour des corrections ou une enquête supplémentaire.

La gestion des cas n'est pas requise lorsque

Tous les processus ne nécessitent pas une gestion des cas. Si un processus est de courte durée, prévisible et suit à chaque fois la même séquence, un Maestro BPMN est souvent plus simple et plus efficace.

Remarque :

Test rapide : si l'étape suivante dépend de ce qui vient de se produire et qu'aucun flowchart ne peut capturer chaque chemin, envisagez la gestion des cas. Si le processus suit le même chemin à chaque fois, utilisez Maestro BPMN.

Fondations partagées

Les deux types de projet réutilisent les mêmes services UiPath Platform et types de tâches :

• Workflows RPA pour UI Automation dans les systèmes hérités.
• Workflows d'API et intégrations pour les opérations de système à système.
• Agents d'IA (UiPath ou externe) pour les tâches non déterministes.
• Tâches humaines via les Apps d'action pour les formulaires, les approbations et les examens.
• Data Fabric pour la gestion des données d'entreprise et la connectivité des données.
• Studio Web comme environnement de conception.

Principales différences

Cote	BPMN Maestro	Cas Maestro
Structure de travail	Séquence définie d'étapes modélisées dans la notation BPMN	Étapes nommées avec des transitions basées sur des règles ; le chemin de runtime est déterminé dynamiquement
Cycle de vie	Généralement de courte à moyenne durée ; suit un flux prédéterminé	Longue durée et axé sur des objectifs ; évolue à mesure que de nouvelles informations deviennent disponibles
Flux non linéaire	Possible via les passerelles et les boucles BPMN, mais complexe à modéliser pour les scénarios très variables	Prise en charge intégrée pour le renouvellement, les étapes secondaires, les règles d'omission et les tâches ad-hoc
Modèle de données	Variables de processus définies sur l'instance	Variables de cas étendues à l'instance + Entité de cas persistante [Bientôt disponible] - un enregistrement métier central et typé que toutes les étapes, les tâches et les conditions lisent et écrivent
SLA et escalades	Non modélisé en natif au niveau du processus	Constructions de première classe au niveau du cas et de l'étape, avec des règles d'escalade en cas de risque et de violation
Expérience utilisateur	Surveillé via l'onglet Surveillance Maestro pour les opérateurs	Application du cas dédiée pour les utilisateurs professionnels (liste de cas, vue détaillée, boîte de réception des tâches) et gestion des instances de cas pour les opérateurs
Accès basé sur les rôles	Autorisations de la Standard Platform	Personas tenant compte de l'étape - définissez qui peut consulter et agir dans chaque étape
Travail ad hoc	Non pris en charge ; toutes les étapes sont définies au moment de la conception	Pris en charge - le gestionnaire de cas ou un utilisateur humain peut créer des tâches lors du runtime

Un cas peut invoquer un Maestro BPMN comme l'un de ses types de tâche et un Maestro BPMN peut invoquer un cas comme l'un de ses types de tâche, ce qui rend les deux types de projet complémentaires plutôt que de rivaliser. Utilisez Maestro BPMN pour les sous-processus bien définis et Maestro Case comme couche d'orchestration externe lorsque le flux global est dynamique.

Conçu dès le départ pour privilégier l'agent

La gestion des cas est la bonne forme pour les tâches de longue durée et contenant beaucoup d'exceptions, mais elle s'appuie toujours sur des travailleurs ayant des connaissances humaines pour effectuer la plupart des appels de routage et de jugement. Maestro Case est agentique d'abord et natif de l'IA : les agents d'IA sont des participants de première classe dans le cas et opèrent à deux niveaux distincts :

• En tant qu'opérateurs de tâches dans les étapes - catégorisation des données, signalement des anomalies, extraction de champs de documents, rédaction de réponses, vérification des stratégies. Chaque agent s'exécute dans une tâche, lit ce dont il a besoin dans l'entité de cas [Bientôt disponible] , fait son travail et réécrit ses résultats.
• En tant qu'orchestrateur du cas lui-même - l'agent gestionnaire de cas gère le cas de la création à la fermeture, en prenant des décisions au niveau de l'étape et de la tâche : quelle étape activer ensuite, quelles tâches exécuter à cette étape, quand une tâche ou une étape est terminée ou doit se terminer tôt et quand escalader. Il fonctionne aux côtés de règles déterministes là où elles existent, et raisonne sur les données de cas et les stratégies là où elles n'existent pas.

Cela élimine le goulot d'étranglement traditionnel qui consiste à s'appuyer uniquement sur les travailleurs ayant des connaissances humaines pour prendre des décisions de routage, gérer les exceptions et faire avancer les cas. Les humains interviennent lorsque la stratégie, le jugement ou la responsabilité le nécessite, non parce que le cas ne peut pas progresser sans eux.

Ensemble d'outils Maestro Case

Maestro Case couvre le cycle de vie de bout en bout du cas via trois surfaces complémentaires :

Concepteur de plan de cas (Studio Web)

À qui il s'adresse : Automation Developers et architectes d'entreprise.

Utilisez-le pour créer ou mettre à jour un plan de cas - étapes, transitions, SLA, escalades et accès au niveau de l'étape. Joignez les implémentations aux tâches (Humain, RPA, API, Agent d'IA, Processus agentique, Cas enfant). Mappez les entrées et les sorties et définissez le comportement de renouvellement. La sortie est un plan de cas versionné prêt à être publié et déployé.

Gestion des instances de cas (Maestro)

À qui il s'adresse : les opérateurs de processus, les gestionnaires de cas et les propriétaires de processus.

Utilisez-le pour gérer des cas en cours avec des contrôles du cycle de vie (Pause, Reprendre, Annuler, Migrer) et un audit complet. Résolvez les incidents en relançant les tâches échouées ou en migrant les instances vers des versions plus récentes de plan de cas. Utilisez des Insights en direct, des cartes thermiques et Process Mining pour repérer les goulots d'étranglement et intégrer les améliorations à la conception.

Application du cas (Maestro)

À qui il s'adresse : les responsables et les gestionnaires de cas.

Utilisez-le pour afficher tous les cas et leurs détails (chronologie, données du cas, tâches humaines) et effectuer des actions rapides telles que Terminer et Rouvrir. L'application du cas est un workspace spécialisé et centré sur le cas - listes, détails, tâches et vues SLA. Les formulaires de tâches humaines continuent d'être créés avec les Apps d'action et référencés par les tâches de cas.

L'application du cas se décline en deux options :

Option	Description	Quand l'utiliser
Application du cas prête à l'emploi	Un workspace de cas pré-construit et sans code qui est livré avec Maestro Case. Les listes, les vues détaillées, la boîte de réception des tâches et les vues SLA sont configurées automatiquement à partir de votre plan de cas et de votre entité.	La valeur par défaut - utilisez-la pour les opérations de cas rapides sans écrire de code.
Application du cas codée personnalisée	Une application du cas sur mesure que vous créez à l'aide du SDK TypeScript pro-code. Vous permet de créer des vues personnalisées, des mises en page et des workflows sur le même runtime de cas.	Lorsque vous avez besoin d'une IU au-delà de ce que l'application prête à l'emploi expose - espaces de travail de marque, tableaux de bord personnalisés ou expériences de cas spécifiques à un domaine.

Remarque :

L'application du cas est distincte des UiPath Apps. L'application du cas est spécialement conçue pour les opérations de cas. UiPath Apps est un générateur low-code à usage général pour les applications métier entièrement personnalisées ou composées. Utilisez l'application du cas pour les opérations de cas rapides ; utilisez UiPath Apps lorsque vous avez besoin d'une IU sur mesure au-delà des opérations de cas.

Concepts de base

Comprendre les concepts suivants est essentiel avant de concevoir un cas agentique.

Cas et clé de cas

Un cas représente une situation métier réelle qui doit être résolue - une réclamation, un litige, une enquête. Contrairement à une instance de processus traditionnelle, un cas évolue au fil du temps à mesure que de nouvelles informations deviennent disponibles et que des décisions sont prises.

Chaque cas est identifié de manière unique par une clé de cas :

TypeClé	Description	Exemple
Clé système	Généré automatiquement par Maestro lors de la création du cas.	HC-1234, CLM-00891
Clé externe (définie par le client)	Un ID en amont transmis lors de la création afin que le même cas réel soit reconnu dans tous les outils	Numéro de cas CRM, numéro de stratégie, ID de commande ERP

Utilisez des clés externes lorsque le cas provient d'un autre système (CRM, ERP, outil de tickets) afin que les humains et les intégrations puissent corréler le cas entre les outils sans maintenir une table de mappage distincte.

Entité du cas

L'entité de cas [Bientôt disponible] est l'enregistrement métier persistant et typé au centre de chaque cas. Il s'agit de la source unique de vérité que les étapes, les tâches et les conditions de transition lisent et écrivent tout au long du cycle de vie du cas.

Chaque projet de cas inclut également deux objets de données prêts à l'emploi supplémentaires :

• Documents de cas - pièces jointes et fichiers associés au cas (reçus, photos, contrats).
• Commentaires sur les cas - notes, annotations et communications ajoutées par les responsables de cas et les gestionnaires pendant l'exécution.

Les trois objets partagent un champ système caseID immuable généré lors de la création du cas.

Vous pouvez apporter l'entité du cas dans Maestro Case de trois manières :

Source	Description	Quand l'utiliser
Object Data Fabric natif	Activez le commutateur de l'entité du cas dans votre projet de cas, qui crée et lie automatiquement une entité de cas Data Fabric native à votre cas	Nouveaux processus où vous possédez le modèle de données
Système d'enregistrement via VDO	Enregistrez une source externe en tant que Virtual Data Object (VDO) dans Data Fabric, activez le commutateur de l'entité de cas et établissez une relation entre le VDO et l'entité de cas dans Data Fabric	Les données de l'entité se trouvent dans un système externe et vous souhaitez les référencer sans les dupliquer
Système d'enregistrement via le déclencheur de cas	Transmettez les données existantes dans le déclencheur de création de cas (par exemple, via un connecteur d'API) ; les champs deviennent des champs de cas disponibles tout au long du cas	Intégrations légères dans lesquelles vous attribuez une valeur au cas au moment de la création

Étapes

Les étapes sont les phases nommées d'un cas, par exemple, Admission, Examen, Règlement, Fermeture. Une étape est, en effet, une collection de tâches qui font avancer le cas vers la condition complète de l'étape.

Étapes primaires vs. secondaires

Maestro Case prend en charge deux types d'étapes :

Type d'étape	Objectif	Comment elle est atteinte	Visibilité dans l'application du cas
Étape primaire	La progression attendue du cas (par exemple, Admission → Examen → Règlement → Fermeture).	Peut être entré via les arêtes d'une étape précédente sur la zone de dessin ou par sa condition d'entrée configurée ; les deux sont valides.	Affichés comme nœuds d'étape de base dans la chronologie de l'application du cas ; ce sont les étapes que les responsables de cas voient comme le cycle de vie principal.
Étape secondaire	Exception ou chemins alternatifs qui peuvent se produire à tout moment pendant le cas (par exemple, Demande d'info, Refusé, Retiré, Annulé).	Aucune arête entrante - l'activation du commutateur d'une étape comme secondaire les supprime. L'étape est atteinte uniquement lorsque sa condition d'entrée est évaluée comme vraie et peut s'activer chaque fois que cela se produit, quel que soit l'endroit où se trouve actuellement le cas.	Ne fait pas partie de la chronologie de l'étape de base. Apparaissent séparément lorsqu'ils sont actifs (par exemple, en tant qu'indicateur de chemin d'exception), car ils peuvent se déclencher à n'importe quel moment.

En d'autres termes, le marquage d'une étape comme secondaire signifie : ne me connectez pas dans le cycle de vie principal ; je m'active moi-même chaque fois que ma condition d'entrée est remplie. C'est ce qui permet à un cas de passer dans Demande d'info à mi-examen ou dans Retiré de n'importe où, sans que le concepteur ait à tracer des liaisons de toutes les sources possibles.

Attributs de l'étape

Chaque étape définit :

• Condition d'entrée - lorsque cette étape commence.
• Condition d'achèvement - ce qui doit être vrai pour marquer l'étape comme terminée et avancer.
• Condition de sortie - quand quitter l'étape tôt (par exemple, scénarios d'abandon ou de réacheminement).
• Condition de renouvellement - comment les routages de révision ou de retour à l'origine vous ramènent ici.
• SLA d'étape et escalades - échéance, seuils d'avertissement et destinataires de la notification d'escalade et de l'e-mail.

Les étapes peuvent être marquées comme requises ou facultatives. Un cas ne peut pas se terminer tant que chaque étape requise n'a pas été terminée. Les étapes facultatives s'activent uniquement lorsque leurs conditions d'entrée sont remplies et peuvent être ignorées sans bloquer le cas.

Étapes parallèles

Plusieurs étapes peuvent être actives dans le même cas en même temps. Par exemple, une étape de communication avec le client peut s'exécuter parallèlement à la souscription pendant que le règlement se prépare en arrière-plan. Le fait que les étapes s'exécutent en parallèle ou en séquence est contrôlé par les règles d'entrée.

Tâches

Une tâche est une unité de travail dans une étape.

Types de tâches

Maestro Case prend en charge les types de tâches suivants :

Type de tâche	Description
Action humaine	Formulaires, approbations et clarifications affectés à une personne
Workflow RPA	UI Automation pour les systèmes hérités, extraction et réconciliation
Workflow d’API	Opérations de système à système via le workflow
Exécuter le connecteur	Invoquer une activité de connecteur (par exemple, envoyer une notification, créer un enregistrement dans un système externe)
Agent d'IA (UiPath)	Raisonnement autonome sur les données pour un travail basé sur le jugement
Agent externe	Agent d'IA tiers invoqué via l'API
Processus agentique Maestro	Un processus BPMN en plusieurs étapes invoqué comme tâche
Cas enfant	Un autre cas est généré en tant que cas enfant avec son propre cycle de vie
Attendre le minuteur	Mettre en pause jusqu'à ce qu'une durée s'écoule ou qu'une date cible soit atteinte
Attendre l’événement du connecteur	Mise en pause jusqu'à ce qu'un événement externe arrive via un connecteur

Modes d'exécution

Indépendamment de son type, chaque tâche s'exécute dans l'un des trois modes d'exécution qui déterminent quand elle démarre :

Mode d’exécution	Comportement	Exemple
Séquentielle	La tâche s'exécute dans un ordre défini dans l'étape. Une séquence peut également inclure des branches parallèles qui se prolongent et se reconnectent avant l'étape suivante.	Dans une étape de souscription : Verify income → (Run credit check ∥ Pull employment history) → Calculate DTI → Generate decision
Généré par les événements	La tâche a une règle d'entrée et se déclenche chaque fois que l'événement rend la règle évaluée comme vraie ; même si l'étape est en cours d'exécution ou si la séquence a déjà dépassé ce point. Elle peut se déclencher plus d'une fois si l'événement se répète.	Dans une étape de traitement des réclamations : Request additional documents se déclenche WHEN une tâche de vérification signale un document manquant IF Documents.Missing == true ; quelle que soit la position actuelle de l'étape dans sa séquence
Ad hoc	La tâche est définie dans le plan de cas, mais commence uniquement lorsqu'un utilisateur la déclenche manuellement lors du runtime. Les tâches ad hoc peuvent être de n'importe quel type de tâche répertorié ci-dessus.	Dans une étape d'escalade du client : Escalate to supervisorou Add fraud review - déclenché par le responsable de cas après jugement

Plusieurs tâches peuvent être actives dans la même étape en même temps. Les branches séquentielles peuvent se déployer en chemins parallèles et se réunir avant l'étape suivante. Les tâches pilotées par des événements se déclenchent indépendamment de la séquence et s'exécutent fréquemment en parallèle avec toute autre chose en cours d'exécution, y compris plusieurs instances de la même tâche pilotée par des événements si son événement de déclenchement se répète. Les tâches ad hoc peuvent être lancées à tout moment parallèlement aux tâches en cours d'exécution.

Exécuter une seule fois

Lorsqu'une étape est réintroduite, vous contrôlez les tâches qui doivent être réexécutées à l'aide de l'indicateur Exécuter une seule fois sur chaque tâche :

• Exécuter une seule fois = vrai - la tâche est ignorée lors du renouvellement. Sa sortie précédente est conservée et la tâche ne s'exécute pas à nouveau.
• Exécuter une seule fois = faux (par défaut) - la tâche se réinitialise et s'exécute à nouveau chaque fois que l'étape est réexécutée, ce qui produit une nouvelle sortie.

Exemple : dans une étape de collection de documents, la tâche Send document checklist to customer est marquée comme exécutée une seule fois ; vous ne souhaitez pas réenvoyer un e-mail au client chaque fois que l'étape se rouvre pour une raison différente. La tâche Validate documents est laissée avec la valeur par défaut afin que chaque nouvelle soumission soit fraîchement validée.

Autres configurations de tâche

Chaque tâche prend également en charge les entrées et les sorties mappées à l'entité de cas.

Règles

Les règles contrôlent le mouvement du cycle de vie et sont le mécanisme qui rend la gestion des cas non linéaire. Elles suivent le modèle CMMN (Case Management Model and Notation) et sont pilotées par les événements — une règle se déclenche uniquement lorsqu'un événement pertinent se produit sur l'incident, et non sur un calendrier d'interrogation ou une séquence fixe.

Chaque règle a trois parties :

• WHEN - l'événement qui déclenche l'évaluation. Les événements sont de deux types :
  • Événements internes émis par le cycle de vie du cas lui-même - CaseCreated, StageEntered, StageCompleted, StageExited, TaskCompleted, CaseSlaAtRisk, CaseSlaBreached, StageSlaAtRisk, StageSlaBreached, et les modifications apportées aux champs de l'entité du cas réécrits par des tâches.
  • Événements externes arrivant de l'extérieur du cas - Événements du connecteur Integration Service (webhooks, messages de file d'attente), déclenchements de minuteurs, achèvement ou sortie du cas enfant et appels d'API directs vers le cas.
• IF (facultatif) - la condition de l'entité du cas qui doit également être vraie pour que la règle prenne effet. Si omis, la règle se déclenche lors de chaque événement WHEN correspondant.
• ACTION - ce que la règle fait lorsqu'elle se déclenche (démarrer une étape, terminer une étape, quitter une étape, terminer le cas, etc.).

Les règles sont définies à l'un des trois niveaux : cas, étape ou tâche.

Règles au niveau du cas

Règles	Objectif	Exemple
Fin de cas	Marquez l'ensemble du cas comme terminé (résultat réussi).	WHEN toutes les étapes requises sont terminées IF Outcome == "Approved"
Sortie du cas	Mettez fin au cas avant qu'il n'atteigne son achèvement normal (annulation, retrait, fraude).	Quand Application.Status modifie IF Application.Status == "Withdrawn"

Règles au niveau de l'étape

Règles	Objectif	Exemple
entrée	Point de passage lorsque l'étape commence.	Quand Application.Submitted l'événement arrive IF Application.Type == "Mortgage" && Documents.Count > 0
Terminer	Décidez quand l'étape se termine normalement.	WHEN une tâche de l'étape se termine IF toutes les tâches requises sont Done et UnderwritingDecision != null
Quitter	Quittez l'étape rapidement, même si elle est incomplète.	Quand UnderwritingDecision modifie IF UnderwritingDecision == "Reject"
Renouvellement	Revenez à une étape précédemment terminée pour une révision contrôlée.	Quand Verification.Result modifie IF Verification.Result == "Failed" && DocsComplete == false

Les règles d'entrée comportent un commutateur d'interruption qui contrôle ce qui arrive aux autres étapes actives lorsque la règle d'entrée est évaluée comme vraie :

• Interruption = vrai : toutes les étapes actuellement actives sont automatiquement quittées et le cas est forcé à entrer dans la nouvelle étape. Utilisez cela pour les chemins d'exception difficiles tels que Retiré ou Suspension de la fraude qui doivent prendre immédiatement en charge le cas.
• Interruption = faux - la nouvelle étape s'active aux côtés de toutes les étapes actives existantes. Le cas peut avoir plusieurs étapes s'exécutant en parallèle.

Les valeurs par défaut diffèrent par type d'étape : pour les étapes primaires, l'interruption est définie par défaut sur faux (jonction en parallèle - la progression normale du travail). Les étapes secondaires sont définies par défaut sur Interruption = vrai (prenez en charge le cas, car les étapes secondaires représentent des exceptions ou des chemins alternatifs). Les deux valeurs par défaut peuvent être remplacées par étape.

Les règles d'achèvement et de sortie portent également une action qui détermine ce qui arrive au cas après la fin de l'étape :

• Terminez le cas/ Quittez le cas - terminez ou mettez fin au cas à partir d'ici.
• Attendez la sélection manuelle - mettez en pause et laissez un utilisateur choisir l'étape suivante.
• Retour à l'origine - renvoyez le cas vers l'étape qui a activé celle-ci à l'origine.

Règles au niveau de la tâche

Règles	Objectif	Exemple
entrée	Point de contrôle lorsqu'une tâche commence dans une étape. Utilisé par les tâches pilotées par des événements pour exécuter un événement déclencheur et éventuellement par des tâches séquentielles ou ad hoc pour protéger l'exécution.	WHEN une tâche de vérification signale un document manquant IF Documents.Missing == true

Étant donné que les règles sont basées sur les événements, le cas n'exécute pas une séquence fixe - les étapes et les tâches s'activent, se terminent, sortent ou se rouvrent chaque fois que leur événement WHEN arrive et que la condition IF (si présente) est évaluée comme vraie par rapport à l'entité de cas actuelle. La réexécution des tâches lors du renouvellement de l'étape est contrôlée par l'indicateur Exécuter une seule fois décrit dans la section Tâches ci-dessus.

Gestionnaire d’incidents

Le gestionnaire de cas est l'orchestrateur d'un cas - l'agent qui conduit les décisions du cycle de vie en fonction d'événements. Il décide l'étape à activer ensuite, les tâches à démarrer, le moment où une étape doit se terminer ou quitter prématurément et le moment de l'escalade.

Il orchestre à l'aide de deux méthodes complémentaires :

1. Règles (primaire) - pour chaque point de décision, le gestionnaire de cas évalue d'abord les règles CMMN déterministes définies dans le plan de cas. Lorsqu'une règle résout la décision, elle est prise. Cela maintient les chemins nominaux à haut volume prévisibles, vérifiables et économiques.
2. Agent (secours) - lorsqu'aucune règle ne couvre la situation (un écart, une exception ou une décision discrétionnaire), le gestionnaire de cas raisonne sur l'entité du cas, le plan de cas et les stratégies et les connaissances disponibles pour choisir l'action suivante. C'est ce qui permet à un cas de continuer à progresser sans escalade vers un humain pour chaque branche non couverte.

Pour gérer un cas, l'agent du gestionnaire de cas doit se conformer à un contrat d'entrée/sortie défini qui spécifie l'état du cas, les événements et les stratégies qu'il peut lire et les décisions d'étape/tâche qu'il peut émettre. Consultez le contrat de l'agent gestionnaire de cas pour obtenir la spécification complète.

SLA et escalades

Définissez les SLA et les règles d'escalade au niveau du cas et de l'étape :

• SLA au niveau du cas - cible de résolution globale (par exemple, résoudre dans les 48 heures).
• SLA au niveau de l'étape - délai d'échéance localisé (par exemple, examen dans les 24 heures).
• État de la SLA - en cours, à risque ou non respecté. Ces états font surface sous forme de badges dans les listes de cas et les vues détaillées.
• Escalades - règles déclenchées lorsqu'une SLA est à risque ou non respectée (par exemple, réaffecter, notifier la direction, créer un indicateur de priorité).
• Mettre en pause/Reprendre - Les minuteurs SLA peuvent être mis en pause lorsque le cas attend une entrée externe et repris lorsqu'il est à nouveau possible d'agir.

Personas de cas

Maestro Case applique l'accès tenant compte de l'étape via des personas afin que les bonnes personnes voient et agissent au bon moment :

Un Case Persona est une abstraction de conception représentant un rôle dans un type de cas (par exemple, agent d'admission, expert en sinistres, superviseur). Les personas dissocient les besoins d'accès d'un cas de la structure d'identité de l'organisation, ce qui rend les définitions de cas portables entre les organisations et les locataires.

• Au moment de la conception, le concepteur de cas crée des personas et définit la portée de chacun pour des étapes spécifiques.
• Au moment du déploiement, un administrateur lie chaque persona à des utilisateurs ou des groupes d'utilisateurs, de sorte que le même type de cas peut avoir différentes étendues dans différents environnements.
• Lors du runtime, le système résout le ou les personas de l'utilisateur et applique l'étendue de l'étape en conséquence. Un utilisateur avec plusieurs personas obtient l'union des étendues de l'étape.

Par exemple, un cas de traitement d'un prêt peut définir :

Utilisateur	Application	Vérification	Souscription	Déboursement
Responsable de prêts	oui
Analyste de vérification		oui
Souscripteur			oui
Directeur d'agence	oui	oui	oui	oui

Les tâches d'une étape sont affectées à un persona, et non à un utilisateur spécifique. Le système résout le persona en rôle/groupe aux utilisateurs lors du runtime pour déterminer la visibilité et l'affectation de la tâche.

Remarque :

La prise en charge complète des rôles d'utilisateur et de l'accès pour les cas sera bientôt disponible.

Facturation et consommables

Maestro Case suit la même facturation que Maestro. Le travail qui s'exécute dans un cas consomme les ressources natives des types de tâche que vous utilisez : agents d'IA, workflows RPA, workflows d'API ou connecteurs IS.

Prochaines étapes

• Créez votre premier projet Maestro Case - Un tutoriel étape par étape qui explique la création, le déploiement et le test d'un cas de sinistre d'assurance habitation à partir de zéro.
• Référence des constructions de base - Référence détaillée pour chaque construction de Maestro Case : entité de cas [Bientôt disponible] , étapes, tâches, conditions de transition, SLA et personas.
• Comment configurer les transitions d'étape et le renouvellement - Un guide pratique pour la modélisation de flux de cas non linéaires avec des conditions d'entrée, de sortie et de renouvellement.