Einführung in Maestro Case

Maestro Case-Konzepte für langlaufende, ausnahmeintensive Arbeit, einschließlich Anwendungsfälle für die Fallverwaltung, Tooloberflächen und Kernkomponenten.

	Maestro-Fall	Maestro-BPMN
Der Inhalt gilt für	✅	❌

Überblick

Maestro Case orchestriert langlebige, zielgesteuerte Arbeit zu einer bestimmten Situation – einem Fall. Ein Fall enthält Daten, Regeln, Aufgaben und Verlauf, um ein prüfbares Ergebnis wie z. B. eine Rückerstattung, eine Anspruchsentscheidung oder einen Abschluss der Untersuchung zu erzielen. Während Maestro BPMN bei strukturierter, sequenzieller Orchestrierung überzeugt, richtet sich Maestro Case an Szenarien, die ausnahmereich und nichtlinear sind und an wichtigen Entscheidungspunkten vom Urteil menschlicher Akteure und KI-Agenten abhängen.

Dieses Dokument stellt Maestro Case vor als eigenständige Funktion in Maestro, führt die Geschäftsanwendungsfälle vor, die es löst und wann Sie es gegenüber Maestro BPMN wählen sollten, führt Sie durch das Toolset, mit dem Sie arbeiten werden, und erläutert die grundlegenden Konzepte, die Sie verstehen müssen, bevor Sie Ihren ersten agentischen Fall erstellen.

Zielgruppe: Anfänger bis Mittelstufe – Lösungsarchitekten, Geschäftsanalysten und Entwickler, die Maestro Case auswerten oder damit beginnen.

Warum Case Management

Herkömmliche Prozessautomatisierung funktioniert am besten, wenn der Arbeitsablauf vorhersehbar und wiederholbar ist. Viele Geschäftsszenarien sind jedoch nicht so. Sie können Tage oder Wochen überspannen, mehrere Teams einbeziehen und Entscheidungen erfordern, die nicht vollständig automatisiert werden können. In diesen Situationen sind Ausnahmen nicht selten – sie werden erwartet.

Das Case Management geht diese Herausforderung an, indem es eine Struktur ohne Starrheit bietet. Dadurch können Automatisierung und KI Routine- oder wiederholbare Arbeit übernehmen, während Menschen eingreifen können, wenn Beurteilungs- oder Richtlinienentscheidungen erforderlich sind.

Schwachstellen, die durch das Case Management gelöst werden

Schwachpunkt	Wie das Case Management dies löst
Keine beständige Fallkonstruktion oder Lebenszyklusverfolgung	Führt eine Case Entität [Demnächst verfügbar] mit vollständigem Lebenszyklus, Status und Verlauf ein
Keine native Phasenmodellierung	Fügt eine visuelle Phasen-Arbeitsfläche hinzu, um sequenzielle Phasen und Übergänge zu definieren
Kein Übergang zur Entwurfszeit oder gezielter Wiedereintritt	Ermöglicht regelbasierte Phasenübergänge und den Wiedereintritt zur genauen Aufgabe in einer vorherigen Phase
Eingeschränkte SLA- und Eskalations-Steuerung	Unterstützt die SLA-Nachverfolgung auf Fall-, Phasen- und Aufgabenebene mit Eskalationsregeln und Anhalten/Fortsetzen
Kein einheitliches Erlebnis für Fallbearbeiter und Manager	Stellt die Case App für Zusammenarbeit, Aufgabenverwaltung und Sichtbarkeit bereit
Keine Flexibilität für Ad-hoc-Arbeit	Ermöglicht die Erstellung von Ad-hoc-Aufgaben zur Laufzeit für Ausnahmen oder zusätzliche Überprüfungen

Wann Case Management verwendet werden soll

Das Case Management ist am effektivsten, wenn die Arbeit im Voraus nicht vollständig definiert werden kann. Diese Szenarien beinhalten oft mehrere Phasen, häufige Entscheidungspunkte und die Zusammenarbeit zwischen verschiedenen Benutzergruppen oder Systemen. Der Fortschritt hängt nicht nur vom Abschluss der Aufgaben ab, sondern auch von der Auswertung der Ergebnisse und der Entscheidung über die nächsten Schritte.

Geschäftsszenarien

