Dictionnaire des composants de gestion de cas Maestro

	Gestion des cas	Processus BPMN
Le contenu s’applique à	✅	❌

Vue d'ensemble (Overview)

Ce document de référence fournit une ventilation factuelle de chaque composant de la gestion des cas Maestro. Utilisez-le comme dictionnaire pour comprendre ce que chaque construction, les propriétés qu'elle expose et sa relation avec d'autres constructions. Pour obtenir des conseils étape par étape sur la création d'un incident, consultez le Tutoriel sur la gestion des incidents.

Public : intermédiaire à avancé — Automation Developers, architectes de solutions, responsables techniques.

Statut du produit: Aperçu.

Liens entre les constructions

La hiérarchie suivante montre comment les constructions de la gestion des cas Maestro s'intègrent au moment de la conception et du runtime.

Case (runtime instance, identified by Case Key)

DESIGN-TIME (Studio Web)
├── Case Manager (rules-based orchestration)
├── Case Personas (human roles, scoped to stages)
└── Case Plan (visual blueprint)
    ├── Event Triggers
    └── Stages + Stage Transitions (entry / complete / exit / re-entry)
        └── Tasks (Human, Agent, External Agent, RPA, Connector,
                    Agentic Process, Child Case, Wait Timer,
                    Wait Event, Ad-hoc)

CROSS-CUTTING
└── SLAs & Escalations (case-level and stage-level)

RUNTIME
├── Case App (business users — view, track, act)
└── Case Instance Management (operators — pause, resume, cancel, migrate, retry)

---

Clé de cas

La clé de cas identifie de manière unique une instance de cas dans Maestro et les systèmes externes.

TypeClé	Description	Exemple
Clé système	Généré automatiquement par Maestro lors de la création de l'incident. Utilise un préfixe constant configurable.	HC-1234, CLM-00891
Clé externe (définie par le client)	Un ID en amont transmis lors de la création de l'incident afin que le même incident dans le monde réel soit reconnu dans tous les outils.	Numéro d'incident CRM, numéro de police, ID de commande ERP

Configurez la clé de cas lorsque vous créez le type de cas dans Studio Web. Sélectionnez la clé de préfixe constante et fournissez une chaîne de préfixe (par exemple, HO-). Maestro ajoute un identifiant incrémenté automatiquement.

Utilisez une clé externe lorsque l'incident provient d'un autre système (CRM, ERP, outil de ticket) et que les humains ou les intégrations doivent corréler l'incident entre les outils sans maintenir une table de mappage distincte.

---

Étapes

Une étape est une phase nommée dans le cycle de vie du cas (par exemple, Entrée, Révision, Règlement). Les étapes sont les colonnes sur le canevas du plan de cas, chacune regroupant des tâches liées qui s'exécutent pendant cette phase.

Types d’étape

Maestro prend en charge deux catégories d'étapes:

Saisie de texte	Description	Exemple
Étape principale	Représente la progression par le chemin heureux d’un incident.	Prise en charge, examen, règlement, clôture
Étape secondaire	Représente des chemins d’exception se ramifiant du flux principal. Peut revenir à l'origine ou être terminal.	En attente avec le client, Refusé, Retrait

Propriétés de l’étape

Propriété	Description
name	Nom complet (par exemple, « Soumis », « Examen du responsable »).
required	Indique si l'incident doit passer par cette étape pour se terminer. Si true et la règle d'entrée ne sont jamais évalués comme vrai, le cas est bloqué. Si false, le cas peut se terminer même si cette étape n’a jamais été saisie.
entryRule	Condition qui doit être « true » pour que cette étape soit activée.
completeRule	Condition qui détermine le moment où cette étape est terminée. Souvent « lorsque toutes les tâches requises sont terminées.»
exitRule	Condition de sortie précoce. Lorsqu'elle est respectée, l'étape se termine immédiatement même si la règle complète n'est pas respectée.
reentryCondition	Condition qui permet à un cas de revenir à cette étape pour la révision.
autoComplete	Marquez automatiquement l’étape comme terminée lorsque toutes les tâches requises sont terminées.
runOnReentry	Contrôle si l’étape se réinitialise et se réexécute lorsqu’elle est renouvelée à la fin du précédent achèvement. Par défaut: false.
sla	Limite de temps pour l'achèvement de l'étape (jours ouvrables ou jours calendaires).

