Der Lebenszyklus von Maestro Case: Vom Ereignis-Trigger zum App-Erlebnis

Maestro Case-Lebenszyklus von Ereignis-Triggern über Case-Entitätsdaten, Case-Plan-Regeln, Case Manager-Entscheidungen, Aufgabenausführung bis hin zu Case App-Erfahrungen.

Überblick

Ein Fall ist ein langlebiges Objekt im Geschäft – ein Anspruch, eine Streitigkeit, eine Untersuchung, ein Darlehen –, das jede einzelne Aufgabe oder Sitzung überdauert und sich nichtlinear durch Phasen bewegt, wenn Daten und Entscheidungen anfallen.Maestro Case steuert diesen Lebenszyklus end-to-end: Ein Ereignis erstellt den Fall, ein Case Plan definiert die möglichen Phasen und die Regeln, die die Übergänge regeln, der Case Manager entscheidet über die nächsten Schritte mithilfe einer regelbasierten Orchestrierung mit Fallback auf den Case Manager Agent und die Case App stellt die laufenden Arbeitsvorgänge für Geschäftsanwender bereit.

Dieses Dokument verfolgt Daten über jede Ebene des Stacks – Auslöser → Case Entität[Demnächst verfügbar] → Case Plan → Case Manager → Aufgaben → Laufzeit-Erfahrung – damit Sie ein genaues mentales Modell erstellen können, bevor Sie Ihren ersten Case Plan entwerfen.

Zielgruppe: Mittelstufe bis Fortgeschrittene – Automation Developers Lösungsarchitekten, Business-Architekten

Warum den vollständigen Stack verstehen

Maestro Case ist keine einzelne Funktion. Es handelt sich um ein koordiniertes System von Entwurfszeit-Definitionen (Case Plan, Case Entität [in Kürze verfügbar], Phasen, Aufgaben, Regeln) und Laufzeit-Engines (Case Manager, Case App, Case Instance Management). Das Verständnis des gesamten Lebenszyklus ermöglicht Ihnen Folgendes:

• Das Entwerfen robuster Case Pläne, die die nichtlineare Natur der realen Arbeit berücksichtigen.
• Vermeiden Sie häufige Fallstricke wie starre Phasensequenzierung, unklare Zuständigkeit für Bereiche oder fehlende Wiedereintrittslogik.
• Kommunizieren Sie rollenübergreifend – vom Entwickler, der Phasen in Studio Web modelliert, bis zum Case Mitarbeiter, der Aufgaben in der Case App abschließt.

Architektur auf einen Blick

Der Maestro Case-Stack besteht aus fünf Ebenen. Daten fließen von den Ereignisquellen über die Orchestrierung und Ausführung nach unten und gelangen nach oben in die Benutzererfahrung der Geschäftsbenutzer.

Die folgenden Abschnitte führen durch jede Ebene in der Reihenfolge, in der die Daten fließen.

Layer 1 – Ereignis-Trigger (wie ein Fall beginnt)

Ereignis-Auslöser sind die Einstiegspunkte, die eine Case-Instanz erstellen und die Case-Entität [demnächst verfügbar] mit Erstdaten versorgen. Ein einzelner Case Plan kann mehrere Auslöser definieren, sodass derselbe Falltyp aus verschiedenen Kanälen stammen kann.

Trigger-Quelle	Beschreibung	Beispiel
Data Fabric-Entität	Ein Ereignis „Zeile erstellt“ auf einer Data Fabric-Entität oder einem VDO startet den Fall. Die Entitätsfelder werden zu Fallfeldern.	Eine neue Zeile in einer Home Claims-Entität erstellt einen Sachversicherungsfall.
Auf Connector warten	Ein Integration-Service-Connector-Ereignis (API-Aufruf, Webhook, Nachricht) startet den Fall. Die API-Payload wird als Case-Entität behandelt.	Eine Microsoft Teams-Kanal-Nachricht löst die Phase ,,Zurückgezogen" aus.
Portal / Formular	Ein Benutzer übermittelt Daten über ein Webformular.	Ein Mitarbeiter übermittelt eine Spesenabrechnung über ein Self-Service-Portal.
E-Mail	Eine eingehende E-Mail wird analysiert und ihre Daten werden Entitätsfeldern zugeordnet.	Eine weitergeleitete Empfangsbestätigungs-E-Mail erstellt eine neue Schadensposition.
API	Ein externes System ruft den Endpunkt der Fallerstellung auf.	Ein ERP-System löst einen Schadensfall bei einem Richtlinienereignis aus.
Geplant	Ein zeitbasierter Trigger erstellt Fälle oder verfolgt sie.	Ein täglicher Auftrag erstellt Folgefälle für veraltete Elemente.

