Wörterbuch für die Fallverwaltungskomponente von Maestro

	Case Management	BPMN-Prozess
Inhalt gilt für	✅	❌

Überblick

Dieses Referenzdokument enthält eine sachliche Aufschlüsselung aller Komponenten in Maestro Case Management. Verwenden Sie es als Wörterbuch, um zu verstehen, was jedes Konstrukt ist, welche Eigenschaften es verfügbar macht und wie es sich auf andere Konstrukte bezieht. Eine Schritt-für-Schritt-Anleitung zum Erstellen eines Falls finden Sie im Tutorial zur Fallverwaltung.

Zielgruppe: Fortgeschrittene bis Fortgeschrittene – Automation Developers, Lösungsarchitekt, technische Leads.

Produktstatus: Vorschau.

Wie sich Konstrukte beziehen

Die folgende Hierarchie zeigt, wie die Konstrukte von Maestro Case Management zur Entwurfsphase und zur Runtime zusammengehören.

Case (runtime instance, identified by Case Key)

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

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

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

---

Fallschlüssel

Der Fallschlüssel identifiziert eine Fallinstanz über Maestro und externe Systeme hinweg eindeutig.

Tastentyp	Beschreibung	Beispiel
Systemschlüssel	Automatisch von Maestro bei der Fallerstellung generiert. Verwendet ein konfigurierbares konstantes Präfix.	HC-1234, CLM-00891
Externer (kundenseitig definierter) Schlüssel	Eine Upstream-ID, die bei der Fallerstellung übergeben wird, damit derselbe reale Fall über Tools hinweg erkannt wird.	CRM-Fallnummer, Policenummer, ERP-Auftrags-ID

Konfigurieren Sie den Fallschlüssel, wenn Sie den Falltyp in Studio Web erstellen. Wählen Sie Konstanter Präfixschlüssel aus und geben Sie eine Präfixzeichenfolge an (z. B. HO-). Maestro fügt einen automatisch inkrementierten Bezeichner an.

Verwenden Sie einen externen Schlüssel, wenn der Fall aus einem anderen System (CRM, ERP, Ticketing-Tool) stammt und Menschen oder Integrationen den Fall über Tools hinweg korrelieren müssen, ohne eine separate Zuordnungstabelle zu pflegen.

---

Phasen

Eine Phase ist eine benannte Phase im Falllebenszyklus (z. B. Ingestion, Überprüfung, Regulierung). Phasen sind die Spalten auf der Arbeitsfläche des Fallplans, die jeweils verwandte Aufgaben gruppieren, die während dieser Phase ausgeführt werden.

Phasentypen

Maestro unterstützt zwei Kategorien von Phasen:

Typ	Beschreibung	Beispiel
Primäre Phase	Stellt den Erfolg eines Falls dar.	Aufnahme, Prüfung, Regulierung, Abschluss
Sekundäre Phase	Stellt Ausnahmepfade dar, die vom primären Flow abzweigen. Kann zum Ursprung zurückkehren oder Terminal sein.	Ausstehend beim Kunden, Verweigert, Zurückgezogen

Phaseneigenschaften

Eigenschaften	Beschreibung
name	Anzeigename (z. B. „Eingereicht“, „Manager-Überprüfung“).
required	Ob der Fall diese Phase durchlaufen muss , um abgeschlossen zu werden. Wenn true und die Eintrittsregel nie „true“ ist, wird der Fall blockiert. Bei false kann der Fall abgeschlossen werden, auch wenn diese Phase nie eingegeben wurde.
entryRule	Bedingung, die „true“ sein muss, damit diese Phase aktiviert wird.
completeRule	Bedingung, die bestimmt, wann diese Phase abgeschlossen ist. Oft „wenn alle erforderlichen Aufgaben erledigt sind“.
exitRule	Bedingung für früher Austritt. Wenn sie erfüllt ist, wird die Phase sofort beendet, auch wenn die vollständige Regel nicht erfüllt wurde.
reentryCondition	Bedingung, die es einem Fall ermöglicht, in diese Phase zur Nachbearbeitung zurückzukehren.
autoComplete	Phase automatisch als abgeschlossen markieren, wenn alle erforderlichen Aufgaben abgeschlossen sind.
runOnReentry	Steuert, ob die Phase zurückgesetzt und erneut ausgeführt wird, wenn sie nach dem vorherigen Abschluss erneut eingegeben wird. Standard: false.
sla	Zeitlimit für den Phasenabschluss (Werktage oder Kalendertage).

Erforderliche vs. optionale Phasen

	Erforderliche Phase	Optionale Phase