Étapes requises et facultatives

	Étape requise	Étape facultative
Fin de cas	Le cas ne peut pas être défini tant que cette étape n’est pas terminée.	Le cas peut se terminer même si cette étape n’a jamais été saisie.
Quand l'utiliser	Phases de base que chaque cas doit passer par (par exemple, « Soumis », « Paiement »).	Phases conditionnelles qui ne s'appliquent que parfois (par exemple, « Examen VP» pour les cas à valeur élevée).
Comportement si la règle d’entrée n’est jamais vraie	Blocs de cas.	Le cas ignore l'étape.

Comportement de sortie de l’étape secondaire

Comportement	Description	Exemple
Retour à l’origine	Lorsque toutes les tâches de l’étape secondaire sont terminées, le cas redirige vers l’étape qui l’a envoyé.	Une étape En attente avec le client revient à la révision après la réception des documents.
Terminal	Lorsque toutes les tâches de l’étape secondaire sont terminées, le cas se termine.	Une étape Refusé ferme le cas après l’envoi d’un paquet de refus.
Entrée générée par le connecteur	L’étape secondaire s’active lorsqu’un événement de connecteur externe arrive, quelle que soit l’étape principale du cas.	Une étape Retiré entre automatiquement lorsqu'un message de canal Microsoft Teams est publié.

Exécuter lors du comportement de renouvellement (étapes)

runOnReentry	Comportement	Use case
true	L’étape est réinitialisée à l’ état Actif. Toutes les tâches sont réévaluées - les tâches requises avec runOnReentry: true réexécution.	Boucle de correction: l'étape « Soumis » doit être revalidée après le rejet.
false (par défaut)	L'étape reste Terminée. L’entrée renouvelée est un nombre interdit. Les résultats précédents sont conservés.	Étapes uniques qui ne doivent s’exécuter qu’une seule fois (par exemple, « Période initiale»).

---

Types de tâches

Une tâche est une unité de travail distincte au sein d’une étape. Les tâches sont les blocs de construction atomiques du traitement des cas.

Types de tâches pris en charge

Type de tâche	Description	Exemple d’utilisation
Human (Action)	Attribuée à une personne via un personnage. Ouvre un formulaire ou un élément de travail dans la file d'attente de l'application de cas. L'humain examine, prend une décision et soumet.	Approbation du gestionnaire, examen par l'expert, approbation financière.
Agent (UiPath)	Un agent UiPath AI raisonne de manière autonome sur les données. Utile pour le travail basé sur le jugement.	Catégoriser les dépenses, signaler les anomalies, rédiger une réponse au client.
Agent externe	Appelle un agent d’IA tiers externe à UiPath (par exemple, via un protocole ou une API A2A). Permet l’orchestration d’agents multi-fournisseurs.	Appelez un agent de conformité externe depuis un système partenaire.
Workflow RPA	Déclenche un robot UiPath pour effectuer UI Automation dans les systèmes hérités sans API.	Traiter le remboursement dans un système de paie hérité, saisir les données dans un cadre principal.
Connecteur (Integration Services)	Appelle un système externe via un connecteur pré-construit ou personnalisé. S'exécute de manière synchrone ou asynchrone avec rappel.	Rechercher les détails de la politique dans Salesforce et effectuer une vérification du crédit.
Workflow d’API	Appelle un système externe via une requête d'API personnalisée. S'exécute de manière synchrone ou asynchrone avec rappel.	Appeler le logiciel de planification pour obtenir des emplacements disponibles, créer un nouveau ticket.
Processus Maestro agentique	Invoque un processus agentique Maestro (basé sur BPMN) en tant que tâche. Le processus s'exécute avec sa propre orchestration et renvoie un résultat.	Workflow d'audit en plusieurs étapes avec sa propre logique d'agent.
Gestion des cas (cas enfant)	Génère une autre définition de cas en tant que cas enfant. L'enfant a son propre cycle de vie, ses étapes et ses tâches, liés au parent via caseID.	Un incident de réclamation génère un incident d’enquête sur la fraude enfant.
Wait for Timer	Suspend l'exécution jusqu'à ce qu'une durée spécifiée se termine ou qu'une date/heure cible soit atteinte.	Attendez 48 heures avant d'envoyer un avis de suivi.
Attendre l’événement du connecteur	Suspend l’exécution jusqu’à ce qu’un événement externe arrive via un connecteur (webhook, file d’attente de messages, rappel système).	Attendez une confirmation de paiement du système bancaire.