Jeder Trigger ordnet seine eingehenden Daten Feldern in der Case Entität zu. Diese anfängliche Zuordnung - manchmal als Hydration bezeichnet - bestimmt die Daten, die für jede nachgelagerte Phase, Aufgabe und Übergangsbedingung verfügbar sind.

Hinweis:

Ein Case Plan kann mehr als einen Trigger haben. Beispielsweise könnte ein Versicherungsfall Übermittlungen von einem Portal, einem E-Mail-Parser und einer Telefonanruf-Transkriptions-API akzeptieren, die alle derselben Entität zugeordnet sind.AutoInsuranceClaim

Layer 2 – die Case Entität (Einzige Informationsquelle)

Die Case Entität [in Kürze verfügbar] ist das persistente, strukturierte Datenobjekt im Zentrum jeder Case-Instanz.Sie bleibt während der gesamten Lebensdauer des Falls bestehen und dient als zentrale Quelle, auf die alle Phasen, Aufgaben und Übergangsbedingungen lesend und schreibend zugreifen.

Einsatzbereite Datenobjekte

Jedes Fallprojekt erstellt automatisch drei Datenobjekte:

Objekt	Zweck
Fallentität	Das zentrale Geschäftsdatenmodell. Enthält strukturierte Daten, die von Bedingungen und Aufgaben verwendet werden.
Falldokumente	Anhänge und Dateien, die mit dem Fall verknüpft sind (Belege, Fotos, Verträge).
Fallkommentare	Hinweise, Anmerkungen und Kommunikation, die von Teilnehmern während des gesamten Lebenszyklus hinzugefügt werden.

Alle drei teilen sich ein unveränderliches caseID-Systemfeld, das bei der Fallerstellung automatisch entsteht und alle Falldaten miteinander verknüpft.

Wie Daten die Entität erreichen

Quelle	Mechanismus
Native in Data Fabric (empfohlen)	Erstellen Sie eine Geschäftsentität in Data Fabric und verknüpfen Sie sie mit dem Fall.
VDO in Data Fabric	Registrieren Sie eine externe Datenquelle als Virtual Data Object und verknüpfen Sie das VDO.
Fall-Trigger-Nutzlast	Übergeben Sie Daten über den Trigger (z. B. einen API-Connector). Die Nutzlastfelder werden zu Fallfeldern.

Warum eine zentrale Entität wichtig ist

• Aufgabenunabhängigkeit – Aufgaben müssen nicht voneinander wissen. Jede Aufgabe greift über Eingabe-/Ausgabezuordnungen lesend oder schreibend auf die Entität zu.
• Orchestrierungskontext – Der Case Manager wertet die Übergangsregeln anhand von Entitätsfeldern aus.Wenn eine Aufgabe adjusterDecision = "approve" in die Entität zurückschreibt, werden nachgelagerte Eintrittsregeln, die auf adjusterDecision verweisen, sofort ausgewertet.
• Prüfungspfad – Jede Änderung an der Entität wird nachverfolgt, einschließlich wer, wann und was geändert wurde.
• Einzige verlässliche Informationsquelle – Es gibt für keinen Teilnehmer und kein System eine Mehrdeutigkeit über den aktuellen Status des Falls.

Das Rückschreibmuster

Das Rückschreibmuster ist der primäre Mechanismus zum Verschieben von Daten durch einen Fall:

1. Eine Aufgabe liest bestimmte Felder aus der Case Entität über die Eingabezuordnung.
2. Die Aufgabe führt ihre Arbeit aus (Validierung, Agentenlogik, menschliche Überprüfung, RPA-Extraktion).
3. Die Aufgabe schreibt ihre Ergebnisse über die Ausgabezuordnung zurück in die Case-Entität.
4. Aktualisierte Entitätswerte bewirken eine erneute Auswertung der Übergangsregeln, was möglicherweise die nächste Phase oder Aufgabe aktiviert.

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

