Le cycle de vie de Maestro Case : du déclencheur d'événement à l'expérience de l'application

Cycle de vie de Maestro Case à partir des déclencheurs d'événements en passant par les données de l'entité de cas, les règles de plan de cas, les décisions du gestionnaire de cas, l'exécution de la tâche et les expériences de l'application du cas.

Vue d'ensemble (Overview)

Un cas est un objet métier de longue durée - une demande d'indemnisation, un litige, une enquête, un prêt - qui survit à toute tâche ou session et passe de manière non linéaire par les étapes à mesure que les données et les décisions s'accumulent. Maestro Case pilote ce cycle de vie de bout en bout : un événement crée le cas, un plan de cas définit les étapes possibles et les règles qui régissent les transitions, le gestionnaire de cas décide ce qui se passe ensuite à l'aide de l'orchestration axée sur les règles avec la solution de secours de l'agent gestionnaire de cas et l'application du cas expose le travail en direct aux utilisateurs professionnels.

Ce document suit les données à travers chaque couche de la pile - déclencheurs → entité de cas [Bientôt disponible] → plan de cas → gestionnaire de cas → tâches → expérience de runtime - afin que vous puissiez former un modèle mental précis avant de concevoir votre premier plan de cas.

Audience : Intermédiaire à Avancé - Automation Developers, Solution Architects, Business Architects

Pourquoi comprendre la pile complète

Maestro Case n'est pas une fonctionnalité unique. Il s'agit d'un système coordonné de définitions au moment de la conception (plan de cas, entité de cas [Bientôt disponible], étapes, tâches, règles) et de moteurs de runtime (gestionnaire de cas, application du cas, gestion des instances de cas). Comprendre le cycle de vie complet vous aide à :

• Concevoir des plans de cas robustes qui tiennent compte de la nature non linéaire du travail dans le monde réel.
• Éviter les pièges courants tels que le séquençage rigide des étapes, la responsabilité peu claire des champs ou la logique de renouvellement manquante.
• Communiquer entre les rôles - du développeur qui modélise les étapes dans Studio Web au gestionnaire de cas qui termine les tâches dans l'application du cas.

Architecture en un coup d'œil

La pile Maestro Case se compose de cinq couches. Les données circulent vers le bas à partir de sources d'événements via l'orchestration et l'exécution et remontent vers le haut dans l'expérience utilisateur métier.

Les sections ci-dessous parcourent chaque couche dans l'ordre de circulation des données.

Couche 1 - Déclencheurs d'événements (comment un cas commence)

Les déclencheurs d'événements sont les points d'entrée qui créent une instance de cas et hydratent l'entité du cas [Bientôt disponible] avec les données initiales. Un seul plan de cas peut définir plusieurs déclencheurs afin que le même type de cas puisse provenir de différents canaux.

