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
Inhalt gilt für	✅	❌

Überblick

Maestro Case orchestriert die langlebige, zielgesteuerte Arbeit zu einer bestimmten Situation – einem Fall. Ein Fall enthält Daten, Regeln, Aufgaben und Verlauf, um ein prüfbares Ergebnis wie eine Rückerstattung, eine Antragsentscheidung oder den Abschluss einer Untersuchung zu steuern. Während Maestro BPMN sich durch strukturierte, sequenzielle Orchestrierung auszeichnet, befasst sich Maestro Case mit ausnahmeintensiven, nicht linearen und bei wichtigen Entscheidungspunkten auf das Urteilsvermögen von Menschen und KI-Agents angewiesen.

Dieses Dokument führt Maestro Case als eigenständige Funktion in Maestro ein, führt die geschäftlichen Einsatzbereiche, die es löst, durch und erläutert, wann sie statt Maestro BPMN zu wählen ist, gibt Ihnen einen Überblick über die Tools, mit denen Sie arbeiten, und stellt die grundlegenden Konzepte vor, die Sie bearbeiten müssen bevor Sie Ihren ersten agentischen Fall erstellen.

Zielgruppe: Anfang bis Fortgeschritten – Lösungsarchitekten, Geschäftsanalysten und Entwickler, die Maestro Case bewerten oder damit beginnen.

Warum Fallverwaltung

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

Das Fallmanagement stellt sich dieser Herausforderung, indem es eine Struktur ohne starre Eigenschaften bietet. Sie ermöglicht es Automatisierung und KI, Routine- oder wiederholbare Arbeit zu übernehmen, während Menschen eingreifen können, wenn Urteilsvermögen oder Richtlinienentscheidungen erforderlich sind.

Probleme, die die Fallverwaltung löst

Problempunkt	Wie die Fallverwaltung damit umgeht
Keine persistente Fallkonstruktivität oder Lebenszyklusnachverfolgung	Führt eine Fallentität [in Kürze] mit vollständigem Lebenszyklus, Status und Verlauf ein
Keine native Phasenmodellierung	Fügt eine visuelle Phasenarbeitsfläche hinzu, um sequenzielle Phasen und Übergänge zu definieren
Kein Übergang zur Entwurfszeit oder gezielter erneuter Eintritt	Ermöglicht regelbasierte Phasenübergänge und den erneuten Eintritt in die genaue Aufgabe innerhalb einer vorherigen Phase
Eingeschränkte SLA und Eskalationskontrolle	Unterstützt die SLA-Nachverfolgung auf Fall-, Phasen- und Aufgabenebene mit Eskalationsregeln und Pause/Fortsetzen
Keine einheitliche Erfahrung für Fallmitarbeitende und Manager	Stellt eine Fall-App für die Zusammenarbeit, Aufgabenverwaltung und Transparenz bereit
Keine Flexibilität für Ad-hoc-Arbeit	Ermöglicht die Erstellung von Ad-hoc-Aufgaben zur Runtime für Ausnahmen oder zusätzliche Überprüfungen

Wann Sie die Fallverwaltung verwenden sollten

Die Fallverwaltung 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 Abschließen von Aufgaben ab, sondern von der Bewertung der Ergebnisse und der Entscheidung, was als Nächstes geschehen soll.

Geschäftsszenarien

Szenario	Warum Fallverwaltung
Versicherungsanspruch	Langfristig, mehrere Parteien (Antragsteller, Schadensregulierer, Prüfer), häufige Ausnahmen (fehlende Dokumente, Streitigkeiten), SLA-gesteuert
Streitigkeiten und Rückrufe	Hin und Her zwischen Parteien, Erfassung von Erfassungen, Eskalationspfade, nicht linearer Ablauf
Kreditvergabe und Underwriting	Mehrere Überprüfungsphasen (Kredit, Compliance, Underwriting), bedingte Pfade basierend auf Risikobewertungen, regulatorische Anforderungen
KYC/AML-Reparatur	Dokumentenerfassung über Phasen hinweg, regulatorische Entscheidungspunkte, Anforderungen an den Prüfungspfad
Kundeneskalationen und -beschwerden	Abgestufte Lösung, erneute Eingabe, wenn eine Lösung nicht gilt, SLA-Verpflichtungen, Übergaben an mehrere Teams
Ausnahmen bei der Auftragsabwicklung	Rückstände, teilweise Lieferungen, Returns – systemübergreifende Koordinierung mit SLA-Nachverfolgung
Untersuchungen und Empfehlungen des öffentlichen Sektors	Ad-hoc-Genehmigungen, abteilungsübergreifende Koordination, richtlinienabhängiges Routing
Anbieter-Onboarding	Mehrstufige Prüfung (Recht, Compliance, Finanzen), bedingte Phasen basierend auf dem Anbietertyp, Dokumentenerfassung