Dieses Muster hält die Aufgaben entkoppelt. Eine Connector-Aufgabe „Validate Policy“ und eine Agent-Aufgabe „Analyze Photos“ kommunizieren nicht direkt.Stattdessen bereichert jede einzelne die Entität, und der Case Manager liest die Entität, um zu entscheiden, was als nächstes passiert.

Hinweis:

Entwerfen Sie Ihr Entitätsschema so, dass jedes Feld von genau einer Aufgabe geschrieben wird.Wenn mehrere Aufgaben in dasselbe Feld schreiben, gewinnt der letzte Schreiber und frühere Daten gehen verloren. Verwenden Sie Felder im Namensbereich (z. B. validation.result vs. categorization.result), um Kollisionen zu vermeiden.

Layer 3 – der Case Plan (Entwurfszeitplan)

Der Case Plan ist der visuelle Bauplan, den Sie in Studio Web erstellen.Er definiert die möglichen Phasen, die ein Fall durchlaufen kann, und die Regeln, die die Übergänge regeln.Im Gegensatz zu einem linearen Workflow schreibt ein Case Plan nicht einen einzelnen festen Pfad vor. Der tatsächliche Pfad wird zur Laufzeit basierend auf Daten und Entscheidungen bestimmt.

Ein Case Plan besteht aus vier Elementen:

• Ereignis-Trigger – die Ereignisse, die eine Case-Instanz erstellen oder beeinflussen (in Layer 1 beschrieben).
• Phasen – die benannten Phasen des Falls.
• Aufgaben – die Arbeitselemente in jeder Phase.
• Regeln – die WHEN/IF/Aktion-Definitionen, die den Eintritt, Abschluss, Austritt und Wiedereintritt von Phasen und Aufgaben regeln.

Phasen

Phasen sind die Hauptphasen, die ein Fall durchläuft – z. B. Aufnahme, Überprüfung, Abrechnung, Abschluss. Eine Phase ist im Grunde eine Sammlung von Aufgaben, die den Fall zur Abschlussregel der Phase voranbringen. 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 Eintrittsregel erreicht werden.	Werden als Kernphasenknoten in der Zeitleiste der Case App angezeigt – der Hauptlebenszyklus, den Case-Mitarbeiter sehen.
Sekundäre Phase	Ausnahme oder alternative Pfade, die jederzeit auftreten können (z. B. Ausstehend beim Kunden, Abgelehnt, Zurückgezogen).	Keine eingehenden Kanten – das Umschalten auf sekundär entfernt sie. Wird nur erreicht, wenn ihre Eintrittsregel als „true“ ausgewertet wird, und kann zu jedem Zeitpunkt im Fall aktiviert werden.	Wird separat angezeigt, wenn aktiv (nicht Teil der Kernzeitleiste).

Jede Phase definiert:

• Eintrittsregel – wenn die Phase aktiviert wird. Enthält ein unterbrechendes Umschalten, das das Übernahmeverhalten steuert.Standard: primäre Phasen = false (parallel); sekundäre Phasen = true (Übernahme).
• Abschlussregel – das normale Fertigstellen (z. B. wenn die erforderlichen Aufgaben abgeschlossen sind).Führt eine Aktion aus (Fall abschließen/verlassen, auf manuelle Auswahl warten, zum Ursprung zurückkehren).
• Austrittsregel – ein vorzeitiger Abbruch, wenn die Fortsetzung der Verarbeitung sinnlos ist.Enthält die gleichen Aktionsoptionen wie die komplette Regel.
• Wiedereintrittsregel – Wie die Nacharbeit den Fall zu einer zuvor abgeschlossenen Phase zurückgibt.
• Phasen-SLA und Eskalationen – Fälligkeitszeit, Warn-Schwellenwerte und Eskalationsempfänger.

Phasen können als erforderlich oder optional markiert sein. Ein Fall kann erst geschlossen werden, wenn alle erforderlichen Phasen abgeschlossen sind. Optionale Phasen werden nur aktiviert, wenn ihre Eintrittsregeln erfüllt sind, und der Fall kann ohne sie geschlossen werden.