Fallabschluss	Der Fall kann erst abgeschlossen werden, wenn diese Phase abgeschlossen ist.	Der Fall kann abgeschlossen werden, auch wenn diese Phase nie eingegeben wurde.
Einsatzbereich	Kernphasen, die jeder Fall durchlaufen muss (z. B. „Eingereicht“, „Zahlung“).	Bedingte Phasen, die nur manchmal angewendet werden (z. B. „VP-Überprüfung“ für hochwertige Fälle).
Verhalten, wenn die Eintrittsregel nie „true“ ist	Fallblöcke.	Der Fall überspringt die Phase.

Austrittsverhalten der sekundären Phase

Verhalten	Beschreibung	Beispiel
Zurück zum Ursprung	Wenn alle Aufgaben in der sekundären Phase abgeschlossen sind, wird der Fall an die Phase zurückgeleitet, die ihn gesendet hat.	Die Phase „Mit Kunde ausstehend“ endet wieder bei „Überprüfung“ , nachdem Dokumente empfangen wurden.
Terminal	Wenn alle Aufgaben in der sekundären Phase abgeschlossen sind, wird der Fall beendet.	Eine verweigerte Phase schließt den Fall nach dem Senden eines Ablehnungspakets.
Connector-gesteuerter Eintrag	Die sekundäre Phase wird aktiviert, wenn ein externes Connector-Ereignis eintrifft, unabhängig von der primären Phase, die sich der Fall befindet.	Eine Zurückgezogene Phase tritt automatisch ein, wenn eine Microsoft Teams-Kanalnachricht gepostet wird.

Verhalten bei der erneuten Eingabe (Phasen)

runOnReentry	Verhalten	Use case
true	Phase wird auf Active zurückgesetzt. Alle Aufgaben werden neu ausgewertet – erforderliche Aufgaben mit runOnReentry: true erneuter Ausführung.	Korrekturschleife: Die Phase „Eingereicht“ muss nach der Ablehnung erneut validiert werden.
false (Standard)	Die Phase bleibt Abgeschlossen. Erneuter Eintrag ist ein No-OP. Frühere Ergebnisse werden beibehalten.	Einmalige Phasen, die nur einmal ausgeführt werden sollen (z. B. „Erste Aufnahme“).

---

Aufgabentypen

Eine Aufgabe ist eine separate Arbeitseinheit innerhalb einer Phase. Aufgaben sind die atomaren Bausteine der Fallverarbeitung.

Unterstützte Aufgabentypen

Aufgabentyp	Beschreibung	Beispiel für die Verwendung
Mensch (Aktion)	Wird einer Person über eine Persona zugewiesen. Öffnet ein Formular oder Arbeitselement in der Warteschlange der Fall-App. Der Mensch überprüft, trifft eine Entscheidung und übermittelt sie.	Genehmigung durch den Manager, Überprüfung durch den Sachverständigen, Freigabe durch Finanzen.
Agent(UiPath)	Ein UiPath KI-Agent führt autonome Schlussfolgerungen über Daten durch. Nützlich für entscheidungsbasiertes Arbeiten.	Kategorisieren Sie Ausgaben, kennzeichnen Sie Anomalien, verfassen Sie eine Kundenantwort.
Externer Agent	Ruft einen KI-Agent eines Drittanbieters außerhalb von UiPath auf (z. B. über A2A-Protokoll oder API). Ermöglicht die Orchestrierung von Agents mit mehreren Anbietern.	Einen externen Compliance-Agent über ein Partnersystem aufrufen.
RPA-Workflow	Löst einen UiPath-Roboter aus, um eine UI-Automatisierung in Legacy-Systemen durchzuführen, in denen keine API vorhanden ist.	Verarbeiten Sie eine Erstattung in einem älteren Gehaltsabrechnungssystem, geben Sie Daten in einen Mainframe ein.
Connector (Integration Services)	Ruft ein externes System über einen vorgefertigten oder benutzerdefinierten Connector auf. Wird synchron oder asynchron mit Rückruf ausgeführt.	Suchen Sie Richtliniendetails in Salesforce und führen Sie eine Bonitätsprüfung durch.
API-Workflow	Ruft ein externes System über eine benutzerdefinierte API-Anforderung auf. Wird synchron oder asynchron mit Rückruf ausgeführt.	Rufen Sie die Planungssoftware auf, um verfügbare Slots zu erhalten und ein neues Ticket zu erstellen.
Agentischer Prozess von Maestro	Ruft einen agentischen Maestro-Prozess (BPMN-basiert) als Aufgabe auf. Der Prozess wird mit seiner eigenen Orchestrierung ausgeführt und gibt ein Ergebnis zurück.	Mehrstufiger Prüfungsworkflow mit eigener Agentenlogik.
Fallverwaltung (Untergeordneter Fall)	Erstellt eine andere Falldefinition als untergeordneten Fall. Das untergeordnete Element hat seinen eigenen Lebenszyklus, Phasen und Aufgaben, die über caseID mit dem übergeordneten Element verknüpft sind.	Ein Anspruchsfall generiert einen untergeordneten Betrugsuntersuchungsfall.
Wait for Timer	Unterbricht die Ausführung, bis eine bestimmte Dauer verstreicht oder ein Zieldatum/-uhrzeit erreicht ist.	Warten Sie 48 Stunden, bevor Sie eine Folgenachricht senden.
Auf Connector-Ereignis warten	Pausiert die Ausführung, bis ein externes Ereignis über einen Connector (Webhook, Nachrichtenwarteschlange, Systemrückruf) eintrifft.	Warten Sie auf eine Zahlungsbestätigung vom Banksystem.