Source du déclencheur	Description	Exemple
Entité Data Fabric	Un événement « Ligne créée » sur une entité Data Fabric ou un VDO déclenche le cas. Les champs de l'entité deviennent des champs de cas.	Une nouvelle ligne dans une entité Home Claims crée un cas d'assurance habitation.
Attendre le connecteur	Un événement de connecteur Integration Service (appel d'API, webhook, message) déclenche le cas. La charge utile de l'API est traitée comme entité de cas.	Un message de canal Microsoft Teams déclenche une étape Retiré.
Portail / Formulaire	Un utilisateur envoie des données via un formulaire Web.	Un employé soumet un rapport de dépenses via un portail en libre-service.
E-mail (Email)	Un e-mail entrant est analysé et ses données sont mappées aux champs de l'entité.	Un e-mail de reçu transféré crée un nouvel élément de ligne de demande d'indemnisation.
API	Un système externe appelle le point de terminaison de création de cas.	Un système ERP déclenche un incident de cas sur un événement de stratégie.
Planifié	Un déclencheur basé sur le temps crée ou suit les cas.	Une tâche quotidienne crée des cas de suivi pour les éléments obsolètes.

Chaque déclencheur mappe ses données entrantes aux champs de l'entité du cas. Ce mappage initial, parfois appelé hydratation, détermine les données qui sont disponibles pour chaque étape en aval, tâche et condition de transition.

Remarque :

Un plan de cas peut avoir plus d'un déclencheur. Par exemple, un incident de réclamation d'assurance peut accepter les soumissions d'un portail, d'un analyseur d'e-mails et d'une API de transcription d'appel téléphonique, le tout mappé à la même entité AutoInsuranceClaim.

Couche 2 - l'entité du cas (source unique de vérité)

L'entité du cas [Bientôt disponible] est l'objet de données persistant et structuré au centre de chaque instance de cas. Il est actif pendant toute la durée de vie du cas et sert de source unique de vérité que toutes les étapes, les tâches et les conditions de transition lisent et écrivent.

Objets de données prêts à l'emploi

Chaque projet d'incident crée automatiquement trois objets de données :

Objet	Objectif
Entité du cas	Le modèle de données métier central. Contient les données structurées utilisées par les conditions et les tâches.
Documents d'incident	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 participants tout au long du cycle de vie.

Les trois partagent un champ système caseID immuable qui est automatiquement généré lors de la création du cas et lie toutes les données du cas.

Comment les données atteignent l'entité

Source	Mécanisme
Natif dans Data Fabric (recommandé)	Créez une entité métier dans Data Fabric et liez-la au cas.
VDO dans Data Fabric	Enregistrez une source de données externe en tant que Virtual Data Object et liez le VDO.
Charge utile du déclencheur d'incident	Transmettez les données via le déclencheur (par exemple, un connecteur d'API). Les champs de charge utile deviennent des champs de cas.

Pourquoi une entité centrale est importante

• Indépendance des tâches - Les tâches n'ont pas besoin de se connaître. Chaque tâche lit et écrit dans l'entité via les mappages d'entrée/sortie.
• Contexte d'orchestration - Le gestionnaire de cas évalue les règles de transition par rapport aux champs de l'entité. Lorsqu'une tâche réécrit adjusterDecision = "approve" dans l'entité, les règles d'entrée en aval qui font référence à adjusterDecision sont immédiatement évaluées.
• Piste d'audit - Chaque modification apportée à l'entité est suivie avec qui, quand et ce qui a changé.
• Source unique de vérité - Il n'y a aucune ambiguïté sur l'état actuel du cas pour tout participant ou système.

Le modèle de réécriture

Le modèle de réécriture est le mécanisme principal pour le déplacement des données dans un cas :