Tâches ad hoc

Les tâches ad hoc sont créées au moment de l’exécution par un utilisateur humain lorsqu’une tâche non planifiée est nécessaire et ne fait pas partie du plan de cas d’origine. Par exemple: Le processeur d'incident humain ajoute une tâche « Demander une documentation supplémentaire» pendant l'enquête.

Propriétés de la tâche

Propriété	Description
name	Nom complet.
type	L’un des suivants: human, agent, externalAgent, rpa, connector, agenticProcess, childCase, waitTimer, waitEvent, adhoc
required	Indique si l’étape parente doit attendre la fin de cette tâche. Si true, l'étape ne peut pas se terminer tant que la tâche n'est pas terminée. Si false, l'étape peut se terminer même si cette tâche n'est pas terminée.
entryRule	Condition qui détermine le moment où cette tâche commence. Active l’exécution conditionnelle (par exemple, s’exécuter uniquement lorsque amount >= 1000).
completeRule	Condition qui détermine le moment où cette tâche est considérée comme terminée.
exitRule	Condition de sortie précoce de la tâche. Lorsque ce champ est rempli, la tâche se termine immédiatement.
runOnReentry	Indique si cette tâche est réinitialisée et réexécutée si l’étape parente est accessible à nouveau. Par défaut: false.
linkedWorkflow	Référence à la configuration du workflow, du formulaire ou de l'agent d'implémentation.
assignment	Pour les tâches humaines: le persona, l'utilisateur, l'équipe ou la règle de routage qui détermine le bénéficiaire.
sla	Pour les tâches humaines: heure d'échéance, seuils d'avertissement et destinataires de l'escalade.

Tâches obligatoires et facultatives

	Tâche requise	Tâche facultative
Étape terminée	L’étape parent ne peut pas se terminer tant que cette tâche n’est pas terminée.	L’étape parente peut se terminer même si cette tâche n’est pas effectuée.
Quand l'utiliser	Doit effectuer des tâches (par exemple, « Approbation du gestionnaire» à l'étape de révision).	Travail convivial (par exemple, « Signalez les anomalies» — utile, mais l’étape peut se poursuivre sans cela).
Interaction de remplissage automatique	Si l’étape comporte autoComplete: true, l’achèvement attend toutes les tâches requises.	Il n’est pas pris en compte dans la vérification de la saisie semi-automatique.

Exécuter lors du comportement de renouvellement (tâches)

runOnReentry	Comportement	Use case
true	La tâche se réinitialise et se réexécute, générant de nouvelles sorties.	Des tâches de validation qui doivent revérifier les données corrigées.
false (par défaut)	La tâche conserve son résultat précédent; ne se réexécute pas.	Les tâches dont la sortie est toujours valide (par exemple, « Catégoriser les dépenses» n’a pas besoin d’être réexécuté).

---

Conditions

Les conditions (également appelées conditions de transition ou règles) contrôlent le mouvement du cycle de vie au niveau de l'étape et de la tâche. Maestro prend en charge quatre types de conditions.

Condition d’entrée

Évalue par rapport aux champs du cas. Lorsque la condition devient vraie, l'étape ou la tâche passe de Disponible à Active.

Portée	Description	Exemple
Étape	Indique le début d'une étape.	vars.validationPassed == true active l'étape Révision.
Tâche	Permet l’exécution conditionnelle d’une tâche dans une étape active.	Exécuter uniquement lorsque amount >= 1000.

Condition de remplissage

Définit le moment où une étape ou une tâche est terminée dans des circonstances normales. Pour les étapes, c’est souvent « lorsque toutes les tâches requises sont terminées». Pour les tâches, il s'agit généralement de « lorsque la tâche produit une sortie».

Portée	Description	Exemple
Étape	Marque une étape comme terminée lorsque le travail est terminé.	Toutes les tâches requises sont terminées.
Tâche	Marque une tâche comme terminée lorsque sa sortie est reçue.	taskOutput.status != "error".

Condition de sortie (sortie précoce)

Un mécanisme de sortie précoce. Lorsque la condition est remplie, l'étape ou la tâche se termine immédiatement , même si la règle globale n'est pas remplie. Les conditions de sortie agissent comme des déclencheurs pour les scénarios anormal ou conditionnel.