Szenario	Warum Case Management
Versicherungsansprüche	Langlaufend, mehrseitig (Antragsteller, Schadensregulierer, Inspektor), häufige Ausnahmen (fehlende Dokumente, Streitigkeiten), SLA-gesteuert
Streitigkeiten und Rückbuchungen	Austausch zwischen den Parteien, Beweiserhebung, Eskalationspfade, nichtlineare Progression
Kreditvergabe und Risikoprüfung	Mehrere Prüfphasen (Kredit, Compliance, Risikoprüfung), bedingte Pfade basierend auf Risikobewertung, regulatorische Anforderungen
KYC/AML-Korrektur	Dokumentsammlung über Phasen hinweg, regulatorische Entscheidungspunkte, Anforderungen des Prüfungspfads
Kundeneskalationen und Beschwerden	Mehrstufige Lösung, Wiedereintritt bei nicht erfolgreicher Korrektur, SLA-Verpflichtungen, Übergaben zwischen mehreren Teams
Ausnahmen von der Auftragserfüllung	Rückstände, Teillieferungen, Retouren – Koordination mehrerer Systeme mit SLA-Nachverfolgung
Untersuchungen und Weiterleitungen im öffentlichen Sektor	Ad-hoc-Genehmigungen, abteilungsübergreifende Koordinierung, richtlinienabhängiges Routing
Anbieter-Onboarding	Mehrstufige Prüfung (Recht, Compliance, Finanzen), bedingte Phasen basierend auf dem Typ des Anbieters, Dokumentensammlung

Case Management schafft einen Mehrwert, wenn

• Die Arbeit ist langfristig – sie erstreckt sich über Stunden, Tage oder Wochen und nicht über Sekunden.
• Der Prozess ist ausnahmeintensiv – der nächste Schritt hängt davon ab, was gerade passiert ist, und kein einzelnes Flowchart erfasst alle Pfade.
• Mehrere Rollen und Systeme sind beteiligt – Fallbearbeiter, Manager, KI-Agenten und externe Integrationen tragen alle dazu bei.
• SLA-Nachverfolgung und Eskalation sind kritisch – Fristen sind wichtig und Verstöße müssen bestimmte Aktionen auslösen.
• Prüfpfade sind erforderlich – jede Entscheidung, Datenänderung und jeder Übergang müssen aufgezeichnet werden.
• Wiedereintritts- und Nachbearbeitungsschleifen sind üblich – Fälle kehren häufig zu früheren Phasen zurück, um Korrekturen oder zusätzliche Untersuchungen vorzunehmen.

Case Management ist nicht erforderlich, wenn

Nicht jeder Prozess erfordert ein Case Management. Wenn ein Prozess kurzlebig und vorhersehbar ist und jedes Mal derselben Sequenz folgt, ist ein Maestro BPMN oft einfacher und effizienter.

Hinweis:

Schnelltest: Wenn der nächste Schritt davon abhängt, was gerade passiert ist, und kein einzelnes Flowchart alle Pfade erfassen kann, sollten Sie ein Case Management in Betracht ziehen. Wenn der Prozess jedes Mal demselben Pfad folgt, verwenden Sie Maestro BPMN.

Freigegebene Grundlagen

Beide Projekttypen verwenden dieselben UiPath-Platform-Dienste und Aufgabentypen wieder:

• RPA-Workflows für die UI-Automatisierung in Altsystemen.
• API-Workflows und Integrationen für System-zu-System-Vorgänge.
• KI-Agenten (UiPath oder extern) für nicht-deterministische Aufgaben.
• Menschliche Aufgaben über Aktions-Apps für Formulare, Genehmigungen und Überprüfungen.
• Data Fabric für Geschäftsdatenverwaltung und Datenkonnektivität.
• Studio Web als Designumgebung.

Hauptunterschiede

Dimension	Maestro-BPMN	Maestro-Fall
Arbeitsstruktur	Definierte Sequenz von Schritten, die in der BPMN-Notation modelliert werden	Benannte Phasen mit regelbasierten Übergängen; der Laufzeit-Pfad wird dynamisch bestimmt
Lebenszyklus	In der Regel kurz- bis mittellebig; folgt einem vorher festgelegten Ablauf	Langlebig und zielorientiert; entwickelt sich weiter, sobald neue Informationen verfügbar werden
Nicht-linearer Ablauf	Möglich über BPMN-Gateways und -Schleifen, aber komplex zu modellieren für sehr variable Szenarien	Integrierte Unterstützung für Wiedereintritt, sekundäre Phasen, Überspringen von Regeln und Ad-hoc-Aufgaben
Datenmodell	Prozessvariablen, die auf die Instanz beschränkt sind	Auf die Instanz beschränkte Fallvariablen + Persistente Case Entität [in Kürze verfügbar] – ein zentraler, typisierter Geschäftsdatensatz, auf den alle Phasen, Aufgaben und Bedingungen lesend und schreibend zugreifen
SLAs und Eskalationen	Nicht nativ auf Prozessebene modelliert	First-Class-Konstrukte sowohl auf Fallebene als auch auf Phasenebene mit Eskalationsregeln für Gefährung und Fristüberschreitung
User Experience	Überwacht über die Registerkarte Maestro-Überwachung für Operatoren	Dedizierte Case App für Geschäftsbenutzer (Fallliste, Detailansicht, Aufgabenposteingang) und Case-Instanz-Management für Operatoren
Rollenbasierter Zugriff	Standard Plattform-Berechtigungen	Phasenbewusste Personas – Definieren Sie, wer in jeder Phase sehen und handeln kann.
Ad-hoc-Arbeit	Nicht unterstützt; alle Schritte werden zur Entwurfszeit definiert	Unterstützt – Der Case Manager oder ein menschlicher Benutzer kann Aufgaben zur Laufzeit erstellen

