> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Fall-Blueprints – Zuweisung & Fallinhalt > Legen Sie mit Didit fest, wie Fälle zugewiesen, eskaliert, übertragen und angezeigt werden, und installieren Sie die vier integrierten Presets. Eine Prüfrichtlinie, die in der API als Blueprint dargestellt wird, legt die Anforderungen für eine Fallkategorie fest. Richtlinien verwalten Sie unter **Fallmanagement > Zuweisung > Prüfrichtlinien**. Fälle speichern die Richtlinienversion, die beim Öffnen gilt. Spätere Änderungen verändern daher keine laufende Prüfung stillschweigend. Der Editor sendet beim Speichern die Version, die Sie geöffnet haben. Hat ein anderer Prüfer inzwischen eine neuere Version veröffentlicht, meldet das Speichern einen Konflikt, und Ihr Entwurf bleibt geöffnet. Prüfen Sie die neueste Richtlinie, bevor Sie Ihre Änderungen erneut übernehmen. API-Integrationen können `expected_version` zusammen mit einer Richtlinienaktualisierung für denselben Schutzmechanismus senden. Eine veraltete Version liefert `409` zurück und ändert die Richtlinie nicht. *** ## Allgemeine Einstellungen | Einstellung | Beschreibung | | - | - | | **Name** | Bis zu 24 Zeichen | | **Beschreibung** | Optional, freier Text | | **Wer bearbeitet Fälle** | Pool der Bearbeiter, Pflichtfeld, mindestens ein Mitglied („Wählen Sie mindestens einen Bearbeiter aus“) | | **Zuweisung** | **Manuell** oder **Automatisch** | | **Fallübertragung** | Schalter; wenn aktiviert, können Fälle in einen anderen aktiven Blueprint derselben Anwendung verschoben werden | | **Eskalation** | Schalter plus eine Auswahl des Ziel-Blueprints | | **4-Augen-Prüfung** | Paarung mit einem Prüfer-Blueprint, siehe [4-Augen-Prüfung](https://docs.didit.me/de/console/case-management/four-eyes.md) | | **Auflösungsnotiz erforderlich** | Schalter; wenn aktiviert, ist die Notiz im Dialog „Auflösen“ verpflichtend | | **Standardfrist** | Optionale Frist in Stunden für neue Fälle; eine explizit gesetzte Fallfrist hat Vorrang | ### Automatische Zuweisung Die automatische Zuweisung wählt einen berechtigten Prüfer mit den wenigsten aktiven Fällen in der gesamten Organisation aus, bis zur konfigurierten Kapazität. Online-Prüfer werden bevorzugt, sofern verfügbar. Andernfalls können berechtigte Offline-Prüfer Fälle erhalten. Sind alle berechtigten Prüfer ausgelastet, bleibt der Fall nicht zugewiesen. Wenn ein Fall aufgelöst wird oder ein Prüfer online geht, kann ein wartender Fall übernommen werden, sofern Kapazität frei ist. ### Eskalation und Verschiebung Bei der Eskalation wird ein Fall mit einer Aktion in einen festen Ziel-Blueprint verschoben (dessen Warteschlange und Inhaltskonfiguration). Bei der Verschiebung kann ein Prüfer dagegen einen beliebigen aktiven Blueprint derselben Anwendung auswählen, in den der Fall verschoben wird. Beide Optionen sind auf der Fallseite ausgeblendet, sofern der aktuelle Blueprint sie nicht aktiviert, und beide werden serverseitig mit 400 blockiert, wenn sie bei deaktivierter Option aufgerufen werden. Ein Blueprint kann sich selbst nicht als eigenes Eskalationsziel oder als 4-Augen-Prüfer referenzieren. ### Verbundene Quellen Die rechte Seitenleiste eines Blueprints listet Folgendes auf: * **Quellen für die Fallerstellung**: AML-Konfigurationen, Transaktionsregeln und Workflow-Knoten, die aktuell neue Fälle in diesen Blueprint leiten, mit Verknüpfungen zu jedem einzelnen. * **Empfängt Eskalationen von**: andere Blueprints, deren Eskalationsziel auf diesen Blueprint zeigt. ## Richtlinienänderungen speichern und veröffentlichen Mit **Entwurf speichern** speichern Sie Ihre Änderungen, ohne neue oder bestehende Fälle zu beeinflussen. Eine neue Richtlinie bleibt unveröffentlicht und kann für einen Fall oder eine Routing-Regel erst ausgewählt werden, nachdem Sie **Veröffentlichen** gewählt haben. Wenn Sie den Editor erneut öffnen, wird der gespeicherte Entwurf wiederhergestellt. **Veröffentlichen** wird verfügbar, sobald die aktuellen Änderungen gespeichert wurden. Beim Veröffentlichen wird diese Version auf neue Fälle angewendet. Bestehende Fälle behalten die akzeptierten Prüfanforderungen. Im **Versionsverlauf** wird jede veröffentlichte Konfiguration mit Veröffentlichungszeitpunkt und, sofern bekannt, dem Veröffentlicher festgehalten. Richtlinien, die vor der Verfügbarkeit des Versionsverlaufs erstellt wurden, erhalten ihre aktuelle Ausgangsversion beim nächsten Veröffentlichen im Verlauf. **Entwurf verwerfen** erfordert eine Bestätigung und setzt den Editor auf die veröffentlichte Konfiguration zurück. Wenn Sie einen nie veröffentlichten Entwurf verwerfen, wird er gelöscht. Beim Speichern eines Entwurfs und bei der Veröffentlichungsprüfung werden sowohl die veröffentlichte Version als auch die Entwurfsrevision geprüft. Ändert jemand anderes eines davon, gibt der Server `409` zurück, und Ihr geöffneter Editor behält die nicht gespeicherten Änderungen. Ein Entwurf, der auf einer älteren veröffentlichten Richtlinie basiert, muss vor der Veröffentlichung mit der aktuellen Richtlinie abgeglichen werden. Direkte API-`PATCH`-Aktualisierungen sind weiterhin sofort wirksame Veröffentlichungen und werden ebenfalls im Versionsverlauf erfasst. ### Entwürfe für Routing-Regeln Routing-Regeln verwenden dieselben Aktionen **Entwurf speichern**, **Veröffentlichen**, **Entwurf verwerfen** und **Versionsverlauf**. Das Speichern eines Entwurfs ändert weder die Regel für die automatische Zuweisung noch die Vorschau der veröffentlichten Regel. Unveröffentlichte Änderungen müssen vor der Veröffentlichung gespeichert werden. Bei der Veröffentlichung wird geprüft, ob die ausgewählte Prüfrichtlinie und das ausgewählte Team noch aktiv sind und zur selben Anwendung gehören. Ändert ein anderer Editor die Regel oder deren Entwurf, meldet der Vorgang einen Konflikt und behält die neueren Änderungen bei. Neue Regeln verwenden zuerst **Entwurf speichern** und bleiben inaktiv, bis **Veröffentlichen** Version 1 erstellt. Für API-Integrationen setzen Sie beim Erstellen einer Richtlinie oder Routing-Regel `publish=false`, um diesen Lebenszyklus zu nutzen. Lassen Sie die Option weg, bleibt die sofortige Erstellung für bestehende Integrationen erhalten. ## Preset-Bibliothek Installieren Sie eines der vier integrierten Presets aus der Galerie der Presets für Prüfrichtlinien. Bei der Installation wird das Preset als vollständig bearbeitbarer Blueprint in Ihre Anwendung kopiert. Anschließend können Sie jede Einstellung frei ändern, ohne den Katalog zu beeinflussen. Die Installation ist pro Preset idempotent: Ein bereits installiertes Preset erneut zu installieren, bewirkt nichts. | Preset | Fallinhalt | | - | - | | **Screening-Treffer** | AML-Kontrolle (Finanzen + Identität), Identität (persönliche Informationen, Risikoübersicht) | | **AML-Ermittlung** | AML-Kontrolle (Finanzen), Identität (persönliche Informationen, Kontaktinformationen, Risikoübersicht, PoI-Dokumente) | | **Verdächtige Aktivität** | Identität (persönliche Informationen, Risikoübersicht, PoI-Dokumente), Finanzen (Zahlungsmethoden, Transaktionen) | | **KYC-Prüfung** | Identität (alle Felder), Verifizierungszusammenfassung | Keines der Presets konfiguriert Zuweisung, Eskalation, 4-Augen-Prüfung oder Verschiebung vor. Diese Routing-Entscheidungen treffen Sie immer selbst, pro Blueprint. ## Fallinhalt Der Tab **Fallinhalt** steuert, welche Tabs und Felder auf der Fallseite erscheinen. Dafür gibt es sechs ein- und ausschaltbare Abschnitte: | Abschnitt | Felder | | - | - | | **Checkliste** | Aktivieren, für die Auflösung optional machen und die Liste der Checklistenpunkte, siehe [Checkliste](https://docs.didit.me/de/console/case-management/checklist.md) | | **AML-Kontrolle** | Finanzbezogene AML-Informationen, identitätsbezogene AML-Informationen | | **Identität** | Persönliche Informationen, Antragsteller-Tags, Kontaktinformationen, Risikoübersicht, Dokumente zum Identitätsnachweis, Adressnachweise | | **Verifizierungen** | Verifizierungszusammenfassung | | **Berichterstattung** | FIU-Berichte | | **Finanzdaten und -quellen** | Zahlungsmethoden, Finanztransaktionen | Ein Blueprint, bei dem keine Abschnitte aktiviert sind, zeigt trotzdem den Tab „Übersicht“ des Falls, jedoch ohne die zusätzlichen Inhaltsblöcke. > [!TIP] > > Verwenden Sie eine Standardfrist aus der Richtlinie, damit neue Fälle einen einheitlichen Prüfzeitraum erhalten. > Prüfer können Priorität und Fälligkeitsdatum eines einzelnen Falls weiterhin ändern. > Eine Änderung der Richtlinie ändert die Fristen bestehender Fälle nicht. ## Löschen eines Blueprints Das Löschen eines Blueprints gelingt immer und lässt seine Fälle unverändert: Bestehende Fälle behalten ihren Blueprint-Verweis, und seine Einstellungen (Inhaltsabschnitte, Eskalation, Übergabe, 4-Augen-Zuordnung) gelten für sie weiterhin. Ein gelöschter Blueprint erscheint nicht mehr in den Blueprint-Listen und kann nicht mehr als Übertragungsziel gewählt werden. Wird ein Maker-Blueprint gelöscht, während eine seiner Auflösungen auf die 4-Augen-Genehmigung wartet, bleibt der Fall bei einer abgelehnten Auflösung auf dem Checker-Blueprint und wird nicht zurückgegeben. Um einen Blueprint sauber außer Betrieb zu nehmen, übertragen Sie seine aktiven Fälle vor dem Löschen auf einen anderen Blueprint. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.