Portée	Description	Exemple
Étape	Termine une étape avant la fin de toutes les tâches.	vars.action == "Reject" termine l'étape Révision et le cas passe à l'étape secondaire Refusé.
Tâche	Arrête une tâche avant son achèvement normal.	policyValid == false arrête une validation supplémentaire.

Remarque :

Ne confondez pas les conditions de sortie avec des conditions complètes. Une condition d'achèvement se déclenche lorsque le travail est terminé (fin d'installation normale). Une condition de sortie se déclenche lorsque quelque chose change qui signifie que le travail doit s'arrêter (abandon des débuts). Dans ces deux cas, le gestionnaire de cas évalue l'étape suivante.

Condition de renouvellement

Permet à un cas de revenir à une étape précédemment terminée de manière structurée et auditable. Cette fonctionnalité permet des flux de cas non linéaires pour les boucles de révision contrôlées.

Portée	Description	Exemple
Étape	Renvoie le cas à une étape antérieure lorsqu'un travail supplémentaire est nécessaire.	vars.decision == "Claim is missing key incident reports" renvoie le cas de Révision à Entrée.

Lorsque le renouvellement se produit, configurez les tâches spécifiques à réexécuter dans l’étape cible. Les tâches avec runOnReentry: true réexécuter; les tâches avec runOnReentry: false conservent leurs résultats précédents.

Règle Ignorer

Condition facultative sur une étape qui contourne entièrement l'étape lorsque la condition est vraie.

Portée	Description	Exemple
Étape	Ignore une étape lorsqu'elle n'est pas applicable.	riskScore < 30 ignore l’étape de l’enquête détaillée.

---

SLA et escalades

Définissez des SLA (accords de niveau de service) et des règles d'escalade au niveau des incidents et des étapes afin d'appliquer des attentes basées sur le temps.

Niveaux du SLA

Niveau (Level)	Description	Exemple
SLA au niveau du cas	Cible globale de la résolution du cas, de la création à la fermeture.	Résoudre le problème dans les 48 heures ouvrables.
SLA au niveau de l’étape	Heure d'échéance localisée pour une étape spécifique.	Prise en charge du NPOM en 4 heures; Examen par le responsable dans les 24 heures.

États du SLA

État (State)	Description
En cours	Le cas ou l’étape se situe dans le délai imparti.
En difficulté	Le SLA approche de sa limite (par exemple, à 80 % du temps alloué).
Violation	La limite de temps du SLA a été dépassée.

Les états SLA apparaissent sous forme de badges dans les listes de cas et les vues détaillées dans l’application des cas.

Règles d’escalade

Déclencheur	Description	Action typique
Escalade à risque	Déclenché lorsque le SLA approche de sa limite.	Avertissez le propriétaire du cas et le superviseur.
Violer l’escalade	Déclenché lorsque le SLA est dépassé.	Réaffecter à un travailleur principal, informer la gestion, créer un indicateur de priorité.

Mettre en pause et reprendre

Les minuteurs du SLA peuvent être suspendus lorsque le cas attend une entrée externe (par exemple, une réponse du client) et reprendre lorsque le cas redevient exploitable.

---

Gestionnaire d’incidents

Le gestionnaire de cas orchestre le cycle de vie du cas à l'aide de règles déterministes. Les règles gèrent les modèles connus et prévisibles.

Fonctionnement du gestionnaire de cas

1. Événement reçu — un déclencheur s'exécute et crée (ou met à jour) une instance de cas.
2. Évaluation des règles — le gestionnaire de cas évalue les conditions d'entrée pour toutes les étapes pour déterminer les étapes qui doivent devenir actives.
3. Activation des tâches — dans les étapes actives, les conditions d'entrée des tâches sont évaluées pour démarrer le travail approprié.
4. Surveillance — alors que les tâches sont terminées, le gestionnaire de cas évalue les conditions complètes (fin d'installation normale) et les conditions de sortie (abandon précoce).
5. Achèvement du cas — lorsque toutes les étapes requises sont terminées, le cas se ferme.

Étendue des règles

Les règles (entrée, complétion, sortie) peuvent être définies à trois niveaux:

• Au niveau du cas : régissez le cycle de vie global du cas (quand le cas est-il terminé?).
• Niveau de l'étape — contrôlez les transitions d'étape (quand cette étape s'active-t-elle, se termine-t-elle ou s'arrête-t-elle?).
• Au niveau de la tâche : contrôlez l'activation et l'achèvement des tâches individuelles.

Configuration du gestionnaire de cas

Paramètre	Description
model	Le LLM qui alimente l'agent (par exemple, claude-3.5-sonnet, gpt-4o).
userPrompt	Instructions système qui définissent le rôle, les politiques et les contraintes de l’agent.
tools	Actions que l'agent peut effectuer (par exemple, déplacer l'étape, escalader, envoyer une notification).
context	Mémoire de l'agent, créée automatiquement en fonction de l'historique d'exécution. L'agent accumule le contexte des décisions antérieures, des résultats des tâches et des modifications de l'état des incidents.