Ein Fall kann ein Maestro BPMN als einen seiner Aufgabentypen aufrufen, und ein Maestro BPMN kann einen Fall als einen seiner Aufgabentypen aufrufen – sodass sich die beiden Projekttypen ergänzen, anstatt zu konkurrieren. Verwenden Sie Maestro BPMN für gut definierte Unterprozesse und Maestro Case als äußere Orchestrierungsebene, wenn der Gesamtablauf dynamisch ist.

Von Grund auf agentenzentriert

Case Management ist die richtige Form für ausnahmereiche Arbeit mit langen Ausführungszeiten – aber für sich allein ist es weiterhin auf menschliche Wissensarbeiter angewiesen, um die meisten Routing- und Ermessensentscheidungen zu treffen.Maestro Case ist primär agentenbasiert und KI-nativ: KI-Agenten sind erstklassige Teilnehmer im Fall und arbeiten auf zwei verschiedenen Ebenen:

• Als Aufgabenbearbeiter in Phasen – Kategorisieren von Daten, Markieren von Anomalien, Extrahieren von Feldern aus Dokumenten, Erstellen von Antworten, Überprüfen von Richtlinien. Jeder Agent wird in einer Aufgabe ausgeführt, liest, was erforderlich ist, aus der Case Entität[Demnächst verfügbar], erledigt seine Arbeit und schreibt seine Ergebnisse zurück.
• Als Orchestrator des Falls selbst – steuert der Case Manager-Agent den Fall von der Erstellung bis zum Abschluss und trifft Entscheidungen sowohl auf Phasen- als auch auf Aufgabenebene: Welche Phase als nächstes aktiviert werden soll, welche Aufgaben in dieser Phase ausgeführt werden sollen, wann eine Aufgabe oder Phase abgeschlossen ist oder frühzeitig beendet werden soll und wann eskaliert werden soll. Er arbeitet zusammen mit deterministischen Regeln, wo sie vorhanden sind, und zieht Schlüsse aus Falldaten und Richtlinien, wo sie nicht vorhanden sind.

Dadurch wird der traditionelle Engpass beseitigt, der durch das ausschließliche Vertrauen auf menschliche Wissensarbeiter bei Routing-Entscheidungen, der Behandlung von Ausnahmen und dem Vorantreiben von Fällen entsteht.Menschen greifen ein, wenn die Richtlinie, die Beurteilung oder die Rechenschaftspflicht es erfordert – nicht, weil der Fall ohne sie nicht weitergeführt werden kann.

Maestro Case-Toolset

Maestro Case deckt den End-to-End-Falllebenszyklus über drei sich ergänzende Oberflächen ab:

Case Plan-Designer (Studio Web)

Für wen es geeignet ist: Automation Developers und Geschäftsarchitekten.

Verwenden Sie es, um einen Case Plan zu erstellen oder zu aktualisieren – Phasen, Übergänge, SLAs, Eskalationen und Zugriff auf Phasenebene.Weisen Sie den Aufgaben Implementierungen zu (Human, RPA, API, KI-Agent, agentischer Prozess, untergeordneter Fall).Ordnen Sie Eingaben und Ausgaben zu und legen Sie das Wiedereintrittsverhalten fest. Die Ausgabe ist ein versionierter Case Plan, der zur Veröffentlichung und Bereitstellung bereit ist.

Verwaltung der Case-Instanz (Maestro)

Für wen es bestimmt ist: Prozessbetreiber, Incident Manager und Prozessverantwortliche.

Verwenden Sie ihn, um laufende Fälle mit Lebenszyklussteuerungen (Anhalten, fortsetzen, Abbrechen, Migrieren) und vollständiger Prüfung zu betreiben.Lösen Sie Vorfälle, indem Sie fehlgeschlagene Aufgaben erneut versuchen oder Instanzen zu neueren Case Plan-Versionen migrieren. Verwenden Sie Live-Insights, Heatmaps und Process Mining, um Engpässe zu erkennen und Verbesserungen in das Design zurückzugeben.

Case App (Maestro)

Für wen es bestimmt ist: Fallbearbeiter und Case Manager.

Verwenden Sie sie, um alle Fälle und Falldetails (Zeitleiste, Falldaten, menschliche Aufgaben) anzuzeigen und schnelle Aktionen wie Abschließen und Erneut öffnen auszuführen.Die Case App ist ein festgelegter, fallzentrierter WorkSpace – Listen, Details, Aufgaben und SLA-Ansichten.Benutzer-Aufgaben-Formulare werden weiterhin mit Aktion-Apps erstellt und Fallaufgaben beziehen sich darauf.

Die Case App ist in zwei Optionen verfügbar:

Option	Beschreibung	Einsatzbereich
Anwendungsbereite Case App	Ein vorgefertigter Fall-WorkSpace ohne Code, der mit Maestro Case ausgeliefert wird. Listen, Detailansichten, Aufgabenposteingang und SLA-Ansichten werden automatisch über Ihren Case Plan und Ihre Entität konfiguriert.	Standard – Verwenden Sie ihn für schnelle Fallvorgänge, ohne einen Code zu schreiben.
Individuell codierte Case App	Eine maßgeschneiderte Case App, die Sie mit dem Pro-Code-TypeScript SDK erstellen. Ermöglicht das Erstellen benutzerdefinierter Ansichten, Layouts und Workflows über dieselbe Fall-Laufzeit.	Wenn Sie eine UI benötigen, die über das hinausgeht, was die anwendungsbereite App anzeigt – markenspezifische Arbeitsbereiche, benutzerdefinierte Dashboards oder domänenspezifische Fallerfahrungen.

Hinweis:

Die Case App unterscheidet sich von UiPath Apps. Die Case App ist speziell für Fallvorgänge konzipiert. UiPath Apps ist ein allgemeiner Low-Code-Builder für vollständig benutzerdefinierte oder zusammengesetzte Geschäfts-Apps. Verwenden Sie die Case App für schnelle Fallvorgänge; verwenden Sie UiPath-Apps, wenn Sie eine maßgeschneiderte UI über die Fallvorgänge hinaus benötigen.

Kernkonzepte

Vor dem Entwerfen eines Agentic-Falls ist das Verständnis der folgenden Konzepte unerlässlich.

Fall und Fallschlüssel

Ein Fall stellt eine reale Geschäftssituation dar, die gelöst werden muss – ein Anspruch, eine Streitigkeit, eine Untersuchung. Im Gegensatz zu einer herkömmlichen Prozessinstanz entwickelt sich ein Fall im Laufe der Zeit, wenn neue Informationen verfügbar werden und Entscheidungen getroffen werden.

Jeder Fall wird durch einen Fallschlüssel eindeutig identifiziert:

Tastentyp	Beschreibung	Beispiel
Systemschlüssel	Automatisch von Maestro bei der Fallerstellung generiert.	HC-1234, CLM-00891
Externer (kundenseitig definierter) Schlüssel	Eine vorgelagerte, bei der Erstellung übergebene ID, damit derselbe reale Fall in allen Tools erkannt wird	CRM-Fallnummer, Policennummer, ERP-Auftrags-ID

Verwenden Sie externe Schlüssel, wenn der Fall aus einem anderen System (CRM, ERP, Ticketing-Tool) stammt, damit Menschen und Integrationen den Fall toolübergreifend korrelieren können, ohne eine separate Zuordnungstabelle zu pflegen.

Case-Entität

Die Case Entität [In Kürze verfügbar] ist der beständiige, typisierte Geschäftsdatensatz im Zentrum jedes Falls. Sie ist die zentrale Quelle, auf die die Phasen, Aufgaben und Übergangsbedingungen während des gesamten Falllebenszyklus lesend und schreibend zugreifen.

Jedes Fallprojekt enthält außerdem zwei zusätzliche sofort einsetzbare Datenobjekte:

• Falldokumente – Anhänge und Dateien, die mit dem Fall verknüpft sind (Belege, Fotos, Verträge).
• Fallkommentare – Hinweise, Anmerkungen und Kommunikation, die von Fallbearbeitern und Managern während der Laufzeit hinzugefügt werden.

Alle drei Objekte teilen sich ein unveränderliches caseID Systemfeld, das bei der Fallerstellung generiert wird.

Sie können die Case Entität auf drei Arten in Maestro Case importieren:

Quelle	Beschreibung	Einsatzbereich
Natives Data Fabric-Objekt	Aktivieren Sie den Case Entität-Umschalter in Ihrem Fallprojekt, wodurch automatisch eine native Data Fabric-Case Entität erstellt und mit Ihrem Fall verknüpft wird.	Neue Prozesse, bei denen Sie das Datenmodell besitzen
Datensatz-System über VDO	Registrieren Sie eine externe Quelle als Virtual Data Object (VDO) in Data Fabric, aktivieren Sie den Umschalter der Fall-Entität und stellen Sie eine Beziehung zwischen dem VDO und der Entität in Data Fabric her.	Entitätsdaten befinden sich in einem externen System und Sie möchten darauf verweisen, ohne sie zu duplizieren.
Datensatz-System über Fall-Trigger	Übergeben Sie vorhandene Daten im Trigger zur Fallerstellung (z. B. über einen API-Connector); die Felder werden zu Fallfeldern, die im gesamten Fall verfügbar sind	Leichte Integrationen, bei denen Sie den Fall zum Zeitpunkt der Erstellung füllen.

Phasen

Phasen sind die benannten Stufen eines Falls – zum Beispiel Aufnahme, Überprüfung, Abrechnung, Abschluss.Eine Phase ist praktisch eine Sammlung von Aufgaben, die den Fall zum Abschlusszustand der Phase verschieben.

Primäre vs. sekundäre Phasen