Mehrere Phasen können gleichzeitig im selben Fall aktiv sein. Ob Phasen parallel oder nacheinander ausgeführt werden, wird über die Eintrittsregeln und deren unterbrechendes Umschalten gesteuert.

Aufgaben

Eine Aufgabe ist eine eigenständige Arbeitseinheit in einer Phase. Jede Aufgabe hat einen Typ, der bestimmt, wie die Arbeit ausgeführt wird:

Aufgabentyp	Was es tut
Menschliche Aktion	Präsentiert einer Person in der Case App ein Formular, eine Genehmigung oder eine Überprüfung.
KI-Agent (UiPath)	Ruft einen UiPath-KI-Agenten für autonomes Denken über Daten auf.
Externer Agent	Ruft einen KI-Agenten eines Drittanbieters außerhalb von UiPath auf (z. B. über die API).
RPA-Workflow	Löst einen UiPath-Roboter für die UI-Automatisierung in Altsystemen aus.
API-Workflow	Ruft ein externes System über eine benutzerdefinierte API-Anforderung auf.
Connector ausführen	Ruft ein externes System über einen vorgefertigten oder benutzerdefinierten Integrations-Service-Connector auf.
Agentischer Maestro Prozess	Ruft ein Maestro BPMN als Aufgabe mit eigener Orchestrierung auf und gibt ein Ergebnis an den übergeordneten Fall zurück.
Untergeordneter Fall	Generiert eine separate Falldefinition als untergeordnete, die über caseID mit der übergeordneten verknüpft ist.
Warten auf Timer	Pausiert, bis eine Dauer abgelaufen oder ein Zieldatum erreicht ist.
Auf Connector-Ereignis warten	Pausiert, bis ein externes Ereignis über einen Connector eintrifft.

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

• Sequenziell – Die Aufgabe wird in einer definierten Reihenfolge in der Phase ausgeführt. Sequenzen können parallele Verzweigungen enthalten, die auffächern und erneut verbunden werden.
• Ereignisgesteuert – Die Aufgabe hat eine Eintrittsregel und wird ausgelöst, wenn das Ereignis dazu führt, dass die Regel als wahr ausgewertet wird.Kann mehrmals ausgelöst werden, wenn das Ereignis wiederholt auftritt.
• Ad-hoc – Die Aufgabe ist im Case Plan definiert, startet aber nur, wenn ein Benutzer sie zur Laufzeit manuell auslöst.

Mehrere Aufgaben können gleichzeitig in derselben Phase aktiv sein – sequenzielle parallele Verzweigungen, ereignisgesteuerte Aufgaben, die unabhängig von der Sequenz ausgelöst werden, und Ad-hoc-Aufgaben, die neben laufenden Arbeiten gestartet werden.

Jede Aufgabe ist konfiguriert mit:

• Eingaben / Ausgaben – zugeordnet zu und von der Case-Entität [Demnächst verfügbar] .
• Erforderliches Kennzeichen – Legt fest, ob die übergeordnete Phase auf diese Aufgabe warten muss.
• Eintrittsregel – erforderlich für ereignisgesteuerte Aufgaben; optional für sequenzielle und Ad-hoc-Aufgaben (wo sie als Wächter dient).
• Nur einmal ausführen – wenn true, wird die Aufgabe beim Wiedereintritt in die Phase übersprungen und ihre vorherige Ausgabe beibehalten; wenn false (Standard) wird die Aufgabe bei jedem Wiedereintritt erneut ausgeführt, was eine neue Ausgabe erzeugt.
• Zuweisung und SLA – für menschliche Aktionen, wer die Arbeit ausführen soll und wann sie fällig ist.

Regeln

Regeln sind der Mechanismus, der die Bewegung im Lebenszyklus steuert. Sie folgen dem CMMN-Muster (Case Management Modell und Notation) und sind ereignisgesteuert – eine Regel wird nur ausgelöst, wenn ein relevantes Ereignis im Fall auftritt. 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 Case-Entitätsfeldern, die von Aufgaben geschrieben wurden.
  • 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) – eine Bedingung über 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 beschränken sich auf eine von drei Ebenen:

Umfang	Regeltypen	Zweck
Fall	Fall abgeschlossen, Fallaustritt	Den Fall fertigstellen oder beenden.
Phase	Eintritt, Abschluss, Austritt, Wiedereintritt	Die Phasenaktivierung, den normalen Abschluss, den vorzeitigen Abbruch und die Nacharbeit steuern.Phaseneintrittsregeln haben einen Unterbrechungs-Umschalter; Abschluss- und Austrittsregeln haben eine Aktion (Fall abschließen/verlassen, auf manuelle Auswahl warten, Zurück zum Ursprung).
Aufgabe	Eintrag	Prüfpunkt, wenn eine Aufgabe gestartet wird. 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.

Die Unterscheidung zwischen Austritt und Abschließen auf Phasenebene ist wichtig. Eine Abschlussregel wird ausgelöst, wenn die Arbeit normal abgeschlossen wird. Eine Austrittsregel wird ausgelöst, wenn eine Änderung der Daten die weitere Verarbeitung unnötig macht. Sie wirkt als Trennschalter.Beides führt dazu, dass der Case Manager die Aktion der Regel anwendet und beurteilt, was als Nächstes passiert.

Layer 4 – der Case Manager (Laufzeit-Orchestrierung)

Der Case Manager ist der ereignisgesteuerte Orchestrator jedes Falls.Er steuert Lebenszyklusentscheidungen – welche Phase als nächstes aktiviert werden soll, welche Aufgaben gestartet werden sollen, wann eine Phase abgeschlossen oder frühzeitig verlassen werden soll und wann eskaliert wird – basierend auf Ereignissen, die beim Fall eintreffen.

Er orchestriert mit zwei komplementären Methoden:

1. Regeln (primär) – Deterministische CMMN-Regeln, die im Case Plan definiert sind. Für jeden Entscheidungspunkt wertet der Case Manager zuerst die anwendbaren Regeln aus.Wenn eine Regel die Entscheidung löst, wird sie übernommen. Dadurch bleiben die Standardabläufe mit hohem Volumen vorhersehbar, prüfbar und kostengünstig.
2. Agent-Argumentation (Fallback) – Wenn keine Regel die Situation abdeckt (eine Lücke, eine Ausnahme oder eine Ermessensentscheidung), analysiert der Case Manager-Agent die Case-Entität, den Case-Plan und die konfigurierten Richtlinien, um die nächste Aktion auszuwählen.Dadurch können Fälle weiterentwickelt werden, ohne dass sie für jede nicht abgedeckte Verzweigung zu einem Menschen eskaliert werden.

Wie der Case Manager ein Ereignis verarbeitet

Die folgende Sequenz wird während der gesamten Lebensdauer des Falls wiederholt:

1. Ereignis empfangen – Ein Trigger wird ausgelöst, eine Aufgabe wird abgeschlossen, ein Case-Entitätsfeld ändert sich, ein Timer- oder Connector-Ereignis kommt an oder ein Phasenübergang findet statt.
2. Regelauswertung – Der Case Manager wertet alle anwendbaren Regeln auf Fall-, Phasen- und Aufgabenebene aus, deren WHEN mit dem Ereignis übereinstimmt und deren IF-Bedingung (falls vorhanden) zutrifft. Passende Regel-Aktionen werden angewendet (eine Phase aktivieren, eine Phase abschließen, eine Phase verlassen usw.).
3. Agent-Fallback – für Entscheidungen, die nicht von einer deterministischen Regel abgedeckt werden, analysiert der Case Manager-Agent den Fallstatus und die Richtlinien, um die nächste Aktion auszuwählen.
4. Statusaktualisierung – Übergang von Phasen und Aufgaben; die Case Entität wird aktualisiert; neue Ereignisse können ausgegeben werden, die den nächsten Zyklus auslösen.
5. Fallabschluss – Wenn eine Fallabschluss- oder Fallaustritt-Regel auf Fallebene ausgelöst wird (oder der Agent entscheidet, dass der Fall abgeschlossen ist), wird der Fall geschlossen.

Regeln und der Agent arbeiten zusammen

Regeln decken das Vorhersehbare ab: „Wenn der Schadensregulierer genehmigt und der Betrag unter 50.000 USD liegt, geben Sie ,Abrechnung' ein.“ Der Agent deckt das Unvorhersehbare ab: ein fehlendes Dokument ohne klaren Richtlinienpfad, ein Grenzfall-Betrugsmuster oder eine ungewöhnliche Kombination von Bedingungen. Der Case Manager versucht immer zuerst die Regeln und greift nur dann auf den Agenten zurück, wenn die Regeln nicht übereinstimmen.