Ad-hoc-Aufgaben

Ad-hoc-Aufgaben werden zur Runtime von einem menschlichen Benutzer erstellt, wenn eine ungeplante Aufgabe benötigt wird, die nicht Teil des ursprünglichen Fallplans ist. Beispiel: Ein menschlicher Fallbearbeiter fügt während der Untersuchung die Aufgabe „Zusätzliche Dokumentation anfordern“ hinzu.

Aufgabeneigenschaften

Eigenschaften	Beschreibung
name	Anzeigename.
type	Einer von: human, agent, externalAgent, rpa, connector, agenticProcess, childCase, waitTimer, waitEvent, adhoc.
required	Ob die übergeordnete Phase auf den Abschluss dieser Aufgabe warten muss. Bei true kann die Phase erst abgeschlossen werden, wenn die Aufgabe erledigt ist. Bei false kann die Phase abgeschlossen werden, auch wenn diese Aufgabe nicht abgeschlossen wurde.
entryRule	Bedingung, die bestimmt, wann diese Aufgabe gestartet wird. Aktiviert die bedingte Ausführung (z. B. nur ausführen, wenn amount >= 1000).
completeRule	Bedingung, die bestimmt, wann diese Aufgabe als erledigt gilt.
exitRule	Bedingung für das frühe Beenden für die Aufgabe. Wenn sie erfüllt ist, wird die Aufgabe sofort beendet.
runOnReentry	Ob diese Aufgabe zurückgesetzt und erneut ausgeführt wird, wenn die übergeordnete Phase erneut eingegeben wird. Standard: false.
linkedWorkflow	Verweis auf den implementierenden Workflow, das Formular oder die Agent-Konfiguration.
assignment	Für menschliche Aufgaben: die Person, der Benutzer, das Team oder die Routingregel, die den Beauftragten bestimmt.
sla	Für menschliche Aufgaben: Fälligkeit, Warnschwellen und Eskalationsempfänger.

Erforderliche vs. optionale Aufgaben

	Erforderliche Aufgabe	Optionale Aufgabe
Phasenabschluss	Die übergeordnete Phase kann erst abgeschlossen werden, wenn diese Aufgabe abgeschlossen ist.	Die übergeordnete Phase kann auch abgeschlossen werden, wenn diese Aufgabe nicht ausgeführt wird.
Einsatzbereich	Muss ausgeführt werden (z. B. „Manager-Genehmigung“ in der Überprüfungsphase).	Nützliche Arbeit (z. B. „Flag-Anomalien“ – hilfreich, aber die Phase kann ohne fortgesetzt werden).
Interaktion automatisch vervollständigen	Wenn die Phase autoComplete: true hat, wartet der Abschluss auf alle erforderlichen Aufgaben.	Wird bei der Prüfung der automatischen Vervollständigung nicht berücksichtigt.

Verhalten bei der Ausführung bei der erneuten Eingabe (Aufgaben)

runOnReentry	Verhalten	Use case
true	Aufgabe wird zurückgesetzt und erneut ausgeführt, wodurch eine neue Ausgabe erzeugt wird.	Validierungsaufgaben, die korrigierte Daten erneut überprüfen müssen.
false (Standard)	Aufgabe behält ihr vorheriges Ergebnis bei; wird nicht erneut ausgeführt.	Aufgaben, deren Ausgabe noch gültig ist (z. B. muss „Ausgaben kategorisieren“ nicht erneut ausgeführt werden).

---

Bedingungen

Bedingungen (auch als Übergangsbedingungen oder Regeln bezeichnet) steuern die Lebenszyklusbewegung sowohl auf Phasen- als auch auf Aufgabenebene. Maestro unterstützt vier Bedingungstypen.