Maestro Case unterstützt zwei Arten von Phasen:

Phasentyp	Zweck	Wie es erreicht wird	Sichtbarkeit in der Case App
Anfangsphase	Der erwartete Verlauf des Falls (z. B. Aufnahme → Überprüfung → Abrechnung → Abschluss).	Kann über Kanten einer vorherigen Phase auf der Arbeitsfläche oder über die konfigurierte Eintrittsbedingung eingegeben werden – beides ist gültig.	Werden als Kernphasenknoten in der Zeitleiste der Case App angezeigt – dies sind die Phasen, die Fallbearbeiter als Hauptlebenszyklus sehen.
Sekundäre Phase	Ausnahme oder alternative Pfade, die jederzeit während des Falls auftreten können (z. B. Info anfordern, Abgelehnt, Zurückgezogen, Abgebrochen).	Keine eingehenden Kanten – das Umschalten einer Phase auf sekundär entfernt sie. Die Phase wird nur erreicht, wenn ihre Eintrittsbedingung als „true“ ausgewertet wird, und kann jederzeit aktivieret werden unabhängig davon, wo sich der Fall gerade befindet.	Nicht Teil der Zeitleiste der Kernphase. Werden separat angezeigt, wenn sie aktiv sind (z. B. als Ausnahmepfadindikator), da sie zu jedem Zeitpunkt ausgelöst werden können.

Mit anderen Worten, das Markieren einer Phase als sekundär bedeutet: Verknüpfen Sie mich nicht mit dem Hauptlebenszyklus – ich werde mich selbst aktivieren, sobald meine Eintrittsbedingung erfüllt ist.Dadurch kann ein Fall während der Überprüfung in den Status „Info anfordern“ oder von überall aus in den Status „Zurückgezogen“ springen, ohne dass der Designer Kanten aus jeder möglichen Quelle zeichnen muss.

Phasenattribute

Jede Phase definiert:

• Eintrittsbedingung – wann diese Phase beginnt.
• Abschlussbedingung – was wahr sein muss, um die Phase als abgeschlossen zu markieren und fortzufahren.
• Austrittsbedingung – wann die Phase frühzeitig verlassen wird (z. B. Rettungs- oder Umleitungsszenarien).
• Wiedereintrittsbedingung – wie Nachbearbeitung oder Rückkehr zum Ursprung hierher zurückführt.
• Phasen-SLA und Eskalationen – Fälligkeitszeit, Warn-Schwellenwerte sowie Eskalationsbenachrichtigungs- und E-Mail-Empfänger.

Phasen können als erforderlich oder optional markiert werden. Ein Fall kann erst abgeschlossen werden, wenn jede erforderliche Phase abgeschlossen ist. Optionale Phasen werden nur aktiviert, wenn ihre Eintrittsbedingungen erfüllt sind, und können übersprungen werden, ohne den Fall zu blockieren.

Parallele Phasen

Mehrere Phasen können gleichzeitig im selben Fall aktiv sein. Beispielsweise kann eine Phase der Kundenkommunikation neben der Risikoprüfungausgeführt werden, während die Abrechnung im Hintergrund vorbereitet wird. Ob Phasen parallel oder nacheinander ausgeführt werden, wird durch Eintrittsregeln gesteuert.

Aufgaben

Eine Aufgabe ist eine Arbeitseinheit in einer Phase.

Aufgabentypen

Maestro Case unterstützt die folgenden Aufgabentypen:

Aufgabentyp	Beschreibung
Menschliche Aktion	Formulare, Genehmigungen und Klärungen, die einer Person zugewiesen sind
RPA-Workflow	UI-Automatisierung für Altsysteme, Extraktion und Abstimmung
API-Workflow	System-zu-System-Vorgänge über Workflow
Connector ausführen	Eine Connector-Aktivität aufrufen (z. B. eine Benachrichtigung senden, einen Datensatz in einem externen System erstellen)
KI-Agent (UiPath)	Autonomes Schlussfolgern anhand von Daten für entscheidungsbasierte Arbeiten
Externer Agent	KI-Agent eines Drittanbieters, der über die API aufgerufen wird
Agentischer Maestro Prozess	Ein mehrstufiger BPMN-Prozess, der als Aufgabe aufgerufen wird
Untergeordneter Fall	Ein anderer Fall wird als untergeordneter Fall mit einem eigenen Lebenszyklus generiert.
Warten auf Timer	Anhalten, bis eine Dauer abgelaufen oder ein Zieldatum erreicht ist
Auf Connector-Ereignis warten	Anhalten, bis ein externes Ereignis über einen Connector eintrifft

Ausführungsmodi

Unabhängig von ihrem Typ wird jede Aufgabe in einem von drei Ausführungsmodi ausgeführt, die bestimmen, wann sie gestartet wird:

Ausführungsmodus	Verhalten	Beispiel
Sequenziell	Die Aufgabe wird in einer definierten Reihenfolge in der Phase ausgeführt. Eine Sequenz kann auch parallele Verzweigungen enthalten, die sich verzweigen und vor dem nächsten Schritt wieder zusammenlaufen.	In einer Phase der Risikoprüfung Verify income → (Run credit check ∥ Pull employment history) → Calculate DTI → Generate decision
Ereignisgesteuert	Die Aufgabe hat eine Eintrittsregel und wird ausgelöst, wenn das Ereignis die Auswertung der Regel wahr macht – auch wenn sich die Phase in Ausführung befindet oder die Sequenz diesen Punkt bereits überschritten hat. Sie kann mehr als einmal ausgelöst werden, wenn das Ereignis wiederholt auftritt.	In einer Phase der Schadensverarbeitung: wird Request additional documents ausgelöst, WENN eine Verifizierungsaufgabe ein fehlendes Dokument kennzeichnet FALLS Documents.Missing == true – unabhängig davon, wo sich die Phase derzeit in der Sequenz befindet.
Ad-hoc	Die Aufgabe ist im Case Plan definiert, startet aber nur, wenn ein Benutzer sie zur Laufzeit manuell auslöst. Ad-hoc-Aufgaben können von jedem oben aufgeführten Aufgabentyp sein.	In einer Phase der Kunden-Eskalation: Escalate to supervisor oder Add fraud review – ausgelöst durch den Fallbearbeiter bei der Prüfung

Mehrere Aufgaben können gleichzeitig in derselben Phase aktiv sein. Sequenzielle Verzweigungen können zu parallelen Pfaden auffächern und vor dem nächsten Schritt wieder verbunden werden.Ereignisgesteuerte Aufgaben werden unabhängig von der Sequenz ausgelöst und werden häufig parallel zu allem ausgeführt, was gerade aktiv ist – einschließlich mehrerer Instanzen derselben ereignisgesteuerten Aufgabe, die gleichzeitig ausgelöst werden, wenn das auslösende Ereignis wiederholt auftritt.Ad-hoc-Aufgaben können jederzeit neben laufenden Aufgaben gestartet werden.

Nur einmal ausgeführt

Wenn eine Phase erneut aufgerufen wird, legen Sie für jede Aufgabe fest, welche Aufgaben erneut ausgeführt werden sollen, über das Kennzeichen Nur einmal ausführen:

• Nur einmal ausführen = true – Die Aufgabe wird beim Wiedereintritt übersprungen. Die vorherige Ausgabe wird beibehalten und die Aufgabe wird nicht erneut ausgeführt.
• Nur einmal ausführen = false (Standard) – Die Aufgabe wird bei jedem Wiedereintritt in die Phase zurückgesetzt und erneut ausgeführt, was eine neue Ausgabe erzeugt.

Beispiel: In einer Phase der Dokumentsammlung ist die Aufgabe Send document checklist to customer als „nur einmal ausführen“ gekennzeichnet – Sie möchten dem Kunden nicht jedes Mal eine E-Mail senden, wenn die Phase aus einem anderen Grund erneut geöffnet wird.Die Aufgabe Validate documents wird beim Standardwert belassen, sodass jede neue Einreichung neu validiert wird.

Sonstige Aufgabenkonfiguration

Jede Aufgabe unterstützt außerdem Eingaben und Ausgaben, die der Case Entität zugeordnet sind.

Regeln

Regeln steuern die Bewegung des Lebenszyklus und sind der Mechanismus, der das Case Management nicht-linear macht.Sie folgen dem CMMN-Muster (Case Management Model and Notation) und sind ereignisgesteuert – eine Regel wird nur ausgelöst, wenn ein relevantes Ereignis im Fall auftritt, nicht bei einem Abrufzeitplan oder einer festen Sequenz.

Jede Regel hat drei Teile:

• WHEN – das Ereignis, das die Auswertung auslöst. Es gibt zwei Arten von Ereignissen:
  • Interne Ereignisse, die vom Falllebenszyklus selbst ausgegeben werden – CaseCreated, StageEntered, StageCompleted, StageExited, TaskCompleted, CaseSlaAtRisk, CaseSlaBreached, StageSlaAtRisk, StageSlaBreached, und Änderungen an Entitätsfeldern des Falls, die von Aufgaben zurückgeschrieben werden.
  • Externe Ereignisse, die von außerhalb des Falls eintreffen – Integration Service-Connector-Ereignisse (Webhooks, Warteschlangenachrichten), Timer-Auslöser, Abschluss oder Austritt eines untergeordneten Falls und direkte API-Aufrufe zum Fall.
• WENN (optional) – die Bedingung für die Case-Entität, die auch wahr sein muss, damit die Regel wirksam wird. Wenn sie weggelassen wird, wird die Regel bei jedem entsprechenden WHEN-Ereignis ausgelöst.
• Aktion – was die Regel tut, wenn sie ausgelöst wird (eine Phase starten, eine Phase abschließen, eine Phase verlassen, den Fall abschließen usw.).

Regeln sind auf eine von drei Ebenen beschränkt: Fall, Phase oder Aufgabe.