1. Une tâche lit des champs spécifiques de l'entité du cas via le mappage d'entrée.
2. La tâche effectue son travail (validation, raisonnement de l'agent, examen humain, extraction RPA).
3. La tâche écrit ses résultats dans l'entité du cas via le mappage de sortie.
4. Les valeurs de l'entité mises à jour provoquent la réévaluation des règles de transition, ce qui active potentiellement l'étape ou la tâche suivante.

Task A writes → Case Entity updates → Rules evaluate → Next stage activates

Ce modèle maintient les tâches découplées. Une tâche de connecteur « Valider la stratégie » et une tâche d'agent « Analyser les photos » ne communiquent pas directement. Au lieu de cela, chacun enrichit l'entité et le gestionnaire de cas lit l'entité pour décider de ce qui se passe ensuite.

Remarque :

Concevez le schéma de votre entité afin que chaque champ soit écrit par exactement une tâche. Si plusieurs tâches écrivent dans le même champ, la dernière opération d'écriture l'emporte et les données antérieures sont perdues. Utilisez des champs avec espace de noms (par exemple, validation.result vs. categorization.result) pour éviter les collisions.

Couche 3 - le plan de cas (plan au moment de la conception)

Le plan de cas est le plan visuel que vous créez dans Studio Web. Il définit les phases possibles qu'un cas peut traverser et les règles qui régissent les transitions. Contrairement à un workflow linéaire, un plan de cas ne prescrit pas un seul chemin fixe. Le chemin réel est déterminé lors du runtime en fonction des données et des décisions.

Un plan de cas se compose de quatre éléments :

• Déclencheurs d'événements - les événements qui créent ou influencent une instance de cas (décrits dans la couche 1).
• Étapes - les phases nommées du cas.
• Tâches - les éléments de travail de chaque étape.
• Règles - les définitions WHEN/IF/ACTION qui régissent l'entrée, l'achèvement, la sortie et le renouvellement des étapes et des tâches.

Étapes

Les étapes sont les phases majeures par lesquelles un cas passe - par exemple, Admission, Examen, Règlement, Fermeture. Une étape est, en effet, une collection de tâches qui font avancer le cas vers la règle d'achèvement de l'étape. 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 règle d'entrée configurée.	Affichés comme nœuds d'étape de base dans la chronologie de l'application du cas - le principal cycle de vie que voient les responsables de cas.
Étape secondaire	Exception ou chemins alternatifs qui peuvent se produire à tout moment (par exemple, En attente avec le client, Refusé, Retiré).	Aucune arête entrante - l'activation/désactivation du secondaire les supprime. Atteint uniquement lorsque sa règle d'entrée est évaluée comme vraie, et peut s'activer à n'importe quel point du cas.	Apparu séparément lorsqu'il est actif (ne fait pas partie de la chronologie de base).

Chaque étape définit :

• Règle d'entrée - lorsque l'étape s'active. Transmet un commutateur d'interruption qui contrôle le comportement de reprise. Par défaut : étapes primaires = false (parallèle) ; étapes secondaires = true (prise en charge).
• Règle d'achèvement - la fin normale (par exemple, lorsque les tâches requises sont terminées). Effectue une action (terminer/quitter le cas, attendre la sélection manuelle, retour à l'origine).
• Règle de sortie - une interruption précoce lorsque la poursuite du traitement est inutile. Transmet les mêmes options d'action que la règle complète.
• Règle de renouvellement - comment la révision renvoie le cas à une étape précédemment terminée.
• SLA de l'étape et escalades - échéance, seuils d'avertissement et destinataires de l'escalade.

Les étapes peuvent être marquées comme requises ou facultatives. Un cas ne peut pas se fermer tant que toutes les étapes requises ne sont pas terminées. Les étapes facultatives s'activent uniquement lorsque leurs règles d'entrée sont respectées et que le cas peut se fermer sans elles.

Plusieurs étapes peuvent être actives dans le même cas en même temps. C'est le fonctionnement des étapes en parallèle ou en séquence qui est déterminé par les règles d'entrée et leur commutateur d'interruption.

Tâches

Une tâche est une unité discrète de travail dans une étape. Chaque tâche a un type qui détermine la façon dont le travail est effectué :