Eintrittsbedingung

Wird anhand von Fallfeldern ausgewertet. Wenn die Bedingung erfüllt wird, geht die Phase oder Aufgabe von „Verfügbar“ zu „Aktiv“ über.

Umfang	Beschreibung	Beispiel
Phase	Gruppiert den Beginn einer Phase.	vars.validationPassed == true aktiviert die Phase Überprüfung.
Aufgabe	Ermöglicht die bedingte Ausführung einer Aufgabe innerhalb einer aktiven Phase.	Nur ausgeführt, wenn amount >= 1000.

Vollständige Bedingung

Definiert, wann eine Phase oder Aufgabe unter normalen Umständen abgeschlossen ist. Bei Phasen ist dies oft „wenn alle erforderlichen Aufgaben erledigt sind“. Bei Aufgaben ist es in der Regel „wenn die Aufgabenausgabe erzeugt wird“.

Umfang	Beschreibung	Beispiel
Phase	Markiert eine Phase als abgeschlossen, wenn die Arbeit abgeschlossen ist.	Alle erforderlichen Aufgaben wurden abgeschlossen.
Aufgabe	Markiert eine Aufgabe als erledigt, wenn ihre Ausgabe empfangen wird.	taskOutput.status != "error".

Austrittsbedingung (früher Austritt)

Ein Mechanismus für das frühe Beenden. Wenn die Bedingung erfüllt ist, wird die Phase oder Aufgabe sofort beendet – auch wenn nicht die gesamte Regel erfüllt ist. Austrittsbedingungen fungieren als Trennzeichen für ungewöhnliche oder bedingte Szenarien.

Umfang	Beschreibung	Beispiel
Phase	Beendet eine Phase, bevor alle Aufgaben abgeschlossen sind.	vars.action == "Reject" beendet die Phase Überprüfung und der Fall geht in die sekundäre Phase Verweigert über.
Aufgabe	Hält eine Aufgabe vor ihrer normalen Fertigstellung an.	policyValid == false beendet die weitere Validierung.

Hinweis:

Verwechseln Sie Austrittsbedingungen nicht mit vollständigen Bedingungen. Eine vollständige Bedingung wird ausgelöst, wenn die Arbeit erledigt ist (normale Fertigstellung). Eine Austrittsbedingung wird ausgelöst, wenn sich etwas ändert, was bedeutet, dass die Arbeit angehalten werden muss (frühe Sicherheitsüberschreitung). Beide führen dazu, dass der Fallmanager bewertet, in welche Phase als nächstes eingegangen werden soll.

Bedingung für die erneute Eingabe

Ermöglicht die Rückkehr eines Falls zu einer zuvor abgeschlossenen Phase auf strukturierte und prüfbare Weise. Diese Funktion ermöglicht nicht lineare Fallabläufe für kontrollierte Nachbearbeitungsschleifen.

Umfang	Beschreibung	Beispiel
Phase	Setzt den Fall in eine vorherige Phase zurück, wenn zusätzliche Arbeit erforderlich ist.	vars.decision == "Claim is missing key incident reports" Gibt den Fall von der Überprüfung an die Aufnahme zurück.

Konfigurieren Sie, welche spezifischen Aufgaben innerhalb der Zielphase erneut ausgeführt werden sollen, wenn der erneute Eintritt erfolgt. Aufgaben mit runOnReentry: true erneut ausgeführt; Aufgaben mit runOnReentry: false behalten ihre vorherigen Ergebnisse bei.

Überspringen Sie eine Regel

Eine optionale Bedingung für eine Phase, die die Phase vollständig umgibt, wenn die Bedingung „true“ ist.

Umfang	Beschreibung	Beispiel
Phase	Überspringt eine Phase, wenn sie nicht anwendbar ist.	riskScore < 30 überspringt die Phase der detaillierten Untersuchung.

---

SLAs und Eskalationen

Definieren Sie SLAs (Service Level Agreements) und Eskalationsregeln auf Fall- und Phasenebene, um zeitbasierte Erwartungen durchzusetzen.

SLA-Ebenen

Ebene	Beschreibung	Beispiel
SLA auf Fallebene	Gesamtziel für die Falllösung von der Erstellung bis zum Abschluss.	Antrag innerhalb von 48 Geschäftsstunden bearbeiten.
SLA auf Phasenebene	Lokalisierte Fälligkeitszeit für eine bestimmte Phase.	Abschließen der FONF-Einnahme innerhalb von 4 Stunden; Managerüberprüfung innerhalb von 24 Stunden.

SLA-Status