Regeln auf Fallebene

Regel	Zweck	Beispiel
Fall abgeschlossen	Den gesamten Fall als abgeschlossen markieren (erfolgreiches Ergebnis).	WENN alle erforderlichen Phasen abgeschlossen sind, FALLSOutcome == "Approved"
Fallaustritt	Den Fall beenden, bevor er den normalen Abschluss erreicht (Abbrechen, Rücknahme, Betrug).	Wenn Application.Status Änderungen IFApplication.Status == "Withdrawn"

Regeln auf Phasenebene

Regel	Zweck	Beispiel
Eintrag	Kontrollpunkt, wenn die Phase beginnt.	Wenn Application.Submitted Ereignis trifft ein, FALLSApplication.Type == "Mortgage" && Documents.Count > 0
Abgeschlossen	Festlegen, wann die Phase normal abgeschlossen wird.	WENN eine beliebige Aufgabe in der Phase abgeschlossen ist, FALLS alle erforderlichen Aufgaben Done und UnderwritingDecision != null sind
Beenden	Verlassen Sie die Phase frühzeitig, auch wenn sie unvollständig ist.	Wenn UnderwritingDecision Änderungen IFUnderwritingDecision == "Reject"
Erneuter Eintrag	Kehren Sie zu einer zuvor abgeschlossenen Phase für eine kontrollierte Nacharbeit zurück.	Wenn Verification.Result Änderungen IFVerification.Result == "Failed" && DocsComplete == false

Eintrittsregeln enthalten ein unterbrechenden Umschalter, der steuert, was mit anderen aktiven Phasen geschieht, wenn die Eintrittsregel als wahr ausgewertet wird:

• Unterbrechung = true – Alle derzeit aktiven Phasen werden automatisch beendet, und der Fall wird in die neu eintretende Phase gezwungen. Verwenden Sie dies für harte Ausnahmepfade wie Zurückgezogen oder Betrugssperre, die den Fall sofort übernehmen müssen.
• Unterbrechung = false – Die neue Phase wird neben allen vorhandenen aktiven Phasen aktiviert. Im Fall können mehrere Phasen parallel laufen.

Standardwerte unterscheiden sich nach Phasentyp: Primärphasen sind standardmäßig auf Unterbrechung = false eingestellt (Parallelzusammenführung – der normale Verlauf der Arbeit). Sekundäre Phasen sind standardmäßig auf Unterbrechung = true eingestellt (übernehmen den Fall – da sekundäre Phasen Ausnahme- oder Alternativpfade darstellen).Beide Standardwerte können pro Phase überschrieben werden.

Abschluss- und Austrittsregeln enthalten außerdem eine Aktion, die bestimmt, was mit dem Fall nach dem Ende der Phase geschieht:

• Den Fall fertig stellen / Den Fall verlassen – den Fall von hier aus fertig stellen oder beenden.
• Auf manuelle Auswahl warten – pausieren und einen Benutzer die nächste Phase auswählen lassen.
• Zum Ursprung zurückkehren – Leiten Sie den Fall zurück zu der Phase, die diese ursprünglich aktiviert hat.

Regeln auf Aufgabenebene

Regel	Zweck	Beispiel
Eintrag	Kontrollpunkt, wenn eine Aufgabe innerhalb einer Phase startet.Wird von ereignisgesteuerten Aufgaben verwendet, um ein auslösendes Ereignis in Gang zu setzen, und optional von sequenziellen oder Ad-hoc-Aufgaben, um die Ausführung zu schützen.	WHEN eine Verifizierungsaufgabe ein fehlendes Dokument kennzeichnet, IF Documents.Missing == true

Da Regeln ereignisgesteuert sind, wird der Fall nicht in einer festen Sequenz ausgeführt – Phasen und Aufgaben werden aktiviert, abgeschlossen, beendet oder erneut geöffnet, wenn ihr WHEN-Ereignis eintrifft und die IF-Bedingung (falls vorhanden) als true gegenüber der aktuellen Entität ausgewertet wird.Die erneute Ausführung von Aufgaben beim erneuten Eintritt in die Phase wird durch das Kennzeichen „nur einmal ausführen“ gesteuert, wie im Abschnitt Aufgaben oben beschrieben.

Case Manager

Der Case Manager ist der Orchestrator eines Falls – der Agent, der Lebenszyklusentscheidungen basierend auf Ereignissen steuert. Er entscheidet, welche Phase als nächstes aktiviert werden soll, welche Aufgaben gestartet werden sollen, wann eine Phase abgeschlossen oder frühzeitig beendet werden soll und wann eskaliert werden muss.

Er orchestriert mit zwei komplementären Methoden:

1. Regeln (primär) – Für jeden Entscheidungspunkt wertet der Case Manager zuerst die im Case Plan definierten deterministischen CMMN-Regeln aus. Wenn eine Regel die Entscheidung trifft, wird diese umgesetzt.Dadurch bleiben die Standardabläufe mit hohem Volumen vorhersehbar, prüfbar und kostengünstig.
2. Agent (Fallback) – wenn keine Regel die Situation abdeckt (eine Lücke, eine Ausnahme oder eine Ermessensentscheidung), analysiert der Case Manager die Entität, den Case Plan sowie die verfügbaren Richtlinien und das Wissen, um die nächste Aktion auszuwählen.Dadurch bleibt ein Fall in Bewegung, ohne dass es für jeden nicht abgedeckten Zweig zu einer Eskalation an einen Mitarbeiter kommt.

Um einen Fall zu steuern, muss der Case Manager-Agent einem definierten Eingabe-/Ausgabevertrag entsprechen, der angibt, welchen Fallstatus, welche Ereignisse und welche Richtlinien er lesen kann und welche Phasen-/Aufgabenentscheidungen er ausgeben kann. Die vollständige Spezifikation finden Sie im Case Manager-Agenten-Vertrag.

SLAs und Eskalationen

SLAs und Eskalationsregeln sowohl auf Fall- als auch auf Phasenebene festlegen:

• SLA auf Fallebene – Gesamtlösungsziel (z. B. innerhalb von 48 Stunden abschließen).
• SLA auf Phasenebene – lokalisierte Fälligkeitszeit (z. B. Überprüfung innerhalb von 24 Stunden).
• SLA-Status – im Zeitplan, gefährdet oder Verstoß. Diese Zustände werden als Markierungen in Falllisten und Detailansichten angezeigt.
• Eskalationen – Regeln, die ausgelöst werden, wenn ein SLA gefährdet ist oder gegen ihn verstoßen wird (z. B. neu zuweisen, Management benachrichtigen, ein Prioritäts-Kennzeichen erstellen).
• Anhalten/Fortsetzen – SLA-Timer können angehalten werden, wenn der Fall auf externe Eingaben wartet, und fortgesetzt werden, wenn er wieder ausführbar ist.

Fallpersonas

Maestro Case gewährleistet den phasenbewussten Zugriff über Personas, damit die richtigen Personen zum richtigen Zeitpunkt sehen und handeln können:

Eine Case-Persona ist eine Entwurfszeit-Abstraktion, die eine Rolle innerhalb eines Falltyps darstellt (z. B. Aufnahme-Agent, Schadensachbearbeiter, Supervisor). Personas entkoppeln die Zugriffsanforderungen eines Falls von der Identitätsstruktur der Organisation, sodass Falldefinitionen über Organisationen und Mandanten hinweg portabel sind.

• Während der Design-Phase erstellt der Case Designer Personas und legt deren Geltungsbereich für bestimmte Phasen fest.
• Zur Bereitstellungszeit bindet ein Administrator jede Persona an Benutzer oder Benutzergruppen, sodass derselbe Falltyp unterschiedliche Anwendungsbereiche in verschiedenen Umgebungen haben kann.
• Zur Laufzeit löst das System die Persona(s) des Benutzers auf und erzwingt die Festlegung des Bereichs der Phasen. Ein Benutzer mit mehreren Personas erhält die Vereinigung von Phasen-Anwendungsbereichen.

Beispielsweise könnte ein Fall der Kreditbearbeitung Folgendes definieren:

Persona	Anwendung	Überprüfung	Underwriting	Auszahlung
Kreditsachbearbeiter	ja
Verifizierungsanalyst		ja
Risikoprüfer			ja
Filialmanager	ja	ja	ja	ja

Aufgaben innerhalb einer Phase werden einer Persona und nicht einem bestimmten Benutzer zugewiesen. Das System löst die Persona zur Rolle/Gruppe zu Benutzern zur Laufzeit auf, um die Sichtbarkeit und Zuweisung von Aufgaben zu bestimmen.

Hinweis:

Benutzerrollen für den gesamten Fall und die Unterstützung für den Zugriff sind in Kürze verfügbar.

Abrechnung und Verbrauchsmaterialien

Maestro Case folgt derselben Abrechnung wie Maestro. Die Arbeit, die in einem Fall ausgeführt wird, verbraucht die nativen Verbrauchseinheiten der von Ihnen verwendeten Aufgabentypen (KI-Agenten, RPA-Workflows, API-Workflows oder IS-Connectors).

Nächste Schritte

• Ihr erstes Maestro-Fallprojekt erstellen – Ein Schritt-für-Schritt-Tutorial, das das Erstellen, Bereitstellen und Testen eines Sachversicherungsfalls von Grund auf durchläuft.
• Referenz zu Kernkonstrukten – Detaillierte Referenz für jedes Maestro-Fallkonstrukt: Case Entität[In Kürze verfügbar], Phasen, Aufgaben, Übergangsbedingungen, SLAs und Personas.
• Konfigurieren von Phasenübergängen und Wiedereintritt – Eine Anleitung zur Modellierung nichtlinearer Fallabläufe mit Eintritts-, Austritts- und Wiedereintrittsbedingungen.