Die Fallverwaltung bietet einen Mehrwert, wenn

• Die Arbeit ist langlaufende – über Stunden, Tage oder Wochen statt über Sekunden.
• Der Prozess ist ausnahmeintensive – der nächste Schritt hängt davon ab, was gerade passiert ist, und kein einzelnes Flowchart erfasst jeden Pfad.
• Mehrere Rollen und Systeme sind beteiligt – Fallmitarbeitende, Manager, KI-Agenten und externe Integrationen tragen alle bei.
• SLA-Nachverfolgung und -Eskalation sind kritisch – Fristen sind wichtig und Verstöße müssen bestimmte Aktionen auslösen.
• Prüfungspfade sind erforderlich – jede Entscheidung, Datenänderung und jeder Übergang muss aufgezeichnet werden.
• Erneute Eingabe- und Nachbearbeitungsschleifen sind häufig – Fälle kehren häufig für Korrekturen oder zusätzliche Untersuchungen in frühere Phasen zurück.

Eine Fallverwaltung ist nicht erforderlich, wenn

Nicht jeder Prozess benötigt eine Fallverwaltung. Wenn ein Prozess kurzlebig und vorhersehbar ist und jedes Mal dem gleichen Ablauf folgt, ist ein BPMN von Maestro oft einfacher und effizienter.

Hinweis:

Schnelltest: Wenn der nächste Schritt davon abhängt, was gerade passiert ist und kein einziges Flowchart jeden Pfad erfassen kann, sollten Sie die Fallverwaltung in Betracht ziehen. Wenn der Prozess jedes Mal demselben Pfad folgt, verwenden Sie Maestro BPMN.

Gemeinsame Grundlagen

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