Status (State)	Beschreibung
Im Zeitplan	Der Fall oder die Phase befindet sich innerhalb der zugewiesenen Zeit.
Gefährdet	Die SLA nähert sich ihrem Limit (z. B. 80 % der zugewiesenen Zeit).
Verstoß	Das SLA-Zeitlimit wurde überschritten.

SLA-Status werden als Abzeichen in Falllisten und Detailansichten innerhalb der Fall-App angezeigt.

Eskalationsregeln

Auslösen	Beschreibung	Typische Aktion
Gefährdete Eskalation	Wird ausgelöst, wenn sich die SLA ihrem Limit nähert.	Den Fallinhaber und den Vorgesetzten benachrichtigen.
Verstoßeskalation	Wird ausgelöst, wenn die SLA überschritten wird.	Neuzuweisung für einen leitenden Mitarbeiter, Benachrichtigung des Managements, Erstellung eines Prioritäts-Flags.

Anhalten und fortsetzen

SLA-Timer können angehalten werden, wenn der Fall auf eine externe Eingabe (z. B. eine Kundenantwort) wartet, und fortgesetzt, wenn der Fall wieder aktiv werden kann.

---

Fallmanager

Der Fallmanager orchestriert den Falllebenszyklus mithilfe deterministischer Regeln . Regeln verarbeiten bekannte, vorhersehbare Muster.

So funktioniert der Fallmanager

1. Ereignis empfangen – Ein Trigger wird ausgelöst und erstellt (oder aktualisiert) eine Fallinstanz.
2. Regelauswertung – Der Fallmanager bewertet die Eintrittsbedingungen für alle Phasen, um zu bestimmen, welche Phasen aktiv werden sollen.
3. Aufgabenaktivierung – Innerhalb aktiver Phasen werden die Eintrittsbedingungen für Aufgaben ausgewertet, um die entsprechende Arbeit zu starten.
4. Überwachung – Während die Aufgaben abgeschlossen sind, bewertet der Fallmanager die Bedingungen für den Abschluss (normale Fertigstellung) und die Austrittsbedingungen (frühes Breakout).
5. Fallabschluss – Wenn alle erforderlichen Phasen abgeschlossen sind, wird der Fall geschlossen.

Regel-Scope

Regeln (Eintrag, Abschluss, Austritt) können auf drei Ebenen definiert werden:

• Fallebene – steuert den gesamten Falllebenszyklus ( wann ist der Fall abgeschlossen?).
• Phasenebene – Steuerelementphasenübergänge ( wann wird diese Phase aktiviert, abgeschlossen oder beendet?).
• Aufgabenebene – steuert die Aktivierung und den Abschluss einzelner Aufgaben.

Konfiguration des Fallmanagers

Einstellung	Beschreibung
model	Das LLM, das den Agent unterstützt (z. B. claude-3.5-sonnet, gpt-4o).
userPrompt	Systemanweisungen, die die Rolle, Richtlinien und Einschränkungen des Agents definieren.
tools	Aktionen, die der Agent ausführen kann (z. B. Phase verschieben, Eskalieren, Benachrichtigungen senden).
context	Speicher für den Agent, das automatisch basierend auf dem Ausführungsverlauf erstellt wird. Der Agent sammelt den Kontext von früheren Entscheidungen, Aufgabenergebnissen und Änderungen des Fallstatus.

Hinweis:

Wenn der Fallmanager aufgrund von mehrdeutigen Daten, widersprüchlichen Regeln oder einem Szenario außerhalb seiner Richtlinien keine Entscheidung treffen kann, eskaliert er automatisch zu einem Menschen.

---

Fallpersonas

Fallpersonas definieren die Rollen menschlicher Teilnehmer, die während seines gesamten Lebenszyklus mit einem Fall interagieren. Personas steuern, wer innerhalb jeder Phase sehen und handeln kann. Personas sind für Menschen, nicht für Agenten. KI-Agents werden separat als Aufgabentypen konfiguriert.

Integrierte Persona-Typen