Konfiguration des Case Manager-Agenten

Der Case Manager-Agent ist konfiguriert mit:

• Einem Modell (das LLM, das den Agenten unterstützt).
• Einem Benutzer-Prompt (Richtlinien, Einschränkungen und Verhaltensanweisungen).
• Tools (Aktionen, die der Agent ausführen kann, z. B. das Verschieben einer Phase, Eskalieren oder Aktualisieren der Entität).
• Kontext (automatisch aus dem Ausführungsverlauf, den Aufgabenergebnissen und Entitätsänderungen kumuliert).
• Eine Eskalationsrichtlinie (Bedingungen, unter denen der Agent zu einem Menschen eskaliert, anstatt autonom zu handeln).

Hinweis:

Wenn weder die Regeln noch der Case Manager-Agent eine Entscheidung herbeiführen können – aufgrund mehrdeutiger Daten, widersprüchlicher Richtlinien oder eines Szenarios außerhalb der Zuständigkeit des Agenten – eskaliert der Case Manager über die konfigurierte Persona zu einem Menschen.

Layer 5 – das Laufzeit-Erlebnis

Zur Laufzeit stellen zwei Schnittstellen Falldaten und Steuerelemente für verschiedene Zielgruppen bereit.

Case App (für Geschäftsbenutzer)

Die Case App ist der WorkSpace für Geschäftsbenutzer, in dem Fallbearbeiter und Case Manager mit Live-Case-Instanzen interagieren. Es wird angezeigt:

• Die Fallliste – Eine filterbare Ansicht aller Case-Instanzen mit Status, Priorität und SLA-Indikatoren (im Zeitplan, gefährdet, Verstoß).
• Falldetailansicht – Die aktuelle Phase, Case-Entitätsdaten, Aufgabenstatus, die Zeitleiste der Ereignisse und der vollständige Prüfungspfad.
• Aufgabenposteingang (Meine Arbeit) – Ausstehende menschliche Aufgaben, die eine Aktion erfordern: Formulare, Genehmigungen, Überprüfungen.
• Schnelle Aktionen – Kontextbezogene Aktionen basierend auf der Rolle und der aktuellen Phase: Abschließen, erneut öffnen, neu zuweisen, eskalieren, Notizen hinzufügen.

Die Case App gibt es in zwei Optionen: eine einsatzbereite Case App (ein vorgefertigter No-Code-WorkSpace, der mit Maestro Case ausgeliefert wird) und eine benutzerdefinierte Case App (die mit dem Pro-Code-TypeScript SDK für maßgeschneiderte Ansichten und Arbeitsabläufe erstellt wurde). Die einsatzbereite App ist zur Entwurfszeit konfigurierbar – Wählen Sie in Studio Web in den Maestro-Falleinstellungen die Option Case App konfigurieren, um den Falltitel und das Layout der Falldetails zu definieren.

Eine einzelne Case Plan-Definition generiert eine Case App, die Tausende von einzelnen Case-Instanzen verarbeitet, jede zu einem anderen Punkt in ihrem Lebenszyklus.

Case-Instanz-Management (für Operatoren)

Case-Instanz Management ist die Betriebskonsole in Maestro, in der Prozessbearbeiter den Status aller laufenden Fälle überwachen und eingreifen, wenn Probleme auftreten.

Operator-Aktion	Beschreibung
Pause	Einen laufenden Fall vorübergehend anhalten. SLA-Timer werden angehalten. Keine Aufgaben werden aktiviert, bis sie fortgesetzt werden.
Fortsetzen	Starten Sie einen angehaltenen Fall neu. SLA-Timer werden dort fortgesetzt, wo sie aufgehört haben.
Abbrechen	Einen Fall dauerhaft beenden. Alle laufenden Aufgaben werden angehalten.
Migrieren	Verschieben Sie nach einer Korrektur oder Aktualisierung eine Live-Case-Instanz zu einer neueren Version des Case Plans, um den aktuellen Status und die Daten zu behalten.
Wiederholen	Führen Sie eine fehlgeschlagene Aufgabe oder einen fehlgeschalgenen Übergang erneut aus, um vorübergehende Fehler zu beheben.

