Introduction to Case

Case concepts for long-running, exception-heavy work, including case management use cases, tool surfaces, and core design components.

	Fall	Flow	BPMN
Der Inhalt gilt für	✅	❌	❌

Überblick

Case orchestrates long-lived, goal-driven work about a specific situation — a case. A case holds data, rules, tasks, and history to drive an auditable outcome such as a refund, a claim decision, or an investigation closure. Where BPMN excels at structured, sequential orchestration, Case addresses scenarios that are exception-heavy, non-linear, and dependent on human and AI agent judgment at key decision points.

This document introduces Case as a distinct capability in Maestro Orchestrate, walks through the business use cases it solves and when to choose it over BPMN, gives you a tour of the toolset you will work in, and lays out the fundamental concepts you need to understand before building your first agentic case.

Audience: Beginner to Intermediate — solution architects, business analysts, and developers evaluating or starting with Case.

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	How Case Addresses It
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	Why Case
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

Not every process needs case management. If a process is short-lived, predictable, and follows the same sequence every time, a BPMN is often simpler and more efficient.

Hinweis:

Quick test: If the next step depends on what just happened and no single flowchart can capture every path, consider case management. If the process follows the same path every time, use 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	Fall	BPMN
Arbeitsstruktur	Benannte Phasen mit regelbasierten Übergängen; der Laufzeit-Pfad wird dynamisch bestimmt	Definierte Sequenz von Schritten, die in der BPMN-Notation modelliert werden
Lebenszyklus	Langlebig und zielorientiert; entwickelt sich weiter, sobald neue Informationen verfügbar werden	Can be long-lived; follows a path defined at design time
Nicht-linearer Ablauf	Integrierte Unterstützung für Wiedereintritt, sekundäre Phasen, Überspringen von Regeln und Ad-hoc-Aufgaben	Möglich über BPMN-Gateways und -Schleifen, aber komplex zu modellieren für sehr variable Szenarien
Datenmodell	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	Prozessvariablen, die auf die Instanz beschränkt sind
SLAs und Eskalationen	First-Class-Konstrukte sowohl auf Fallebene als auch auf Phasenebene mit Eskalationsregeln für Gefährung und Fristüberschreitung	Nicht nativ auf Prozessebene modelliert
User Experience	Dedizierte Case App für Geschäftsbenutzer (Fallliste, Detailansicht, Aufgabenposteingang) und Case-Instanz-Management für Operatoren	Monitored via the Maestro Orchestrate Monitoring tab for operators
Rollenbasierter Zugriff	Phasenbewusste Personas – Definieren Sie, wer in jeder Phase sehen und handeln kann.	Standard Plattform-Berechtigungen
Ad-hoc-Arbeit	Unterstützt – Der Case Manager oder ein menschlicher Benutzer kann Aufgaben zur Laufzeit erstellen	Nicht unterstützt; alle Schritte werden zur Entwurfszeit definiert

A case can invoke a BPMN as one of its task types, and a BPMN can invoke a case as one of its task types — making the two project types complementary rather than competing. Use BPMN for well-defined sub-processes and Case as the outer orchestration layer when the overall flow is dynamic.

Von Grund auf agentenzentriert

Case management is the right shape for exception-heavy, long-running work — but on its own, it still relies on human knowledge workers to make most routing and judgment calls. Case is agentic-first and AI-native: AI agents are first-class participants in the case and operate at two distinct levels:

• 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.

Case toolset

Case spans the end-to-end case lifecycle through three complementary surfaces:

Case Plan-Designer (Studio Web)

Who it is for: Process developers and business architects.

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.

Case instance management (Maestro Orchestrate)

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 Orchestrate)

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	A pre-built, no-code case workspace that ships with Case. Lists, detail views, task inbox, and SLA views are configured automatically from your case plan and entity.	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	Auto-generated by Maestro Orchestrate on case creation	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.

You can bring the case entity into Case in three ways:

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

Case supports two kinds of stages:

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

Case supports the following task types:

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
Agent-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 einen Umschalter Aktive Arbeit unterbrechen, der steuert, was mit anderen aktiven Phasen und laufenden Aufgaben geschieht, wenn die Eintrittsregel mit wahr zurückgegeben wird:

• Aktive Arbeit unterbrechen an – Alle derzeit aktiven Phasen werden beendet und jede laufende Aufgabe im Fall wird abgebrochen, bevor der Fall in die neue Phase eintritt. Verwenden Sie dies für harten Ausnahmepfade wie „Zurückgezogen“ oder „Be Betrugsspeicher“ , die den Fall sofort übernehmen müssen.
• Aktive Arbeit unterbrechen – die neue Phase wird zusammen mit allen vorhandenen aktiven Phasen aktiviert. Für den Fall können mehrere Phasen parallel ausgeführt werden, und bereits ausgeführte Aufgaben werden fortgesetzt.

Die Standardeinstellungen unterscheiden sich je nach Phasenart: In primären Phasen ist der Umschalter standardmäßig deaktiviert (parallel beitreten – der normale Arbeitsfortschritt) und Sie können ihn pro Eintrittsregel aktivieren. Sekundäre Phasen unterbrechen immer die aktive Arbeit, da sie Ausnahmen oder alternative Pfade darstellen, die den Fall übernehmen; Der Umschalter ist aktiviert und kann nicht deaktiviert werden.

Ein eigenständiger Phasenaustritt (über eine Abgeschlossen- oder Austrittsregel) beendet keine Aufgaben, die bereits ausgeführt werden. Nur eine Eintrittsregel mit aktiver Arbeit unterbrechen bricht laufende Aufgaben ab.

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 – Der Fallmanager-Agent berücksichtigt den Fall, die Ereignisse, die darauf eintreffen, sowie die verfügbaren Richtlinien und das Wissen, um die nächste Aktion auszuwählen. Auf diese Weise kann ein Fall weiterlaufen, ohne für jede nicht abgedeckte Verzweigung zu einem Menschen zu eskalieren – z. B. wenn ein Dokument hochgeladen oder ein Kommentar mitten im Fall hinzugefügt wird und keine Regel dies erwartet hat.

Sie wählen über seine Verhaltenseinstellung aus, wann der Agent aufgerufen wird:

• Rules-First (Agent als Fallback) – Der Agent wird nur für Ereignisse und Entscheidungen ausgeführt, die durch keine Regel abgedeckt werden.
• Agent-gesteuert (rein agentisch) – Der Agent wird für jeden Entscheidungspunkt ausgeführt und wählt die nächstbeste Aufgabe oder Phase aus, wobei Regelentscheidungen als Leitplanken verwendet werden.

Hinweis:

Der Fall Manager-Agent und seine Verhaltensmodi befinden sich in der öffentlichen Vorschau.

Der Fallmanager-Agent entscheidet; Die Engine wird ausgeführt – sie gibt Entscheidungen zurück und verändert den Fall nie direkt. Es handelt sich um einen gesteuerten UiPath-Agent: Sein System-Prompt und sein Eingabe-/Ausgabevertrag sind vordefiniert, während Sie das Modell, den Kontext, den Speicher, die Tools und Eskalationspfade konfigurieren – und es vor der Produktion mit Evaluierungen testen. Die vollständige Spezifikation finden Sie unter Konfigurieren und Testen des Case Manager-Agents .

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 werden nicht automatisch angehalten. Ein Operator kann eine Fallinstanz explizit anhalten, um deren SLA-Timer zu stoppen, und sie fortsetzen, um sie an der Stelle neu zu starten, an der sie angehalten wurden.

Fallpersonas

Case enforces stage-aware access through personas so the right people see and act at the right time:

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 Verbrauchseinheiten

Case follows the same billing as Maestro Orchestrate. Work that runs inside a case consumes the native consumables of the task types you use: AI agents, RPA workflows, API workflows, or IS connectors.

Nächste Schritte

• Build your first Case project — A step-by-step tutorial that walks through creating, deploying, and testing a property insurance claims case from scratch.
• Core constructs reference — Detailed reference for every Case construct: case entity [Coming Soon] , stages, tasks, transition conditions, SLAs, and personas.
• Konfigurieren von Phasenübergängen und Wiedereintritt – Eine Anleitung zur Modellierung nichtlinearer Fallabläufe mit Eintritts-, Austritts- und Wiedereintrittsbedingungen.
• Konfigurieren und Testen des Fallmanager-Agents (Vorschau) – Fügen Sie den KI-Orchestrator zu einem Fall hinzu, wählen Sie seinen Verhaltensmodus aus, konfigurieren Sie Modell/Kontext/Speicher/Eskalation und testen Sie ihn mit Evaluierungen vor der Produktion.
• Build a Case with a coding agent (preview) — Use a coding agent such as Claude Code or GitHub Copilot to draft, build, and deploy a case plan from a prompt, BPMN model, process map, or PDD.