Type de tâche	Ce qu’il fait
Action humaine	Présente un formulaire, une approbation ou un examen à une personne dans l'application du cas.
Agent d'IA (UiPath)	Invoque un agent d'IA UiPath pour le raisonnement autonome sur les données.
Agent externe	Appelle un agent d'IA tiers en dehors d'UiPath (par exemple, via l'API).
Workflow RPA	Déclenche un robot UiPath pour UI Automation dans les systèmes hérités.
Workflow d’API	Appelle un système externe via une demande d'API personnalisée.
Exécuter le connecteur	Appelle un système externe via un connecteur Integration Service pré-construit ou personnalisé.
Processus agentique Maestro	Invoque un Maestro BPMN en tant que tâche, avec sa propre orchestration, et renvoie un résultat au cas parent.
Cas enfant	Génère une définition de cas distincte en tant qu'enfant, liée au parent via caseID.
Attendre le minuteur	Il marque une pause jusqu'à ce qu'une durée s'écoule ou qu'une date cible soit atteinte.
Attendre l’événement du connecteur	Il marque une pause jusqu'à ce qu'un événement externe arrive via un connecteur.

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 :

• Séquentiel - la tâche s'exécute dans un ordre défini dans l'étape. Les séquences peuvent inclure des branches parallèles qui se divisent et se rejoignent.
• Pilotée par des événements - la tâche a une règle d'entrée et se déclenche chaque fois que l'événement fait en sorte que la règle soit évaluée comme vraie. Peut déclencher plusieurs fois si l'événement se répète.
• 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.

Plusieurs tâches peuvent être actives dans la même étape en même temps - branches parallèles séquentielles, tâches pilotées par des événements se déclenchant indépendamment de la séquence et tâches ad hoc lancées parallèlement à l'exécution du travail.

Chaque tâche est configurée avec :

• Entrées / Sorties - mappées vers et à partir de l'entité du cas [Bientôt disponible] .
• Indicateur requis - détermine si l'étape parente doit attendre cette tâche.
• Règle d'entrée - requise pour les tâches pilotées par des événements ; facultatif pour les tâches séquentielles et ad hoc (où il agit comme une garde).
• Exécuter une seule fois - si true, la tâche est ignorée lors du renouvellement de l'étape et sa sortie précédente est conservée ; si false (par défaut), la tâche se réexécute à chaque renouvellement, produisant une nouvelle sortie.
• Affectation et SLA - pour les actions humaines, qui doit effectuer le travail et quand il est dû.

Règles

Les règles sont le mécanisme qui contrôle le mouvement du cycle de vie. Ils suivent le modèle CMMN (Case Management Model and Notation) et sont pilotés par les événements - une règle se déclenche uniquement lorsqu'un événement pertinent se produit sur le cas. Chaque règle a trois parties :

• WHEN - l'événement qui déclenche l'évaluation. Les événements sont de deux types :
  • Les é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 écrites 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) - une 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 :