Wenn ein Fall in einen Error-Status eintritt – eine Aufgabe fehlschlägt, eine Integration das Zeitlimit überschreitet oder der Fall hängen bleibt – wird dies zu einem Fallvorfall. Operatoren verwenden die Instanzverwaltungskonsole, um Vorfälle mit den oben genannten Aktionen zu diagnostizieren und zu beheben.

Hinweis:

• Die Case App ist für Geschäftsbenutzer (Fallbearbeiter, Manager) gedacht, die an einzelnen Fällen arbeiten.
• Das Case-Instanz-Management ist für Prozessbetreiber gedacht, die den Systemstatus überwachen und eingreifen, wenn etwas schief geht.

End-to-End-Verfolgung von Daten: ein Walkthrough

Um den Lebenszyklus zu konkretisieren, ziehen Sie einen Sachversicherungsfall in Betracht:

1. Ereignis-Trigger wird ausgelöst.Eine neue Zeile wird in einer Data Fabric-Entität für Wohnbereich-Schadensfälle erstellt. Der Trigger ordnet Entitätsfelder (Policennummer, Name des Anspruchsberechtigten, Schadensbeschreibung) der Case-Entität zu [Demnächst verfügbar] und erstellt eine Fallinstanz mit SchlüsselHO-1234.

2. Der Case Manager aktiviert die erste Phase.Die Eintrittsregel für die Aufnahme wird zu true (WHEN CaseCreated das Ereignis eintrifft). Die Phase wird aktiv.

3. Aufgaben werden in der Aufnahme ausgeführt. Eine Extraktionsaufgabe (KI-Agent) verarbeitet Anspruchsdetails.Eine Nachschlageaufgabe (Connector ausführen) überprüft die Richtlinie. Ein Anomalie-Erkennungs-Agent überprüft historische Ansprüche. Jede Aufgabe schreibt Ergebnisse zurück in die Case-Entität.

4. Die Aufnahme ist abgeschlossen, die Überprüfung wird aktiviert. Wenn alle erforderlichen Aufnahmeaufgaben fertig gestellt sind und validationPassed == true, wird die Aufnahme-Abschlussregel ausgelöst. Der Case Manager wertet die Eintrittsregeln für die nächsten Phasen aus und aktiviert die Überprüfung.

5. Überprüfungsaufgaben werden ausgeführt. Ein Deckungsprüfungs-Connector, eine menschliche Schadensprüfungs-Verifizierungsaufgabe und ein Auditor-Agent erzeugen Ausgaben. Der Schadensbeauftragte schreibt decision = "Approve" in die Entität zurück.

6. Bedingtes Routing bei der Überprüfung. Die Regeln zum Abschließen und Beenden der Überprüfung werten das Feld decision aus. Wenn "Approve", wird die Abschlussregel ausgelöst und der Fall wird zur Abrechnung verschoben. Wenn "Reject", wird die Austrittsregel ausgelöst und leitet den Fall in die sekundäre Phase Abgelehnt weiter. Wenn "Claim is missing key incident reports", sendet die Wiedereintrittsregel den Fall an die Aufnahme zurück, wobei nur die Aufgaben erneut ausgeführt werden, deren runOnlyOnce false ist (zum Beispiel der Vorfallberichte-Roboter und der Anomalie-Agent).

7. Abrechnungsaufgaben werden ausgeführt. Ein Abwicklungsprozess, ein Abrechnungsprozess und ein Kommunikations-Agent übernehmen Auszahlungen und Benachrichtigungen. Jeder schreibt in die Entität zurück.

8. Fall wird geschlossen. Wenn alle erforderlichen Phasen abgeschlossen sind, erreicht der Fall einen Endstatus. Der vollständige Prüfungspfad – jede Aufgabenausführung, jede Entitätsänderung, jede Entscheidung und jeder Zeitstempel – wird beibehalten.

9. Während des gesamten Lebenszyklus sieht ein Fallbearbeiter die zugewiesenen Aufgaben im Posteingang „Meine Arbeit“ der Case App. Ein Case Manager überwacht das Portfolio, weist Aufgaben neu zu und wickelt Eskalationen ab. Ein Operator überwacht Vorfälle in der Konsole des Case-Instanz-Managements.