• RPA-Workflows für die UI-Automatisierung in Legacy-Systemen.
• API-Workflows und Integrationen für System-zu-System-Vorgänge.
• KI-Agents (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äftsdatenmanagement und Datenkonnektivität.
• Studio Web als Designumgebung.

Hauptunterschiede

Dimension	Maestro-BPMN	Maestro-Fall
Arbeitsstruktur	Definierte Sequenz von Schritten, die in BPMN-Notation modelliert wurden	Benannte Phasen mit regelbasierten Übergängen; Der Runtime-Pfad wird dynamisch bestimmt
Lebenszyklus	In der Regel kurz- bis mittellebig; folgt einem vorgegebenen Fluss	Langfristig und zielgesteuert; entwickelt sich, wenn neue Informationen verfügbar werden
Nicht linearer Fluss	Möglich über BPMN-Gateways und -Schleifen, aber komplex zu modellieren für stark variable Szenarien	Integrierte Unterstützung für den erneuten Eintritt, sekundäre Phasen, Überspringungsregeln und Ad-hoc-Aufgaben
Datenmodell	Prozessvariablen, die auf die Instanz beschränkt sind	Fallvariablen im Scope + Persistente Fallentität [In Kürze verfügbar] – ein zentraler, typisierter Geschäftsdatensatz, aus dem alle Phasen, Aufgaben und Bedingungen lesen und in den sie schreiben
SLAs und Eskalationen	Nicht nativ auf Prozessebene modelliert	Erstklassige Konstrukte sowohl auf Fall- als auch auf Phasenebene mit Eskalationsregeln für Gefährde und Verstöße
User Experience	Überwacht über die Registerkarte Überwachung von Maestro für Operatoren	Dedizierte Fall-App für Geschäftsbenutzer (Fallliste, Detailansicht, Aufgabeneingang) und Fallinstanzverwaltung für Operatoren
Rollenbasierter Zugriff	Berechtigungen für Standardplattformen	Phasenbewusste Personen – Definieren Sie, wer innerhalb jeder Phase sehen und handeln kann
Ad-hoc-Arbeit	Nicht unterstützt; Alle Schritte werden in der Entwurfsphase definiert	Unterstützt – Der Fallmanager oder ein menschlicher Benutzer kann Aufgaben zur Runtime erstellen

Ein Fall kann ein Maestro-BPMN als einen seiner Aufgabentypen aufrufen, und ein Maestro-BPMN kann einen Fall als einen seiner Aufgabentypen aufrufen – wodurch sich die beiden Projekttypen ergänzen und nicht konkurrieren. Verwenden Sie Maestro BPMN für klar definierte Teilprozesse und Maestro Case als äußere Orchestrierungsebene, wenn der Gesamtfluss dynamisch ist.

Agentic-First von Natur aus

Die Fallverwaltung ist die richtige Form für ausnahmeintensive Arbeit mit langer Ausführungszeit – aber für die meisten Routing- und Urteilsvermögen ist sie immer noch auf menschliches Wissen angewiesen. Maestro Fall ist „Agentic-First“ und KI-nativ: KI-Agents sind erstklassige Teilnehmer am Fall und arbeiten auf zwei verschiedenen Ebenen:

• Als Aufgabenbetreuer innerhalb von Phasen – Kategorisieren von Daten, Kennzeichnen von Anomalien, Extrahieren von Feldern aus Dokumenten, Verfassen von Antworten, Überprüfen von Richtlinien. Jeder Agent wird innerhalb einer Aufgabe ausgeführt, liest von der Fallentität [in Kürze] , was er benötigt, erledigt seine Arbeit und schreibt die Ergebnisse zurück.
• Als Orchestrator des Falls selbst – der Fallmanager-Agent steuert 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 innerhalb dieser Phase ausgeführt werden sollen, wenn eine Aufgabe oder Phase vorhanden ist abgeschlossen sind oder früh beendet werden sollten und wann die Eskalation durchgeführt werden soll. Es funktioniert zusammen mit deterministischen Regeln, wenn sie vorhanden sind, und mit Argumenten für Falldaten und Richtlinien, wenn sie nicht vorhanden sind.

Damit wird das herkömmliche Engpass beseitigt, bei dem man sich ausschließlich auf menschliche Wissensarbeitende verlassen muss, um Routing-Entscheidungen zu treffen, Ausnahmen zu behandeln und Fälle voranzutreiben. Menschen springen ein, wenn Richtlinien, Urteilsvermögen oder Verantwortlichkeit dies erfordern – nicht, weil der Fall nicht ohne sie bearbeitet werden kann.

Fall-Toolset von Maestro

Maestro Case umfasst den End-to-End-Lebenszyklus des Falls über drei sich ergänzende Oberflächen:

Fallplan-Designer (Studio Web)

Für wen es ist: Automatisierungsentwickler und Geschäftsarchitekt.

Verwenden Sie sie, um einen Fallplan zu erstellen oder zu aktualisieren – Phasen, Übergänge, SLAs, Eskalationen und Zugriff auf Phasenebene. Implementierungen zu Aufgaben hinzufügen (Human, RPA, API, AI Agent, Agentic Process, Untergeordneter Fall). Ordnen Sie Eingaben und Ausgaben zu und legen Sie das Verhalten bei der erneuten Eingabe fest. Die Ausgabe ist ein versionierter Fallplan, der veröffentlicht und bereitgestellt werden kann.

Verwaltung von Fallinstanzen (Maestro)

Für wen es ist: Prozessoperatoren, Vorfallsmanager und Prozessinhaber.

Verwenden Sie es, um laufende Fälle mit Lebenszyklus-Steuerelementen (Pause, Resume, Abbrechen, Migrieren) und der vollständigen Prüfung zu betreiben. Beheben Sie Vorfälle, indem Sie fehlgeschlagene Aufgaben wiederholen oder Instanzen zu neueren Fallplanversionen migrieren. Verwenden Sie Live-Einblicke, Heatmaps und Process Mining, um Engpässe zu erkennen und Verbesserungen in das Design einzubauen.

Fall-App (Maestro)

Für wen es ist: Fallmitarbeitende und Fallmanager.

Verwenden Sie sie, um alle Fälle und Falldetails (Zeitleiste, Falldaten, menschliche Aufgaben) anzuzeigen und Schnellaktionen wie Abschließen und Erneut öffnen auszuführen. Die Fall-App ist ein empfohlener, fallzentrierter Arbeitsbereich – Listen, Details, Aufgaben und SLA-Ansichten. Menschliche Aufgabenformulare werden weiterhin mit Aktions-Apps erstellt und von Fallaufgaben referenziert.

Die Fall-App gibt es in zwei Optionen:

Option	Beschreibung	Einsatzbereich
Vorgefertigte Fall-App	Ein vorgefertigter Arbeitsbereich ohne Code, der mit Maestro Case ausgeliefert wird. Listen, Detailansichten, Aufgabeneingang und SLA-Ansichten werden automatisch aus Ihrem Fallplan und Ihrer Entität konfiguriert.	Der Standardwert – verwenden Sie ihn für schnelle Fallvorgänge, ohne Code zu schreiben.
Benutzerdefinierte codierte Fall-App	Eine maßgeschneiderte Fall-App, die Sie mit dem Pro-Code TypeScript SDK erstellen. Ermöglicht das Erstellen benutzerdefinierter Ansichten, Layouts und Workflows über derselben Fall-Runtime.	Wenn Sie eine Benutzeroberfläche benötigen, die über das hinausgeht, was die sofort einsatzbereite App zur Verfügung stellt – gebündelte Arbeitsbereiche, benutzerdefinierte Dashboards oder domain-spezifische Fallerfahrungen.

Hinweis:

Die Fall-App unterscheidet sich von UiPath Apps. Die Fall-App wurde speziell für Fallvorgänge entwickelt. UiPath Apps ist ein universelles Low-Code-Builder für vollständig benutzerdefinierte oder zusammengesetzte Geschäfts-Apps. Verwenden Sie die Fall-App für schnelle Fallvorgänge. Verwenden Sie UiPath Apps, wenn Sie eine maßgeschneiderte Benutzeroberfläche über Fallvorgänge hinaus benötigen.

Kernkonzepte

Es ist wichtig, dass Sie die folgenden Konzepte verstehen, bevor Sie einen Agent-Fall entwerfen.

Fall und Fallschlüssel

Ein Fall stellt eine reale Geschäftssituation dar, die gelöst werden muss – ein Anspruch, ein Streitfall oder eine Untersuchung. Im Gegensatz zu einer herkömmlichen Prozessinstanz entwickelt sich ein Fall im Laufe der Zeit, da 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 Upstream-ID, die bei der Erstellung übergeben wird, damit derselbe reale Fall über mehrere Tools hinweg erkannt wird	CRM-Fallnummer, Policenummer, 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 über Tools hinweg korrelieren können, ohne eine separate Zuordnungstabelle zu pflegen.

Case entity

Die Fallentität [Coming Bald] ist der persistente, typisierte Geschäftsdatensatz in der Mitte jedes Falls. Es ist die einzige Source of Truth, aus der Phasen, Aufgaben und Übergangsbedingungen während des gesamten Lebenszyklus gelesen und in die geschrieben werden.

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

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

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

Sie können die Fallentität auf drei Arten in Maestro Case bringen:

Quelle	Beschreibung	Einsatzbereich
Native Data Fabric-Objekt	Aktivieren Sie den Umschalter für die Fallentität in Ihrem Fallprojekt, das automatisch eine native Data Fabric-Fallentität erstellt und mit Ihrem Fall verknüpft	Neue Prozesse, bei denen Sie das Datenmodell besitzen
System der Aufzeichnung über VDO	Registrieren Sie eine externe Quelle als virtuelles Datenobjekt (VDO) in Data Fabric, aktivieren Sie die Umschalttaste für die Fallentität und stellen Sie eine Beziehung zwischen dem VDO und der Fallentität in Data Fabric her	Entitätsdaten befinden sich in einem externen System und Sie möchten ohne Duplikate darauf verweisen
System der Aufzeichnung über Falltrigger	Vorhandene Daten im Trigger für die Fallerstellung übergeben (z. B. über einen API-Connector); Die Felder werden zu Fallfeldern, die im gesamten Fall verfügbar sind	Einfache Integrationen, bei denen Sie den Fall zum Zeitpunkt der Erstellung hydratisieren

Phasen

Phasen sind die benannten Phasen eines Falls – z. B. Input, Review, Settlement, Closing. Eine Phase ist effektiv eine Sammlung von Aufgaben , die den Fall in Bezug auf die vollständige Bedingung der Phase vorantreiben.

Primäre vs. sekundäre Phasen

Maestro Case unterstützt zwei Arten von Phasen:

Phasenart	Zweck	Wie es erreicht wird	Sichtbarkeit in der Fall-App
Primäre Phase	Der erwartete Ablauf des Falls (z. B. Aufnahme → Überprüfung → Regulierung → Abschluss).	Kann über Kanten aus einer vorherigen Phase auf der Arbeitsfläche oder durch die konfigurierte Eintrittsbedingung eingegeben werden – beide sind gültig.	Angezeigt als Kernphasenknoten in der Fall-App-Zeitleiste – das sind die Phasen, die die Fallbearbeiter als Hauptlebenszyklus sehen.
Sekundäre Phase	Ausnahme oder alternative Pfade, die während des Falls jederzeit auftreten können (z. B. Request Info, Verweigert, Zurückgezogen, Abgebrochen).	Keine eingehenden Edges – das Umschalten einer Phase als sekundäre Edges entfernt sie. Die Phase wird nur erreicht, wenn ihre Eintrittsbedingung „true“ ist, und kann jedes Mal aktiviert werden, wenn dies der Fall ist, unabhängig davon, wo sich der Fall derzeit befindet.	Nicht Teil der Zeitleiste der Kernphase. Werden separat angezeigt, wenn sie aktiv sind (z. B. als Ausnahmepfad-Indikator), da sie jederzeit ausgelöst werden können.

Mit anderen Worten: Das Markieren einer Phase als sekundäre Phase bedeutet: Integrieren Sie mich nicht in den Hauptlebenszyklus – ich aktiviere mich selbst, wenn meine Eintrittsbedingung erfüllt ist. Dadurch kann ein Fall mitten in der Überprüfung in „Anforderungsinformationen“ oder von überall in „Zurückgezogen“ springen, ohne dass der Designer Kanten aus jeder möglichen Quelle ziehen muss.

Phasenattribute

Jede Phase definiert:

• Eintrittsbedingung – wenn diese Phase beginnt.
• Abgeschlossene Bedingung – was muss sein, um die Phase als abgeschlossen zu markieren und fortzufahren.
• Austrittsbedingung – wann die Phase frühzeitig verlassen werden soll (z. B. Bailout- oder Umleitungsszenarien).
• Bedingung für die erneute Eingabe – wie die Nachbearbeitung oder die Rückkehr zum Ursprung hier zurückgeleitet wird.
• Phasen-SLA und Eskalationen – Fälligkeit, Warnschwellenwerte sowie Eskalationsbenachrichtigung und E-Mail-Empfänger.

Phasen können als erforderlich oder optional markiert werden. Ein Fall kann erst abgeschlossen werden, wenn alle erforderlichen Phasen abgeschlossen sind. 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 im selben Fall gleichzeitig aktiv sein. Zum Beispiel kann eine Phase der Kundenkommunikation neben dem Underwriting ausgeführt werden, während sich die Regulierung im Hintergrund vorbereitet. Ob die Phasen parallel oder nacheinander ausgeführt werden, wird durch Eintrittsregeln gesteuert.

Aufgaben

Eine Aufgabe ist eine Arbeitseinheit innerhalb einer Phase.

Aufgabentypen

Maestro Case unterstützt folgende Aufgabentypen:

Aufgabentyp	Beschreibung
Menschliche Aktion	Formulare, Genehmigungen und Klärungen, die einer Person zugewiesen sind
RPA-Workflow	UI-Automatisierung für Legacy-Systeme, Extraktion und Abstimmung
API-Workflow	System-zu-System-Vorgänge über einen Workflow
Connector ausführen	Eine Connector-Aktivität aufrufen (z. B. Benachrichtigung senden, Datensatz im externen System erstellen)
KI-Agent (UiPath)	Autonome Schlussfolgerung mit Daten für entscheidungsbasierte Arbeit
Externer Agent	KI-Agent eines Drittanbieters, der über API aufgerufen wird
Agentischer Prozess von Maestro	Ein mehrstufiger BPMN-Prozess, der als Aufgabe aufgerufen wird
Untergeordneter Fall	Ein weiterer Fall wird als untergeordneter Fall mit eigenem Lebenszyklus generiert
Wait for Timer	Pausieren, bis eine Dauer verstrichen ist oder ein Zieldatum erreicht ist
Auf Connector-Ereignis warten	Pausieren Sie, 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 beginnt:

Ausführungsmodus	Verhalten	Beispiel
Sequenziell	Die Aufgabe wird in einer definierten Reihenfolge innerhalb der Phase ausgeführt. Eine Sequence kann auch parallele Verzweigungen enthalten, die sich verzweigen und vor dem nächsten Schritt wieder zusammengeführt werden.	In einer Underwriting- Phase: Verify income → (Run credit check Pull employment history) → Calculate DTI → Generate decision
Ereignisgesteuert	Die Aufgabe verfügt über eine Eintrittsregel und wird immer dann ausgelöst, wenn das Ereignis die Regel als „true“ ausgewertet – auch wenn sich die Phase mitten im Flow befindet oder die Sequence bereits über diesen Punkt hinausgegangen ist. Er kann mehrmals ausgelöst werden, wenn das Ereignis wiederholt wird.	In einer Anspruchsbearbeitungsphase : Request additional documents wird ausgelöst , wenn eine Verifizierungsaufgabe ein fehlendes Dokument markiert IF Documents.Missing == true – unabhängig davon, wo sich die Phase derzeit in ihrer Sequence befindet
Ad-hoc	Die Aufgabe ist im Fallplan definiert, startet aber nur, wenn ein Benutzer sie zur Runtime manuell auslöst. Ad-hoc-Aufgaben können von jedem oben aufgeführten Aufgabentyp sein.	In einer Kundeneskalationsphase : Escalate to supervisor oder Add fraud review – ausgelöst durch den Fallbearbeiter nach eigenem Ermessen

Mehrere Aufgaben können gleichzeitig in derselben Phase aktiv sein. Sequentielle Verzweigungen können sich in parallele Pfade verteilen und vor dem nächsten Schritt wieder zusammengeführt werden. Ereignisgesteuerte Aufgaben werden unabhängig von der Sequence ausgelöst und häufig parallel zu dem ausgeführt, was sich sonst noch im Gange befindet – einschließlich mehrerer Instanzen derselben ereignisgesteuerten Aufgabe, die gleichzeitig ausgelöst werden, wenn ihr auslösendes Ereignis wiederholt wird. Ad-hoc-Aufgaben können jederzeit neben laufenden Aufgaben gestartet werden.

Nur einmal ausgeführt

Wenn eine Phase erneut eingegeben wird, steuern Sie, welche Aufgaben erneut ausgeführt werden sollen, indem Sie das Flag „ Nur einmal ausführen“ für jede Aufgabe verwenden:

• Nur einmal ausführen = „true“ – die Aufgabe wird bei der erneuten Eingabe übersprungen. Die vorherige Ausgabe wird beibehalten und die Aufgabe wird nicht erneut ausgeführt.
• Nur einmal ausführen = false (Standard) – Die Aufgabe wird zurückgesetzt und jedes Mal erneut ausgeführt, wenn die Phase erneut eingegeben wird, wodurch eine neue Ausgabe erzeugt wird.

Beispiel: In einer Dokumenterfassungsphase ist die Aufgabe Send document checklist to customer als nur einmal ausgeführt markiert – Sie möchten den Kunden nicht jedes Mal erneut E-Mails senden, wenn die Phase aus einem anderen Grund erneut geöffnet wird. Die Aufgabe Validate documents wird mit dem Standardwert belassen, sodass jede neue Übermittlung neu validiert wird.

Andere Aufgabenkonfiguration

Jede Aufgabe unterstützt auch Eingaben und Ausgaben, die der Fallentität zugeordnet sind.

Regeln

Regeln steuern die Lebenszyklusbewegung und sind der Mechanismus, der die Fallverwaltung 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 für den Fall eintritt, nicht nach einem Abrufzeitplan oder einer festen Sequence.

Jede Regel hat drei Teile:

• Wen – das Ereignis, das die Bewertung auslöst. Ereignisse gibt es in zwei Arten:
  • Interne Ereignisse, die vom Falllebenszyklus selbst ausgegeben werden – CaseCreated, StageEntered, StageCompleted, StageExited, TaskCompleted, CaseSlaAtRisk, CaseSlaBreached, StageSlaAtRisk, StageSlaBreached und Änderungen an der Fallentität von Aufgaben zurückgeschriebene Felder.
  • Externe Ereignisse, die von außerhalb des Falls eintreffen – Integration Service-Connector-Ereignisse (Webhooks, Warteschlangennachrichten), Timer-Ausführungen, Vervollständigung oder Beenden eines untergeordneten Falls und direkte API-Aufrufe an den Fall.
• WENN (optional) – die Bedingung für die Fallentität, die auch erfüllt sein muss, damit die Regel wirksam wird. Wenn sie nicht angegeben wird, wird die Regel bei jedem übereinstimmenden WHEN-Ereignis ausgelöst.
• Aktion – was die Regel bewirkt, wenn sie ausgelöst wird (eine Phase starten, eine Phase abschließen, eine Phase beenden, den Fall abschließen usw.).

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

Regeln auf Fallebene

Regel	Zweck	Beispiel
Fall abgeschlossen	Markieren Sie den gesamten Fall als abgeschlossen (Erfolgreiches Ergebnis).	Wenn alle erforderlichen Phasen abgeschlossen werden IF Outcome == "Approved"
Fallaustritt	Beenden Sie den Fall, bevor er die normale Fertigstellung erreicht (Abbruch, Auszahlung, Betrug).	WHEN Application.Status ändert IF Application.Status == "Withdrawn"

Regeln auf Phasenebene

Regel	Zweck	Beispiel
Eintrag	Gateway, wenn die Phase beginnt.	WHEN Application.Submitted Ereignis tritt ein, IF Application.Type == "Mortgage" && Documents.Count > 0
Abgeschlossen	Entscheiden Sie, wann die Phase normal abgeschlossen wird.	WENN eine Aufgabe in der Phase abgeschlossen wird IF alle erforderlichen Aufgaben Done und UnderwritingDecision != nullsind
Beenden	Gehen Sie frühzeitig aus der Phase, auch wenn sie unvollständig ist.	WHEN UnderwritingDecision ändert IF UnderwritingDecision == "Reject"
Erneuter Eintrag	Kehren Sie zu einer zuvor abgeschlossenen Phase für die kontrollierte Nacharbeit zurück.	WHEN Verification.Result ändert IF Verification.Result == "Failed" && DocsComplete == false

Eintrittsregeln enthalten einen Unterbrechungsumschalter , der steuert, was mit anderen aktiven Phasen geschieht, wenn die Eintrittsregel mit „true“ ausgewertet wird:

• Unterbrechend = true – Alle derzeit aktiven Phasen werden automatisch beendet und der Fall wird in die neu eintretende Phase versetzt. Verwenden Sie dies für harten Ausnahmepfade wie „Zurückgezogen“ oder „Be Betrugsspeicher“ , die den Fall sofort übernehmen müssen.
• Unterbrechend = false – Die neue Phase wird zusammen mit allen vorhandenen aktiven Phasen aktiviert. Der Fall kann mehrere Phasen haben, die parallel ausgeführt werden.

Die Standardeinstellungen unterscheiden sich je nach Phasenart: Primäre Phasen sind standardmäßig unterbrechend = false (Parallel beitreten – der normale Arbeitsfortschritt). Sekundäre Phasen sind standardmäßig unterbrechend = true (den Fall übernehmen – da sekundäre Phasen eine Ausnahme oder alternative Pfade darstellen). Beide Standardeinstellungen können pro Phase überschrieben werden.

Abgeschlossen- und Austrittsregeln enthalten auch eine Aktion , die bestimmt, was mit dem Fall nach dem Ende der Phase geschieht:

• Fall abschließen / Fall beenden – den Fall von hier aus fertigstellen oder beenden.
• Warten auf manuelle Auswahl – Halten Sie an und lassen Sie einen Benutzer die nächste Phase auswählen.
• Zurück zur Quelle – Leitet den Fall zurück zu der Phase, in der dieser ursprünglich aktiviert wurde.

Regeln auf Aufgabenebene

Regel	Zweck	Beispiel
Eintrag	Gate, wenn eine Aufgabe innerhalb einer Phase beginnt. Wird von ereignisgesteuerten Aufgaben verwendet, um ein auslösendes Ereignis auszulösen, und optional von sequenziellen oder Ad-hoc-Aufgaben, um die Ausführung zu überwachen.	Wenn eine Verifizierungsaufgabe ein fehlendes Dokument markiert IF Documents.Missing == true

Da Regeln ereignisgesteuert sind, führt der Fall keine feste Abfolge aus – Phasen und Aufgaben werden aktiviert, abgeschlossen, beendet oder erneut geöffnet, wenn ihr WHEN- Ereignis eintrifft und die IF- Bedingung (falls vorhanden) für die aktuelle Fallentität als „true“ ausgewertet wird. Die erneute Ausführung von Aufgaben beim erneuten Eintritt in die Phase wird durch das Flag „ Nur einmal ausführen“ gesteuert, das im obigen Abschnitt Aufgaben beschrieben ist.

Case Manager

Der Fallmanager ist der Orchestrator eines Falls – der Agent, der Lebenszyklusentscheidungen basierend auf Ereignissen trifft. Sie 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 soll.

Es orchestriert mit zwei sich ergänzenden Methoden:

1. Regeln (primär) – Für jeden Entscheidungspunkt bewertet der Fallmanager zuerst die im Fallplan definierten deterministischen CMMN-Regeln. Wenn eine Regel die Entscheidung löst, wird sie getroffen. Dadurch bleiben die Erfolgspfade mit hohem Volumen vorhersehbar, überprüfbar und kostengünstig.
2. Agent (Fallback) – Wenn keine Regel die Situation abdeckt (eine Lücke, eine Ausnahme oder eine Entscheidungsfindung), berücksichtigt der Fallmanager die Fallentität, den Fallplan sowie die verfügbaren Richtlinien und das Wissen, um die nächste Aktion auszuwählen. Auf diese Weise kann ein Fall weiterlaufen, ohne dass es für jede nicht abgedeckte Verzweigung zu einem Menschen eskalieren muss.

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

SLAs und Eskalationen

Definieren Sie SLAs und Eskalationsregeln sowohl auf Fall- als auch auf Phasenebene:

• SLA auf Fallebene – allgemeines Lösungsziel (z. B. Lösung innerhalb von 48 Stunden).
• SLA auf Phasenebene – lokalisierte Fälligkeitszeit (z. B. Überprüfung innerhalb von 24 Stunden).
• SLA-Status – auf Kurs, gefährdet oder verletzt. Diese Status werden als Abzeichen in Falllisten und Detailansichten angezeigt.
• Eskalationen – Regeln, die ausgelöst werden, wenn eine SLA gefährdet oder verletzt wird (z. B. Neuzuweisung, Benachrichtigung des Managements, Erstellen eines Prioritäts-Flags).
• Pause/Fortsetzen – SLA-Timer können angehalten werden, wenn der Fall auf eine externe Eingabe wartet, und fortgesetzt, wenn sie wieder aktiv werden können.

Fallpersonas

Maestro Case erzwingt den phasenbewussten Zugriff über Personen, damit die richtigen Personen zum richtigen Zeitpunkt sehen und handeln:

Eine Fallpersona ist eine Zusammenfassung zur Entwurfszeit, die eine Rolle innerhalb eines Falltyps darstellt (z. B. Input Agent, Sachverständiger, Vorgesetzter). Personas entkoppeln die Zugriffsanforderungen eines Falls von der Identitätsstruktur der Organisation, sodass Falldefinitionen über Organisationen und Mandanten hinweg portierbar sind.

• Zur Entwurfszeit erstellt der Falldesigner Personas und Scopes für jede bestimmte Phase.
• Zur Bereitstellungszeit bindet ein Administrator jede Person an Benutzer oder Benutzergruppen, sodass derselbe Falltyp in verschiedenen Umgebungen unterschiedliche Scopes haben kann.
• Zur Runtime löst das System die Persona(s) des Benutzers auf und erzwingt den Phasen-Scoping entsprechend. Ein Benutzer mit mehreren Personas erhält die Vereinigung von Phasen-Scopes.

Zum Beispiel könnte ein Fall der Kreditbearbeitung Folgendes definieren:

Persona	Anwendung	Überprüfung	Underwriting	Auszahlung
Kreditsexperte	ja
Verifizierungsanalyst		ja
Underwriter			ja
Niederlassungsmanager	ja	ja	ja	ja

Aufgaben innerhalb einer Phase werden einer Person zugewiesen, nicht einem bestimmten Benutzer. Das System löst die Persona in Rollen/Gruppen für Benutzer zur Runtime auf, um die Sichtbarkeit und Zuweisung der Aufgabe zu bestimmen.

Hinweis:

Vollständige Unterstützung für Fallbenutzerrollen und Zugriff in Kürze verfügbar.

Abrechnung und Verbrauchsmaterialien

Maestro Case folgt der gleichen Abrechnung wie Maestro. Arbeit, die innerhalb eines Falls ausgeführt wird, verbraucht die nativen Verbrauchsmaterialien der von Ihnen verwendeten Aufgabentypen: KI-Agents, RPA-Workflows, API-Workflows oder IS-Connectors.

Nächste Schritte

• Erstellen Sie Ihr erstes Maestro Case-Projekt – Ein Schritt-für-Schritt-Tutorial, das das Erstellen, Bereitstellen und Testen eines Schadensfalls für eine Schadensversicherung von Grund auf durchführt.
• Referenz für Kernkonstrukte – Detaillierte Referenz für jedes Maestro-Fallkonstrukt: Fallentität [in Kürze verfügbar] , Phasen, Aufgaben, Übergangsbedingungen, SLAs und Personas.
• Konfigurieren von Phasenübergängen und erneutem Eintritt – Ein Leitfaden zur Modellierung nicht linearer Fallabläufe mit Eintritts-, Austritts- und erneuten Eintrittsbedingungen.