Portée	Types de règles	Objectif
Cas	Cas terminé, Sortie du cas	Terminer ou mettre fin au cas.
Étape	Entrée, Terminé, Sortie, Renouvellement	Régissez l'activation de l'étape, l'achèvement normal, l'abandon précoce et la révision. Les règles d'entrée de l'étape comportent un commutateur d'interruption ; les règles d'achèvement et de sortie comportent une action (terminer/quitter le cas, attendre la sélection manuelle, retour à l'origine).
Tâche	entrée	Point de contrôle lorsqu'une tâche démarre. 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.

La distinction entre Quitter et Terminer au niveau de l'étape est importante. Une règle Terminer se déclenche lorsque le travail se termine normalement. Une règle de sortie se déclenche lorsqu'une modification de données rend la poursuite du traitement inutile ; elle agit comme un disjoncteur. Les deux ont pour résultat que le gestionnaire de cas applique l'action de la règle et évalue ce qui se passe ensuite.

Couche 4 - le gestionnaire de cas (orchestration du runtime)

Le gestionnaire de cas est l'orchestrateur piloté par les événements de chaque cas. Il pilote les décisions du cycle de vie - quelle étape activer ensuite, quelles tâches démarrer, quand une étape doit se terminer ou quitter prématurément, et quand escalader - en fonction des événements arrivant sur le cas.

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

1. Règles (primaire) - Règles CMMN déterministes définies dans le plan de cas. Pour chaque point de décision, le gestionnaire de cas évalue d'abord les règles applicables. Si 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. Raisonnement de l'agent (solution de secours) - Lorsqu'aucune règle ne couvre la situation (un écart, une exception ou une décision discrétionnaire), l'agent gestionnaire de cas raisonne sur l'entité du cas, le plan de cas et les stratégies configurées pour choisir l'action suivante. Cela permet aux cas de continuer à progresser sans escalade vers un humain pour chaque branche non couverte.

Comment le gestionnaire de cas traite un événement

La séquence suivante se répète tout au long de la vie du cas :

1. Événement reçu - un déclencheur s'exécute, une tâche se termine, un champ d'entité d'incident change, un minuteur ou un événement de connecteur arrive, ou une étape effectue une transition.
2. Évaluation de la règle - le gestionnaire de cas évalue toutes les règles applicables au niveau du cas, de l'étape et de la tâche dont le WHEN correspond à l'événement et dont la condition IF (si présente) est remplie. Les actions des règles correspondantes sont appliquées (activer une étape, terminer une étape, quitter une étape, etc.).
3. Politique de secours de l'agent - pour les décisions non couvertes par une règle déterministe, l'agent gestionnaire de cas raisonne sur l'état du cas et les stratégies pour choisir l'action suivante.
4. Mise à jour de l'état - transition des étapes et des tâches ; l'entité du cas est mise à jour ; de nouveaux événements peuvent être émis, déclenchant le cycle suivant.
5. Achèvement d'un cas - lorsqu'une règle de fin de cas ou de sortie de cas au niveau du cas se déclenche (ou que l'agent décide que le cas est terminé), le cas se ferme.

Les règles et l'agent fonctionnent ensemble

Les règles couvrent le prévisible : « Si l'expert en sinistres approuve et que le montant est inférieur à 50 000 $, entrez Règlement. » L'agent couvre l'imprévisible : un document manquant sans chemin de stratégie clair, un modèle de cas de fraude atypique ou une combinaison inhabituelle de conditions. Le gestionnaire de cas essaie toujours d'abord les règles et ne revient à l'agent que lorsque les règles ne correspondent pas.

Configuration de l'agent gestionnaire de cas

L'agent gestionnaire de cas est configuré avec :

• Un modèle (le LLM alimentant l'agent).
• Une invite de l'utilisateur (stratégies, contraintes et instructions comportementales).
• Outils (actions que l'agent peut effectuer, telles que le déplacement d'une étape, l'escalade ou la mise à jour de l'entité).
• Contexte (automatiquement accumulé à partir de l'historique d'exécution, des résultats de la tâche et des modifications de l'entité).
• Une stratégie d'escalade (conditions dans lesquelles l'agent passe à un humain au lieu d'agir de manière autonome).

Remarque :

Lorsque ni les règles ni l'agent gestionnaire de cas ne peuvent résoudre une décision (en raison de données ambiguës, de stratégies conflictuelles ou d'un scénario extérieur à l'autorité de l'agent), le gestionnaire de cas passe à un humain via le persona configuré.

Couche 5 - l'expérience de runtime

Lors du runtime, deux interfaces exposent les données de cas et les contrôles à différentes audiences.

Application du cas (pour les utilisateurs professionnels)

L'application du cas est le workspace orienté vers les utilisateurs professionnels où les responsables et les gestionnaires de cas interagissent avec les instances de cas en direct. Elle affiche :

• Liste de cas - Une vue filtrable de toutes les instances de cas avec le statut, la priorité et les indicateurs de SLA (sur la bonne voie, à risque, non respecté).
• Vue des détails du cas - L'étape actuelle, les données de l'entité du cas, les statuts des tâches, la chronologie des événements et la piste d'audit complète.
• Boîte de réception des tâches (Mon travail) - Tâches humaines en attente d'une action : formulaires, approbations, examens.
• Actions rapides - Actions contextuelles basées sur le rôle et l'étape actuelle : terminer, rouvrir, réaffecter, transmettre, ajouter des notes.

L'application du cas est disponible en deux options : une application du cas prête à l'emploi (un workspace pré-construit sans code livré avec Maestro Case) et une application du cas codée personnalisée (créée avec le SDK TypeScript pro-code, permettant de créer des vues et des workflows sur mesure). L'application prête à l'emploi est configurable au moment de la conception - dans Studio Web, sélectionnez Configurer l'application du cas dans les paramètres de Maestro Case pour définir le titre du cas et la mise en page des détails du cas.

Une seule définition de plan de cas génère une application du cas qui gère des milliers d'instances de cas individuelles, chacune à un point différent de son cycle de vie.

Gestion des instances de cas (pour les opérateurs)

La gestion des instances de cas est la console d'opérations dans Maestro où les opérateurs de processus surveillent l'état de tous les cas en cours d'exécution et interviennent lorsque des problèmes surviennent.

Action de l'opérateur	Description
Suspendre	Arrêtez temporairement un cas en cours d'exécution. Les minuteurs SLA se mettent en pause. Aucune tâche ne s'active tant qu'elle n'est pas reprise.
Reprendre	Redémarrez un cas en pause. Les minuteurs SLA reprennent là où ils se sont arrêtés.
Annuler (Cancel)	Mettez fin à un cas de manière permanente. Toutes les tâches en cours d'exécution s'arrêtent.
Migrer	Déplacez une instance de cas en cours vers une version plus récente du plan de cas après un correctif ou une mise à jour, en préservant l'état et les données actuels.
Réessayer	Réexécutez une tâche ou une transition échouée pour récupérer des erreurs transitoires.

Lorsqu'un cas entre dans un état d'erreur - une tâche échoue, une intégration expire ou le cas se bloque - il devient un incident de cas.Les opérateurs utilisent la console de gestion des instances pour diagnostiquer et résoudre les incidents avec les actions ci-dessus.

Remarque :

• L'application du cas est destinée aux utilisateurs professionnels (responsables de cas, gestionnaires) qui travaillent sur des cas individuels.
• La gestion des instances de cas est pour les opérateurs de processus qui surveillent la santé du système et interviennent lorsque les choses tournent mal.

Traçage des données de bout en bout : un guide pratique

Pour concrétiser le cycle de vie, envisagez un cas de réclamation d'assurance habitation :

1. Le déclencheur d'événement s'exécute. Une nouvelle ligne est créée dans une entité Home Claims Data Fabric. Le déclencheur mappe les champs de l'entité (numéro de politique, nom du demandeur, description de la perte) dans l'entité du cas [Bientôt disponible] et crée une instance de cas avec la clé HO-1234.

2. Le gestionnaire de cas active la première étape. La règle d'entrée pour l'admission est évaluée comme vraie (WHENCaseCreated l'événement arrive). L'étape devient active.

3. Les tâches s'exécutent dans l'admission. Une tâche d'extraction (agent d'IA) traite les détails de la réclamation. Une tâche de recherche (Exécuter le connecteur) vérifie la stratégie. Un agent de détection d'anomalies vérifie l'historique des réclamations. Chaque tâche écrit les résultats dans l'entité du cas.

4. L'admission se termine, l'examen s'active. Lorsque toutes les tâches d'admission requises se terminent et validationPassed == true, la règle d'achèvement de l'admission se déclenche. Le gestionnaire de cas évalue les règles d'entrée pour les étapes suivantes et active l'examen.

5. Les tâches de révision s'exécutent. Un connecteur de vérification de la couverture, une tâche de vérification par le responsable des sinistres humain et un agent auditeur produisent des sorties. Le responsable des sinistres réécrit decision = "Approve" dans l'entité.

6. Routage conditionnel lors de l'examen. Les règles d'achèvement et de sortie évaluent le champ decision. Si "Approve", la règle d'achèvement se déclenche et le cas se déplace vers le règlement. Si "Reject", la règle de sortie se déclenche et achemine le cas vers l'étape secondaire Refusé. Si "Claim is missing key incident reports", la règle de renouvellement renvoie le cas à l'admission, en réexécutant uniquement les tâches dont runOnlyOnce est false (par exemple, Robot de rapports d'incident et Agent d'anomalie).

7. Les tâches de règlement s'exécutent. Un processus d'exécution, un processus de règlement et un agent de communication gèrent le paiement et les notifications. Chacun réécrit dans l'entité.

8. Le cas se ferme. Lorsque toutes les étapes requises sont terminées, le cas atteint un état terminal. La piste d'audit complète - chaque exécution de tâche, modification d'entité, décision et horodatage - est conservée.

9. Tout au long du cycle de vie, un responsable de cas affiche les tâches affectées dans la boîte de réception Mon travail de l'application du cas. Un gestionnaire de cas surveille le portefeuille, réaffecte les tâches et gère les escalades. Un opérateur surveille les incidents dans la console de gestion des instances de cas.

SLA et escalades tout au long du cycle de vie

Les SLA ajoutent une dimension de temps au cycle de vie :

Niveau SLA	Portée	Exemple
SLA au niveau du cas	Cible globale de la création à la fermeture.	Résolvez dans les 48 heures.
SLA au niveau de l'étape	Heure d'échéance localisée pour une étape spécifique.	Effectuer l'examen dans les 24 heures.

Les états de la SLA - en cours, à risque et non respectés - apparaissent sous forme de badges dans la liste et les vues dtailles de l'application du cas. Les règles d'escalade se déclenchent automatiquement :

• À risque - SLA s'approche de sa limite. Avertir le propriétaire de l'incident et le superviseur.
• Non respecté - Le SLA est dépassé. Réaffectez à un travailleur senior ou transmettez à la direction.
• Pause / Resume - Les minuteurs du SLA ne sont pas suspendus automatiquement. Un cas en attente d'une entrée externe continue à augmenter le temps du SLA jusqu'à ce qu'un opérateur suspende explicitement l’instance du cas.

Rôles d'utilisateur dans le cycle de vie

Maestro Case applique un accès adapté à l'étape afin que les bonnes personnes voient et agissent au bon moment.

Rôle	Responsabilité
Gestionnaire de cas	Termine les tâches humaines et met à jour les champs autorisés dans les étapes auxquelles il a accès.Voit le travail affecté dans Mon travail.
Gestionnaire d’incidents	Supervise un portefeuille. Peut réaffecter, transmettre et (selon la stratégie) rouvrir. Peut effectuer des actions au niveau de l'étape telles que la mise en pause et la reprise.

Pour chaque étape, le plan de cas définit les personas qui peuvent consulter et ceux qui peuvent agir (terminer les tâches, réaffecter, transmettre, mettre en pause). Les tâches héritent des paramètres de l'étape, mais peuvent restreindre davantage les personnes affectées.

Remarque :

Les rôles d'utilisateur du cas complets et les contrôles d'accès au niveau de l'étape ne sont pas encore disponibles.

Principes architecturaux clés

Principe	Explication
Priorité à l'agent	Les agents d'IA sont des participants de première classe, à la fois en tant qu'exécutants des tâches dans les étapes et en tant qu'agent gestionnaire de cas qui orchestre l'ensemble du cas. Les humains n'interviennent que lorsque la stratégie ou le jugement l'exige.
Non linéaire par conception	Les règles de renouvellement, les étapes secondaires, les tâches pilotées par des événements et les tâches ad hoc permettent aux cas de suivre le chemin dicté par les données, et non une séquence rigide.
Centré sur l'entité	L'entité du cas [Bientôt disponible] est la source unique de vérité. Les tâches sont des producteurs et des consommateurs découplés des données de l'entité.
Les règles d'abord, l'agent ensuite	Les règles CMMN déterministes gèrent les chemins nominaux à haut volume. L'agent gestionnaire de cas gère les exceptions et l'ambiguïté - et transmet à des humains lorsque ni les règles ni l'agent ne peuvent décider.
Séparation entre le temps de conception et le runtime	Le plan de cas est ce que vous concevez dans Studio Web. L'application du cas et la console de gestion des instances sont ce que les utilisateurs professionnels et les opérateurs utilisent tous les jours. Un seul plan de cas sert des milliers d'instances de cas.

Ressources connexes

• Concepts de base dans Maestro Case - Définitions de référence pour les clés de cas, les entités, les étapes, les tâches, les règles et les SLA.
• Vue d'ensemble du Concepteur de plan de cas - Comment modéliser des plans de cas dans Studio Web.
• Configuration des règles de l'étape - Conseils détaillés sur les règles d'entrée, d'achèvement, de sortie et de renouvellement.
• Vue d'ensemble de l'application du cas - Ce que les utilisateurs professionnels voient et comment configurer la mise en page de l'application du cas.
• Gestion des instances de cas - Actions de l'opérateur pour la surveillance, la résolution de l'incident et la migration en direct.