Persona	Rolle	Typische Funktionen
Fallersteller	Initiiert den Fall – übermittelt den ursprünglichen Trigger (Portalformular, API-Aufruf, E-Mail).	Neue Fallinstanzen erstellen; Status der von ihnen erstellten Fälle anzeigen; Eingeschränkte Möglichkeit, offene Fälle zu aktualisieren, bevor die erste Phase abgeschlossen ist.
Fallbesitzer	Verantwortlich für den Fall durchgängig. Wird bei der Erstellung oft zugewiesen.	Vollständige Sichtbarkeit des Falls über alle Phasen hinweg; kann Aufgaben neu zuweisen, Entscheidungen überschreiben (innerhalb der Richtlinie), geschlossene Fälle erneut öffnen
Fallbearbeiter	Führt zugewiesene menschliche Aufgaben innerhalb bestimmter Phasen aus.	Anzeigen und Abschließen von Aufgaben in ihrer Warteschlange (Meine Arbeit); Fallfelder aktualisieren, die auf die Ausgabe ihrer Aufgabe beschränkt sind; Nur Sichtbarkeit auf Phasenebene.
Vorgesetzter/Manager	Überwacht das Portfolio eines Teams; Behandelt Eskalationen.	Alle Fälle anzeigen, die ihrem Team zugewiesen sind; Aufgaben neu zuweisen; Eskalationen genehmigen; SLA-Timer anhalten/fortsetzen; Zugriff auf Dashboards und KPIs.
Antragstellerexperte (SME)	Beratung zu bestimmten Fällen oder Phasen, die Fachwissen erfordern.	Lesezugriff auf relevante Falldaten; kann von KMU festgelegte Aufgaben abschließen; verfügt nicht über umfassende Berechtigungen für die Fallverwaltung.

Über die integrierten Typen hinaus können Fallentwickler benutzerdefinierte Personas erstellen – geben Sie der Person einen Namen und ordnen Sie sie einer oder mehreren bestimmten Phasen zu. Benutzerdefinierte Personas werden nicht automatisch überall angezeigt.

Persona-Berechtigungen auf Phasenebene

Definieren Sie für jede Phase im Fallplan zwei Zugriffsdimensionen für jede Person:

• Zugriff anzeigen – Welche Personen können die Daten, Aufgaben und den Verlauf dieser Phase in der Fall-App sehen.
• Act-Zugriff – welche Personen innerhalb dieser Phase Aktionen ausführen (Aufgaben abschließen, Hinweise hinzufügen, Neu zuweisen, Eskalieren, Übergänge auslösen).

Aufgaben übernehmen standardmäßig die Persona-Einstellungen der Phase, können jedoch die zulässigen Rollen weiter eingrenzen.

Zuweisungsstrategien

Strategy	Wie es funktioniert	Einsatzbereich
Statisch	Ein fester Benutzer, ein Team oder eine Gruppe wird zur Entwurfszeit zugewiesen.	Aufgaben, die immer an dasselbe Team gehen (z. B. geht die Finanzüberprüfung immer an die Gruppe „Finanzen“).
Dynamisch	Eine Regel oder ein Ausdruck löst den Beauftragten zur Laufzeit auf.	Ausgewogene Zuweisung mit Workload, Gebiets-/Regionsweiterleitung, fähigkeitsbasiertes Routing.

Hinweis:

Die Unterstützung für Fallbenutzerrollen und den Zugriff ist noch nicht verfügbar.

---

Fall-App

Die Fall-App ist die Runtime-Anwendung für Geschäftsanwender, in der Fallmitarbeitende, Manager und andere Personen Live-Fallinstanzen anzeigen, nachverfolgen und darauf reagieren können.

Was Geschäftsanwender sehen

Ansicht	Beschreibung
Fallliste/Warteschlange	Filterbare Ansicht aller Fallinstanzen mit Status-, Prioritäts- und SLA-Indikatoren (auf Kurs, gefährdet, verletzt).
Ansicht mit Falldetail	Aktuelle Phase, Aufgabenstatus, Zeitleiste der Ereignisse und vollständiger Prüfungspfad.
Aufgabeneingang (Meine Arbeit)	Ausstehende menschliche Aufgaben, die auf Aktion warten: Formulare, Genehmigungen, Überprüfungen.
Aktionen	Kontextbezogene Aktionen basierend auf der Rolle und der aktuellen Phase: Abschließen, erneut öffnen, eskalieren, neu zuweisen, Hinweise hinzufügen, Informationen anfordern, Ad-hoc-Aufgaben erstellen.
Dashboards	Aggregierte KPIs: Durchsatz, Lösungszeit, SLA-Compliance, Engpassidentifizierung.

Konfiguration

Konfigurieren Sie die Fall-App über die Option Fall-App konfigurieren in den Einstellungen für die Fallverwaltung in Studio Web. Zu den konfigurierbaren Elementen gehören:

• Falltitel – Der in der Fallliste und in den Detailansichten angezeigte Anzeigetitel.
• Falldetails – Die Felder und das Layout, die in der Falldetailansicht angezeigt werden.

Fall-App im Vergleich zu UiPath-Apps