SLAs und Eskalationen während des gesamten Lebenszyklus

SLAs fügen dem Lebenszyklus eine Zeitdimension hinzu:

SLA-Ebene	Umfang	Beispiel
SLA auf Fallebene	Gesamtziel von der Erstellung bis zum Abschluss.	Innerhalb von 48 Stunden beheben.
SLA auf Phasenebene	Lokalisierte Fälligkeitszeit für eine bestimmte Phase.	Überprüfung innerhalb von 24 Stunden abschließen.

SLA-Status – im Zeitplan, gefährdet und Verstoß – werden als Abzeichen in den Listen- und Detailansichten der Case App angezeigt. Eskalationsregeln lösen automatisch aus:

• Gefährdet – SLA nähert sich seinem Limit.Benachrichtigen Sie den Fallbesitzer und den Vorgesetzten.
• Verstoß – SLA wird überschritten.Einem leitenden Mitarbeiter neu zuweisen oder an das Management eskalieren.
• Pause / Resume — SLA timers are not paused automatically. A case waiting on external input keeps accruing SLA time until an operator pauses the case instance explicitly.

Benutzerrollen im Lebenszyklus

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

Rolle	Verantwortung
Fallbearbeiter	Schließt menschliche Aufgaben ab und aktualisiert zulässige Felder in Phasen, auf die er Zugriff hat.Zugewiesene Arbeit wird in „Meine Arbeit“ angezeigt.
Case Manager	Überwacht ein Portfolio. Kann neu zuweisen, eskalieren und (gemäß Richtlinie) erneut öffnen.Kann Aktionen auf Phasenebene wie Anhalten und Fortsetzen ausführen.

Für jede Phase definiert der Case Plan, welche Personas betrachten und welche handeln können (Aufgaben abschließen, neu zuweisen, eskalieren, anhalten). Aufgaben erben Phaseneinstellungen, können jedoch die Zuweisungsempfänger weiter einschränken.

Hinweis:

Vollständige Benutzerrollen und Zugriffssteuerungen auf Phasenebene sind noch nicht verfügbar.

Wesentliche Architekturprinzipien

Prinzip	Erklärung
Zuerst der Agent	KI-Agenten sind erstklassige Teilnehmer – sowohl als Aufgaben-Bearbeiter in Phasen als auch als Case Manager-Agent, der den gesamten Fall orchestriert. Menschen greifen nur ein, wenn die Richtlinie oder das Urteilsvermögen es erfordert.
Nicht-linear konzipiert	Wiedereintrittsregeln, sekundäre Phasen, ereignisgesteuerte Aufgaben und Ad-hoc-Aufgaben ermöglichen es Fällen, dem Pfad zu folgen, den die Daten vorschreiben – keine starre Sequenz.
Entitätszentriert	Die Case Entität [Demnächst verfügbar] ist die einzige verlässliche Informationsquelle.Aufgaben sind entkoppelte Produzenten und Verbraucher von Entitätsdaten.
Zuerst die Regeln, dann der Agent	Deterministische CMMN-Regeln behandeln die Standardabläufe mit hohem Volumen. Der Case Manager-Agent behandelt Ausnahmen und Mehrdeutigkeit – und eskaliert zu Menschen, wenn weder die Regeln noch der Agent entscheiden können.
Trennung von Design- und Laufzeit	Der Case Plan ist das, was Sie in Studio Web entwerfen. Geschäftsbenutzer und Operator verwenden die Case App und die Instanzverwaltungskonsole jeden Tag. Ein einziger Case Plan dient Tausenden von Fallinstanzen.

Zugehörige Ressourcen

• Kernkonzepte in Maestro Case – Referenzdefinitionen für Fallschlüssel, Entitäten, Phasen, Aufgaben, Regeln und SLAs.
• Case Plan-Designer-Übersicht – So modellieren Sie Case Plans in Studio Web.
• Konfigurieren von Phasenregeln – Detaillierte Anleitung zu Eintritts-, Abschluss-, Austritts- und Wiedereintrittsregeln.
• Case App-Übersicht – Was Geschäftsbenutzer sehen und wie das Layout der Case App konfiguriert wird.
• Case-Instanz-Management – Operator-Aktionen für Überwachung, Vorfallbehebung und Live-Migration.