Remarque :

Si le gestionnaire de cas ne peut pas prendre de décision, en raison de données ambiguës, de règles en conflit ou d'un scénario hors de ses politiques, il est automatiquement transmis à un humain.

---

Types d'incidents

Les personas du cas définissent les rôles de participant humain qui interagissent avec un cas tout au long de son cycle de vie. Les personas contrôlent qui peuvent afficher et agir à chaque étape. Les personas représentent des personnes, et non des agents. Les agents d'IA sont configurés séparément en tant que types de tâches.

Types de persona intégrés

Utilisateur	Rôle	Fonctionnalités typiques
Créateur de cas	Lance l'incident: soumet le déclencheur d'origine (formulaire portail, appel d'API, e-mail).	Créez de nouvelles instances de cas; afficher le statut des incidents créés; capacité limitée de mettre à jour les incidents ouverts avant la fin de la première étape.
Propriétaire du cas	Responsable de l'incident de bout en bout. Souvent attribué lors de la création.	Visibilité complète du cas à toutes les étapes; peut réaffecter des tâches, remplacer des décisions (dans le cadre de la politique) et rouvrir les incidents clôturés.
Travailleur de cas	Exécute les tâches humaines assignées dans des étapes spécifiques.	Afficher et effectuer les tâches dans leur file d'attente; mettre à jour les champs de cas relatifs à la sortie de leur tâche; visibilité au niveau de l’étape uniquement.
Supervision/Gestionnaire	Supervise le portefeuille d’incidents d’une équipe; gère les escalades.	Afficher tous les cas attribués à leur équipe; réaffecter des tâches; approuver les escalades; suspendre/reprendre les minuteurs du SLA; accéder aux tableaux de bord et aux ICP.
Expert métier (SME)	Consulté sur des cas ou des étapes spécifiques nécessitant des connaissances de spécialistes.	Lire l’accès aux données pertinentes du cas; peut effectuer des tâches conçues par l’SME; ne dispose pas d’autorisations étendues de gestion des cas.

Au-delà des types intégrés, les développeurs de cas peuvent créer des personas personnalisés - donnez au persona un nom et l'affectez à une ou plusieurs étapes spécifiques. Les personas personnalisés n'apparaissent pas automatiquement partout.

Autorisations personnelles au niveau de l'étape

Pour chaque étape du plan de cas, définissez deux dimensions d'accès pour chaque profil:

• Afficher l’accès — quels personas peuvent voir les données, les tâches et l’historique de cette étape dans l’application des cas.
• Accès aux actions — quels personas peuvent prendre des actions à cette étape (effectuer des tâches, ajouter des notes, réaffecter, escalader, déclencher des transitions).

Les tâches héritent des paramètres de persona de l’étape par défaut, mais peuvent affiner davantage les rôles autorisés.

Stratégies d’attribution

Strategy	Mode de fonctionnement	Quand l'utiliser
Statique	Un utilisateur, une équipe ou un groupe fixe est affecté au moment de la conception.	Tâches qui sont toujours envoyées à la même équipe (par exemple, Finance Review est toujours envoyée au groupe Finance).
Dynamique	Une règle ou une expression résout le bénéficiaire au moment du runtime.	Affectation équilibrée par la charge de travail, routage régional/région, routage basé sur les compétences.

Remarque :

La prise en charge des rôles d'utilisateur et des accès n'est pas encore disponible.

---

Application du cas

L' application d'incident est l'application d'exécution destinée aux utilisateurs métier où les travailleurs, les responsables et d'autres personnes voient, suivent et agissent sur les instances d'incidents en direct.

Ce que les utilisateurs professionnels voient

Consultation (View)	Description
Liste/files d’attente des cas	Vue filtrable de toutes les instances de cas, avec des indicateurs de statut, de priorité et de SLA (en cours, à risque, violé).
Vue détaillée du cas	Étape actuelle, statuts des tâches, chronologie des événements et piste d’audit complète.
Boîte de réception des tâches (Mon travail)	Tâches humaines en attente d'action: formulaires, approbations, avis.
Actions	Actions contextuelles basées sur le rôle et l'étape actuelle: effectuer, rouvrir, escalader, réaffecter, ajouter des notes, demander des informations, créer des tâches ad hoc.
Tableaux de bord	ICP agrégés: débit, délai de résolution, conformité au SLA, identification des goulots d'étranglement.

Configuration

Configurez l'application de cas à partir de l'option Configurer l'application de cas dans les paramètres de gestion des cas de Studio Web. Les éléments configurables incluent:

• Titre du cas - le titre affiché dans la liste des cas et les vues détaillées.
• Détails du cas - les champs et la mise en page affichés sur la vue des détails du cas.

Application de cas vs applications UiPath

Aspect	Case App	UiPath Apps
Objectif	Espace de travail spécialisé et centré sur les incidents — répertorie, des détails, des tâches, des incidents et des vues SLA pour les opérations d'incident.	Générateur low-code à usage général pour des applications métier entièrement personnalisées ou composites.
Quand l'utiliser	Opérations rapides sur les incidents avec des vues prêtes à l'emploi.	Personnalisez les exigences de l'interface utilisateur au-delà des opérations de cas.

Les formulaires de tâches humaines continuent d'être créés avec les applications Action et sont référencés par les tâches de cas.

---

Gestion des instances de cas

La gestion des instances de cas est la console d’exploitation où les opérateurs de processus surveillent et gèrent toutes les instances de cas en cours d’exécution.

Actions de l’opérateur

Action	Description
Suspendre	Interrompre temporairement une instance de cas en cours d'exécution. Les minuteurs du SLA s'interrompent. Aucune tâche n'est activée jusqu'à ce qu'elle soit reprise.
Reprendre	Redémarrez un cas suspendu. Les minuteurs du SLA reprennent l'endroit où ils se sont arrêtés.
Annuler (Cancel)	Mettez fin aux instances de cas de façon permanente. Toutes les tâches en cours d’exécution sont arrêtées.
Migrer	Déplacez une instance de cas en direct vers une version plus récente du plan de cas (par exemple, après une correction de bogue ou une mise à jour du plan), en préservant son état et ses données actuels.
Réessayer	Réexécutez la tâche ou la transition ayant échoué pour récupérer des erreurs transitoires.
Update Variables	Modifiez les valeurs des variables de cas sur une instance en cours d'exécution pour débloquer le traitement.

Incidents du cas

Lorsqu’une instance de cas entre dans un état d’erreur (par exemple, une tâche échoue, une intégration expire ou le cas est bloqué), cela devient un incident de cas. Les opérateurs de processus utilisent Migrer, Réessayer et Mettre à jour les variables pour résoudre les incidents.

---

Déclencheurs d'évènement

Les déclencheurs d'événement sont les points d'entrée d'un cas. Elles définissent le point de départ d’un cas et l’origine des données. Un plan de cas unique peut avoir plusieurs déclencheurs.

Type de déclencheur	Source	Exemple
Formulaire/Portail	L'utilisateur soumet via un formulaire Web.	L'employé soumet une note de frais par le biais d'un portail.
E-mail (Email)	E-mail entrant analysé pour les données.	L'e-mail de reçu transféré crée un nouveau cas.
API	Le système externe appelle le point de terminaison de la création de cas.	Le système ERP déclenche un incident de réclamation sur un événement de politique.
File d’attente/Événement	Message d'un flux de file d'attente ou d'événement.	Le sujet Kufk publie un nouvel événement de commande.
Planifié	Déclencheur basé sur le temps.	Le contrôle quotidien crée des cas de suivi pour les éléments obsolètes.
Événement d'entité Data Fabric	Un événement au niveau de la ligne sur une entité Data Fabric ou un VDO (par exemple, « Ligne créée»).	Une nouvelle ligne dans l'entité Revendications d'accueil déclenche un incident.
Attendre le connecteur	Un événement de connecteur d'Integration Service (par exemple, message de canal Microsoft Teams publié).	Un message Teams déclenche une entrée d’étape Retiré.

Chaque déclencheur mappe les données entrantes aux champs du cas.

---

Facturation et consommables

• Pas de facturation distincte pour la gestion des cas Maestro
• Le travail qui s’exécute dans un cas utilise les consommables natifs des types de tâches utilisés:
  • AI agents
  • Processus Maestro agentiques (Processus BPMN)
  • Workflows RPA
  • Workflows / intégrations d'API

---

Glossaire

Condition	Définition
Tâche ad hoc	Une tâche créée au moment de l’exécution (ne faisant pas partie du plan de cas d’origine) par un utilisateur humain lorsqu’une action non planifiée est nécessaire.
Cas	Une instance de runtime représentant une situation commerciale réelle qui doit être résolue (réclamation, litige, enquête, exception). Identifié par une clé de cas.
Case App	L'application orientée utilisateur métier où les utilisateurs voient, suivent et agissent sur les instances de cas en direct.
Commentaires sur les cas	Objets prêts à l'emploi stockant des notes, des annotations et des fils de communication, liés via l'immuable caseID.
Documents du cas	Stockage d'objets prêt à l'emploi fichiers et pièces jointes liés à l'incident, liés via l'immuable caseID.
Incident du cas	Un état d'erreur sur une instance de cas (échec de tâche, délai d'intégration, cas bloqué) qui nécessite une intervention de l'opérateur.
Gestion des instances de cas	Console d'opérations dans Maestro où les opérateurs de processus voient toutes les instances de cas en cours d'exécution et effectuent des actions: suspendre, reprendre, annuler, migrer, réessayer.
Clé du cas	Identificateur unique pour une instance de cas. Il peut s’agir d’une valeur générée par le système ou d’une valeur externe/définie par le client.
Case Manager	Moteur d'orchestration qui utilise des règles déterministes.
Profil du cas	Un rôle de participant humain défini sur des étapes spécifiques. Types intégrés: Créateur de cas, Propriétaire du cas, Collaborateur de cas, Superviseur/Gestionnaire, SME. Les développeurs peuvent créer des personas personnalisés.
Case Plan	Schéma visuel définissant les étapes, les tâches, les déclencheurs et les règles. Décrit les chemins possibles, et non une séquence fixe. Conçu dans Studio Web.
Condition de réalisation	Condition qui détermine lorsqu’une étape ou une tâche est terminée dans des circonstances normales.
Condition d’entrée	Condition qui doit être « true » pour qu’une étape ou une tâche soit activée.
Déclencheur d'évènement	Point d’entrée qui crée ou influence une instance de cas. Associe les données entrantes aux champs du cas.
Exit Condition	Condition de sortie précoce. Lorsqu'elle est respectée, l'étape ou la tâche se termine immédiatement même si la règle n'a pas été respectée.
Étape principale	Une étape de la progression heureux d’un cas.
Re-entry Condition	Condition qui permet à un cas de revenir à une étape précédemment terminée pour la révision.
Requis	Indicateur des étapes et des tâches. Les étapes requises doivent être réalisées pour que le cas se ferme. Les tâches requises doivent être terminées pour que l’étape se termine.
Run on Re-entry	Indicateur qui contrôle si une étape ou une tâche se réinitialise et s’exécute à nouveau lors d’un renouvellement.
Secondary Stage	Une étape représentant un chemin d'exception se ramifiant du flux principal. Peut revenir à l'origine ou être terminal.
RègleIgnorer	Condition facultative sur une étape qui contourne entièrement l'étape lorsque la condition est vraie.
SLA	Accord de niveau de service. Attente basée sur le temps pour l'achèvement du cas ou de l'étape, avec des états: en cours, à risque, violé.
Étape	Une phase nommée dans le cycle de vie du cas qui regroupe les tâches liées. Gouverné par les conditions d'entrée, de complétion, de sortie et de renouvellement.
Tâche	Une unité de travail distincte au sein d’une étape. Dix types: humain, agent, agent externe, RPA, connecteur, processus agentique, cas enfant, attendre le minuteur, attendre l'événement, ad-hoc.

---

Ressources connexes

• Tutoriel de gestion des cas - Présentation de bout en bout de la création d’un cas à partir de zéro.
• Concepteur de plan de cas dans Studio Web — référence pour la zone de dessin de conception visuelle.
• Documentation des applications d'action — comment créer des formulaires pour les tâches humaines référencées par des tâches de cas.