Aspekt	Case App	UiPath Apps
Zweck	Opinionierter, fallzentrierter Arbeitsbereich – Listen, Details, Aufgaben, Vorfälle und SLA-Ansichten für Fallvorgänge.	Allgemeine Low-Code-Builder für vollständig benutzerdefinierte oder zusammengesetzte Geschäfts-Apps.
Einsatzbereich	Schnelle Fallvorgänge mit sofort einsatzbereiten Ansichten.	Maßgeschneiderte UI-Anforderungen, die über Fallvorgänge hinausgehen.

Menschliche Aufgabenformulare werden weiterhin mit Aktions-Apps erstellt und werden von Fallaufgaben referenziert.

---

Verwaltung von Fallinstanzen

Fallinstanzverwaltung ist die Betriebskonsole, auf der Prozessoperatoren alle ausgeführten Fallinstanzen überwachen und verwalten.

Operatoraktionen

Aktion	Beschreibung
Pause	Halten Sie eine laufende Fallinstanz vorübergehend an. SLA-Timer pausieren. Es werden keine Aufgaben aktiviert, bis sie fortgesetzt werden.
Fortsetzen	Starten Sie einen angehaltenen Fall neu. SLA-Timer werden dort fortgesetzt, wo sie angehalten wurden.
Abbrechen	Eine Fallinstanz endgültig beenden. Alle laufenden Aufgaben werden angehalten.
Migrieren	Verschieben Sie eine Live-Fallinstanz in eine neuere Version des Fallplans (z. B. nach einer Fehlerbehebung oder Planaktualisierung), wobei der aktuelle Status und die Daten erhalten bleiben.
Wiederholen	Führen Sie die fehlgeschlagene Aufgabe oder den Übergang erneut aus, um vorübergehende Fehler zu beheben.
Update Variables	Ändern Sie die Werte von Fallvariablen in einer laufenden Instanz, um die Verarbeitung zu entsperren.

Fallvorfälle

Wenn eine Fallinstanz in einen Fehlerzustand eintritt (z. B. eine Aufgabe schlägt fehl, eine Integration wird abgebrochen oder der Fall bleibt hängen), wird sie zu einem Fallvorfall. Prozessoperatoren verwenden Variablen migrieren, wiederholen und aktualisieren, um Vorfälle zu beheben.

---

Ereignistrigger

Ereignistrigger sind die Einstiegspunkte in einem Fall. Sie definieren, was einen Fall startet und woher die Daten stammen. Ein einzelner Fallplan kann mehrere Trigger haben.

Triggertyp	Quelle	Beispiel
Formular/Portal	Der Benutzer übermittelt über ein Webformular.	Der Mitarbeiter reicht einen Ausgabenbericht über ein Portal ein.
E-Mail	Eingehende E-Mail auf Daten analysiert.	Weitergeleitete Beleg-E-Mail erstellt einen neuen Fall.
API	Externes System ruft den Endpunkt der Fallerstellung auf.	Das ERP-System löst einen Anspruchsfall für ein Richtlinienereignis aus.
Warteschlange/Ereignis	Nachricht aus einer Warteschlange oder einem Ereignisstream.	Das Kafka-Thema veröffentlicht ein neues Reihenfolgeereignis.
Geplant	Zeitbasierter Trigger.	Die tägliche Überprüfung erstellt Nachfassungen für veraltete Elemente.
Data Fabric-Entitätsereignis	Ein Ereignis auf Zeilenebene in einer Data Fabric-Entität oder einem VDO (z. B. „Zeile erstellt“).	Eine neue Zeile in der Entität „Home Claims“ löst einen Fall aus.
Auf Connector warten	Ein Connector-Ereignis von Integration Service (z. B. eine gepostete Nachricht im Microsoft Teams-Kanal).	Eine Teams-Nachricht löst den Eintrag in der zurückgezogenen Phase aus.

Jeder Trigger ordnet eingehende Daten Fallfeldern zu.

---

Abrechnung und Verbrauchsmaterialien

• Keine separate Abrechnung für Fallmanagement von Maestro
• Arbeit, die innerhalb eines Falls ausgeführt wird, verbraucht die nativen Verbrauchsmaterialien der verwendeten Aufgabentypen:
  • AI agents
  • Agentische Prozesse von Maestro (BPMN-Prozesse)
  • RPA-Workflows
  • API-Workflows/-Integrationen

---

Glossar

Begriff	Definition
Ad-hoc-Aufgabe	Eine zur Runtime erstellte Aufgabe (nicht Teil des ursprünglichen Fallplans), die von einem menschlichen Benutzer erstellt wird, wenn eine unerwartete Aktion erforderlich ist.
Fall	Eine Runtime-Instanz, die eine reale Geschäftssituation darstellt, die gelöst werden muss (ein Anspruch, ein Streitfall, eine Untersuchung, eine Ausnahme). Identifiziert durch einen Fallschlüssel.
Case App	Die für Geschäftsbenutzer ausgerichtete Anwendung, bei der Personen Live-Fallinstanzen anzeigen, nachverfolgen und darauf reagieren können.
Fallkommentare	Vorgefertigtes Objekt, das Hinweise, Anmerkungen und Kommunikations-Threads speichert, die über das Unveränderliche caseID verknüpft sind.
Falldokumente	Vorgefertigtes Objekt, das Dateien und Anhänge im Zusammenhang mit dem Fall speichert, verknüpft über das Unveränderliche caseID.
Fallvorfall	Ein Fehlerzustand in einer Fallinstanz (Aufgabenfehler, Integrationszeitüberschreitung, festgefahrener Fall), der ein Eingreifen eines Operators erfordert.
Verwaltung von Fallinstanzen	Betriebskonsole in Maestro, in der Prozessoperatoren alle laufenden Fallinstanzen anzeigen und Aktionen ausführen: Anhalten, Fortsetzen, Abbrechen, Migrieren, Wiederholen.
Fallschlüssel	Eindeutiger Bezeichner für eine Fallinstanz. Kann vom System generiert oder ein externer/kundendefinierter Wert sein.
Case Manager	Orchestrierungsengine, die deterministische Regeln verwendet.
Fallpersona	Eine Rolle für einen menschlichen Teilnehmer, die auf bestimmte Phasen beschränkt ist. Integrierte Typen: Fallersteller, Fallinhaber, Fallmitarbeiter, Vorgesetzter/Manager, SME. Entwickler können benutzerdefinierte Personas erstellen.
Case Plan	Visuelle Blaupause, die Phasen, Aufgaben, Trigger und Regeln definiert. Beschreibt die möglichen Pfade, keine feste Sequence. Entworfen in Studio Web.
Vollständige Bedingung	Bedingung, die bestimmt, wann eine Phase oder Aufgabe unter normalen Umständen abgeschlossen ist.
Eintrittsbedingung	Bedingung, die „true“ sein muss, damit eine Phase oder Aufgabe aktiviert wird.
Ereignistrigger	Einstiegspunkt, der eine Fallinstanz erstellt oder beeinflusst. Ordnet eingehende Daten Fallfeldern zu.
Exit Condition	Bedingung für früher Austritt. Wenn sie erfüllt ist, wird die Phase oder Aufgabe sofort beendet, auch wenn die vollständige Regel nicht erfüllt wurde.
Primäre Phase	Eine Phase im Erfolgspfad eines Falls.
Re-entry Condition	Bedingung, die es einem Fall ermöglicht, in eine zuvor abgeschlossene Phase zur Nachbearbeitung zurückzukehren.
Erforderlich	Kennzeichnen für Phasen und Aufgaben. Erforderliche Phasen müssen abgeschlossen sein, damit der Fall geschlossen wird. Erforderliche Aufgaben müssen abgeschlossen sein, damit die Phase abgeschlossen werden kann.
Run on Re-entry	Flag, das steuert, ob eine Phase oder Aufgabe zurückgesetzt und erneut ausgeführt wird, wenn sie nach dem vorherigen Abschluss erneut eingegeben wird.
Sekundäre Phase	Eine Phase, die einen Ausnahmepfad darstellt, der vom primären Flow abzweigt. Kann zum Ursprung zurückkehren oder Terminal sein.
Überspringen einer Regel	Optionale Bedingung für eine Phase, die die Phase vollständig umgibt, wenn die Bedingung „true“ ist.
SLA	Vereinbarung zum Servicelevel. Zeitbasierte Erwartung für den Abschluss eines Falls oder einer Phase mit den Zuständen: auf Kurs, gefährdet, verletzt.
Phase	Eine benannte Phase im Falllebenszyklus, die verwandte Aufgaben gruppiert. Wird durch Eintritts-, Abschluss-, Austritts- und erneute Eingabebedingungen geregelt.
Aufgabe	Eine einzelne Arbeitseinheit innerhalb einer Phase. Zehn Typen: Mensch, Agent, Externer Agent, RPA, Connector, Agentischer Prozess, Untergeordneter Fall, Warten, Ereignis warten, Ad-hoc.

---

Zugehörige Ressourcen

• Tutorial zur Fallverwaltung – End-to-End-Anleitung zum Erstellen eines Falls von Grund auf.
• Fallplan-Designer in Studio Web – Referenz für die visuelle Entwurfsfläche.
• Dokumentation zu Aktions-Apps – So erstellen Sie Formulare für menschliche Aufgaben, auf die Fallaufgaben verweisen.