--- title: "Wie verhindern Sie, dass Angebote und Rabatte ohne Freigabe verschickt werden?" blueprint: 004 slug: quote-approval-thresholds category: Prozesssteuerung published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/quote-approval-thresholds/ language: de translation_of: https://blueprints.coevera.com/blueprints/quote-approval-thresholds/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie verhindern Sie, dass Angebote und Rabatte ohne Freigabe verschickt werden? **Kurze Antwort.** Ein **Freigabeprozess auf der Entität Quote**, ausgelöst beim Anlegen oder Aktualisieren und eingegrenzt durch einen gewöhnlichen **Filterknoten** – dort liegt der Schwellenwert. Eine Angebotssumme mit dem Operator `More` und dem Wert `10000` ist alles, was „nur über 10K“ bedeutet. Derselbe Mechanismus funktioniert auf einem Rabattprozentsatz oder einem Margenfeld. Durchgesetzt wird über **`recordLock`**, nicht über eine Benachrichtigung. Leiten Sie an **`SalesUnitManager`** weiter statt an namentlich benannte Personen, damit es Personalwechsel übersteht. Und prüfen Sie **`expirationResult`**, bevor Sie live gehen – es kann auf *Approve* gesetzt sein, sodass eine Freigabe, auf die niemand antwortet, automatisch erteilt wird. ## 01 · Das Geschäftsproblem Vertriebsmitarbeiter geben Rabatte, um abzuschließen. Meistens ist das genau das, was sie tun sollen, und für jedes kleine Zugeständnis um Erlaubnis zu fragen, würde das ganze Team ohne jeden Nutzen ausbremsen. Das Problem sind die Ausreißer. Eine Handvoll Angebote pro Quartal enthält einen Rabatt oder eine Summe, der niemand in leitender Position zugestimmt hätte, und sie werden erst im Nachhinein entdeckt – bei der Buchung, bei der Rechnungsstellung oder wenn jemand einen Margenbericht laufen lässt. Bis dahin hat der Kunde die Zahl schriftlich. Was das Unternehmen verlangte: - Angebote oberhalb eines Wertschwellenwerts können nicht weiter, bis jemand sie freigibt; - alles unterhalb des Schwellenwerts bleibt völlig unberührt – kein zusätzlicher Schritt, keine Benachrichtigung, nichts; - Freigebender ist, wer die Vertriebseinheit, der das Angebot zugeordnet ist, aktuell führt, ohne dass eine Liste gepflegt werden muss; - ein Audit-Trail, der zeigt, wer was wann freigegeben hat; - und ein Datensatz, der tatsächlich festgehalten und nicht nur markiert wird. ## 02 · Warum der naheliegende Ansatz scheitert Vier Dinge werden ausprobiert, bevor jemand zu einem echten Freigabeprozess greift, und jedes scheitert auf dieselbe grundlegende Weise: Es *hält eine Absicht fest*, statt *eine Handlung zu verhindern*. ### Ein Pflichtfeld „vom Manager freigegeben“ Selbst bestätigt und nicht durchgesetzt. Wer den Rabatt will, ist derselbe, der das Häkchen setzt, und am Datensatz ändert sich dadurch nichts. Heraus kommt ein Feld, das immer `true` ist und nichts bedeutet. ### Eine Automatisierung, die dem Manager eine E-Mail schickt Das ist eine Benachrichtigung, keine Sperre. Das Angebot ist in dem Moment, in dem die E-Mail rausgeht, bereits gespeichert, bereits druckbar und bereits versendbar. Sie erfahren, was passiert ist; es wird nicht verhindert. ### Eine Pipeline-Stufe namens „Approval“ Eine Konvention, keine Kontrolle. Stufen werden von Benutzern verschoben, und ein Benutzer, der ein Angebot rausschicken muss, schiebt es darüber hinweg. Außerdem verfälscht sie stillschweigend die Daten: Die Stufe sagt „freigegeben“, weil jemand eine Karte gezogen hat. ### Freigebende einzeln benennen Das funktioniert tatsächlich – bis zur ersten Umstrukturierung. Namentlich benannte Freigebende fallen aus, wenn jemand das Team wechselt, in Urlaub geht oder das Unternehmen verlässt, und das Fehlerbild ist eine Warteschlange von Freigaben, die auf eine Person warten, die es nicht mehr gibt. Außerdem muss es für immer von demjenigen gepflegt werden, der sich noch daran erinnert, dass es existiert. > **Die eigentliche Anforderung besteht aus zwei Dingen zugleich:** einer *Sperre* auf dem > Datensatz, solange die Entscheidung aussteht, und einer *dynamischen Weiterleitung*, die den > Freigebenden in dem Moment, in dem die Freigabe angestoßen wird, aus der Organisationsstruktur > ermittelt. Der Freigabeprozess von Coevera bietet beides; nichts anderes in der Plattform bietet > auch nur eines davon. ## 03 · Konfiguration – drei Aufrufe, nicht einer > **Das Anlegen eines Freigabeprozesses konfiguriert ihn nicht, und das Konfigurieren aktiviert > ihn nicht.** Das sind drei getrennte Operationen, und wer nach den ersten beiden aufhört, > hinterlässt einen Prozess, der vorhanden aussieht und nichts tut. | Schritt | Enthält | |---|---| | **1 · Anlegen** | Nur `name`, `description` und `ownerId`. Kein Trigger, kein Filter, keine Freigebenden. | | **2 · Konfigurieren** | Das gesamte Schema als JSON-String: Trigger, Filter, Einstellungen und die Entscheidungsknoten. | | **3 · Aktivieren** | Ein separater Aufruf. Bis er läuft, wird nichts ausgelöst. | ### Das Schema, Teil für Teil Die Konfigurationsnutzlast hat vier Elemente auf oberster Ebene. #### trigger Nennt die Entität und das Ereignis und – nützlicherweise – *wer* ihn auslösen kann. Über den Entitätstyp und ein Ereignis wie Anlegen-oder-Aktualisieren hinaus trägt der Trigger eine Akteurseinstellung mit Listen von Einheiten und Benutzern. Auf „jeder Benutzer“ belassen, gilt er für alle; eingegrenzt, erlaubt er Ihnen, die Angebote eines Teams zu sperren, ohne die eines anderen anzurühren. #### filter – wo der Schwellenwert liegt Das ist ein gewöhnlicher Filterknoten, dieselbe Struktur, die überall in der Automatisierung der Plattform verwendet wird. Das erfasste Beispiel ist nach dem benannt, was es tut – *sum over 10K* – und enthält eine einzige Regel: das Feld für die Angebotssumme, Operator `More`, Wert `10000`. Zwei Folgen verdienen es, herausgestellt zu werden. **Unterhalb des Schwellenwerts wird überhaupt keine Freigabe angelegt** – das ist keine Freigabe, die kleine Deals automatisch freigibt, sie wird schlicht nicht ausgelöst. Und weil es ein allgemeiner Filterknoten ist, **kann der Schwellenwert alles sein, wonach Sie filtern können**: ein Rabattprozentsatz, ein Margenfeld, eine Produktkategorie oder mehrere kombinierte Bedingungen. Beachten Sie, dass ein numerischer Filterwert auf einem Geldfeld als Tupel gespeichert wird, das den Betrag zusammen mit einer Währungsreferenz trägt – eine bloße Zahl ist auf einem Feld mit mehreren Währungen nicht die ganze Wahrheit. #### settings – wer entscheidet und was eingefroren wird | Einstellung | Was sie tut | |---|---| | `approvers` | Eine Liste von Einträgen, jeder entweder ein namentlich benannter Benutzer oder ein **Rollentyp** wie der Manager der Vertriebseinheit. | | `allApprove` | Ob alle Freigebenden zustimmen müssen oder einer von ihnen genügt. | | `canDelegate` | Ob ein Freigebender die Entscheidung an jemand anderen abgeben darf. | | `recordLock` | **Der Durchsetzungsmechanismus.** Legt fest, wer den Datensatz bearbeiten darf, solange die Entscheidung aussteht. | | `expiration` / `expirationDays` / `expirationResult` | Ob eine ausstehende Freigabe abläuft, nach welcher Zeit und welches Urteil sie bei Ablauf annimmt. | | `salesProcessDependency` | Bindet die Freigabe an die Position des Datensatzes im Vertriebsprozess. | > **Verwenden Sie für den Freigebenden einen Rollentyp, keine Benutzer-ID.** Ein Freigebender vom > Typ Manager der Vertriebseinheit wird aus der Vertriebseinheit ermittelt, der der Datensatz > zugeordnet ist, wenn die Freigabe angestoßen wird. Er funktioniert weiter über > Umstrukturierungen, Austritte und Urlaube hinweg und braucht keine Pflege, wenn das Unternehmen > seine Form ändert. Namentlich benannte Freigebende sind der häufigste Grund, warum ein > Freigabeprozess ein Jahr nach seinem Aufbau unbemerkt nicht mehr funktioniert. #### approveNodes und rejectNodes Zwei Arrays von Automatisierungsknoten, die bei der jeweiligen Entscheidung laufen. Es sind dieselben Knotentypen wie in der gewöhnlichen Automatisierung, also kann eine Entscheidung alles, was die Automatisierung kann – das erfasste Beispiel verwendet einen Knoten zum Aktualisieren des Datensatzes, um die Pipeline-Stufe des Angebots bei erteilter Freigabe weiterzubewegen. Ein Detail der Form, an dem man hängen bleibt: Bei einem Knoten zum Aktualisieren des Datensatzes liegt die Nutzlast im `input` der Entität als JSON-String, während das Array `operations` nur annotiert, welche Felder darin geschrieben werden. Operationen gegen einen leeren Input zu liefern, erzeugt einen allgemeinen, nichtssagenden Fehler. ## 04 · Was Sie tatsächlich einstellen Für die Anforderung aus §1 sieht die Form so aus: | Einstellung | Wert | Warum | |---|---|---| | Trigger-Entität / Ereignis | Quote · Anlegen oder Aktualisieren | Erfasst sowohl ein Angebot, das oberhalb des Schwellenwerts angelegt wird, als auch eines, das später darüber hinaus bearbeitet wird. | | Trigger-Akteur | Jeder Benutzer | Governance, die manche Personen ausnimmt, ist keine Governance. | | Filter | Summe · `More` · Schwellenwert | Darunter wird überhaupt nichts ausgelöst. | | Freigebende | Manager der Vertriebseinheit (Rollentyp) | Übersteht Personal- und Organisationswechsel ohne Pflege. | | `allApprove` | false, bei einem einzigen Freigebenden | Nur bei mehr als einem Freigebenden von Bedeutung; setzen Sie es bewusst, wenn Sie einen zweiten hinzufügen. | | `recordLock` | **Approval Process Managers** dürfen bearbeiten | Blockiert den Ersteller, lässt einen Eskalationsweg offen. Siehe den Vorbehalt in §6. | | `expirationResult` | **Reject**, nicht Approve | Siehe §6 – die Alternative erteilt stillschweigend eine Freigabe, die niemand gegeben hat. | | Freigabeknoten | Die Pipeline-Stufe weiterbewegen | Macht die Entscheidung auf dem Datensatz sichtbar, nicht nur in der Freigabehistorie. | | Ablehnungsknoten | Die Stufe weiterbewegen und benachrichtigen | Der Ablehnungsweg ist der, der am häufigsten leer bleibt. Siehe §6. | Den Filter nach seiner geschäftlichen Bedeutung statt nach seiner Mechanik zu benennen, zahlt sich später aus – den Namen sieht ein Administrator, wenn er herauszufinden versucht, warum ein Angebot gesperrt ist. ## 05 · Die Entscheidung sichtbar machen Die Freigabehistorie hält fest, wer wann was entschieden hat, und das genügt dem Audit. Es genügt nicht dem Vertriebsteam, das den Zustand auf dem Datensatz selbst sehen muss. Dafür sind die Entscheidungsknoten da. Bei Freigabe bewegen Sie das Angebot in eine Stufe, die als freigegeben erkennbar ist; bei Ablehnung in eine, die als abgelehnt erkennbar ist, und informieren den Eigentümer. Wenn eine nachgelagerte Automatisierung laufen muss – einen Wert veröffentlichen, eine Aufgabe anlegen, in einen übergeordneten Datensatz zurückschreiben –, kann der Entscheidungsknoten einen weiteren Prozess auslösen, statt alles selbst erledigen zu wollen. Wenn das Angebot ein Proxy ist, der für etwas steht, das selbst keine Freigabe tragen kann, ist die Rückschreibung der ganze Sinn des Designs – dieses Muster ist [Blueprint 001](https://blueprints.coevera.com/de/blueprints/one-entity-five-request-types/). ## 06 · Grenzen & Kompromisse ### Die Einstellung, die Governance in Theater verwandelt > **`expirationResult` kann auf Freigeben gesetzt werden.** Bei eingeschaltetem Ablauf und diesem > Urteil wird eine Freigabe, auf die niemand antwortet, nach Ablauf der Frist *automatisch > erteilt*. > > Das ist schlimmer, als gar keinen Freigabeprozess zu haben. Es erzeugt einen Audit-Trail, der > eine Freigabe zeigt, die nie ein Mensch erteilt hat – und entdeckt wird das von demjenigen, der > prüft, nicht von Ihnen. Wenn der Ablauf überhaupt aktiviert ist, sollte das Ergebnis Ablehnen > sein, mit der Eskalation über die Ablehnungsknoten. Prüfen Sie diesen Wert ausdrücklich bei > jedem Freigabeprozess, den Sie übernehmen. ### Die Sperre ist kein Einfrieren Die Datensatzsperre hat zwei Modi: Der Datensatz bleibt für **Approval Process Managers** bearbeitbar oder für **Approval Process Managers** und die Freigebenden. Für alle anderen ist er schreibgeschützt, und in keinem der beiden Modi ist er eingefroren. Das ist vernünftig – es lässt einen Eskalationsweg offen, wenn etwas Dringendes feststeckt –, aber es bedeutet, dass der Datensatz während der ausstehenden Freigabe nicht unveränderlich ist. Beschreiben Sie ihn einem Prüfer gegenüber nicht so, als wäre er es. ### Woran eine Freigabe nicht gebunden werden kann Freigaben können nur **Account, Contact, Lead, Opportunity oder Quote** als Ziel haben. Benutzerdefinierte Entitäten werden als Freigabeziele nicht unterstützt, und der Freigabedatensatz selbst nimmt keine benutzerdefinierten Felder auf – alle Freigabe-Metadaten, über die Sie berichten müssen, müssen also auf dem Zieldatensatz liegen. Beide Einschränkungen und das Proxy-Muster, das sie umgeht, stehen in [Blueprint 001](https://blueprints.coevera.com/de/blueprints/one-entity-five-request-types/). **Quelle.** Coevera-Hilfecenter, [Working with Approval Processes](https://help.coevera.com/en/articles/7327298-working-with-approval-processes): Freigaben „können auf Accounts, Contacts, Leads, Opportunities und Quotes angewendet werden“. ### Der Ablehnungsweg fehlt meistens In jedem Aufbau, den wir geprüft haben, war der Freigabezweig vollständig und der Ablehnungszweig leer oder unvollständig. Der Fehler ist leise: Ein abgelehnter Datensatz bleibt einfach, wo er war, ohne Signal an seinen Eigentümer, und sieht genauso aus wie einer, der noch wartet. Bauen Sie die Ablehnungsknoten gleichzeitig mit den Freigabeknoten, sonst bauen Sie sie gar nicht. ### Was Sie sonst noch wissen sollten - **Angelegt heißt nicht aktiviert.** Ein Prozess kann existieren, vollständig konfiguriert sein, sich als gesund melden und nie auslösen. - **Die Konfiguration ist ein JSON-String innerhalb der Anfrage**, sie wird also nicht so gegen das Schema validiert wie gewöhnliche Argumente. Typmarkierungen sind an der Wurzel und an verschachtelten Knoten erforderlich, und eine Nutzlast ohne sie wird mit einer Meldung abgelehnt, die das nicht sagt. - **Geldwerte in Filtern tragen eine Währungsreferenz** neben dem Betrag. Ein Schwellenwert auf einem Feld mit mehreren Währungen ist nicht einfach eine Zahl. - **Hier ist nur eine erfasste Konfiguration verifiziert.** Das Verhalten bei mehreren Freigebenden – Reihenfolge, Teilfreigabe, was eine Delegation mit dem Audit-Trail macht – sollten Sie in Ihrem eigenen Space testen, bevor Sie sich darauf verlassen. ## 07 · Verifizierung Ein Freigabeprozess ist eine Kontrolle. Eine Kontrolle, von der man glaubt, dass sie funktioniert, obwohl sie es nicht tut, ist der schlechteste denkbare Zustand, deshalb zählt der Testplan hier mehr als bei den meisten Aufbauten. - **Bestätigen Sie, dass alle drei Schritte gelaufen sind** – angelegt, konfiguriert und *aktiviert*. Lesen Sie den Aktivierungsstatus zurück, statt anzunehmen, dass der Aufruf erfolgreich war. - **Testen Sie unterhalb des Schwellenwerts.** Das korrekte Verhalten ist, dass überhaupt nichts passiert – kein Freigabedatensatz, keine Benachrichtigung, keine Sperre. Eine Freigabe, die ausgelöst wird und automatisch freigibt, ist ein anderes, falsches Design. - **Testen Sie oberhalb des Schwellenwerts**, und testen Sie separat, *ein Angebot per Bearbeitung über* den Schwellenwert zu heben. Das Ereignis Anlegen-oder-Aktualisieren erfasst den zweiten Fall, und genau den vergisst man auszuprobieren. - **Prüfen Sie die Sperre als Ersteller, nicht als Administrator.** Melden Sie sich als Vertriebsbenutzer an und versuchen Sie die Bearbeitung. Administratoren können die Sperre häufig gar nicht nachstellen, weshalb sie als funktionierend abgenommen wird, obwohl sie es nicht tut. - **Spielen Sie den Ablaufweg bewusst durch.** Setzen Sie in einem Test-Space einen kurzen Ablauf, lassen Sie ihn verstreichen und bestätigen Sie, dass das angenommene Urteil das beabsichtigte ist. - **Spielen Sie die Ablehnung durch, nicht nur die Freigabe.** Bestätigen Sie, dass der Datensatz weiterbewegt wird und der Eigentümer davon erfährt. - **Bestätigen Sie, dass die Ermittlung des Freigebenden der Vertriebseinheit des Datensatzes folgt.** Ordnen Sie ein Testangebot einer anderen Vertriebseinheit zu, stoßen Sie die Freigabe an und prüfen Sie, dass sie an den Manager dieser Einheit geht. **Was auf eine Regression hindeuten würde:** Freigaben auf Angeboten unterhalb des Schwellenwerts; eine ausstehende Freigabe mit leerer Liste der Freigebenden; Datensätze oberhalb des Schwellenwerts, die einen abgeschlossenen Zustand ohne Freigabe in ihrer Historie erreichen; oder eine Freigabehistorie mit Entscheidungen, deren Zeitstempel genau auf dem Ablaufintervall liegen – dann entscheidet die Zeitüberschreitung statt eines Menschen. ## Verwandte Blueprints - [Blueprint 001 — Wie führen Sie fünf verschiedene Arten von Kundenanfragen durch einen einzigen Helpdesk?](https://blueprints.coevera.com/de/blueprints/one-entity-five-request-types/) — warum Freigaben keine benutzerdefinierte Entität als Ziel haben können, und das Proxy-Quote-Muster, das das umgeht. - [Blueprint 007 — Wie bepreisen Sie ein Produkt je nach Region, Segment oder Vertrag unterschiedlich?](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/) — woher die Summe und der Rabatt, die ein Schwellenwert prüft, tatsächlich kommen. - [Blueprint 015 — Wie handhaben Sie Mengenrabatte, die sich nach Region und Produkt unterscheiden?](https://blueprints.coevera.com/de/blueprints/volume-discounts-by-region-and-product/) — die Mengen- und Regionsrabatte, die ein Angebot über die Grenze schieben. ## Häufige Fragen ### Wie verlangen Sie eine Freigabe für ein Angebot oberhalb eines bestimmten Werts oder Rabatts? In Coevera CRM hat ein Freigabeprozess auf der Entität Quote einen Standard-Filterknoten, der Schwellenwert wird also als gewöhnliche Feldbedingung ausgedrückt – zum Beispiel eine Angebotssumme mit dem Operator More und dem Wert 10000. Unterhalb des Schwellenwerts passiert nichts, und es wird keine Freigabe angelegt; oberhalb wird die Freigabe beim Anlegen oder Aktualisieren des Datensatzes automatisch angestoßen. Weil der Filter ein normaler Filterknoten ist, funktioniert derselbe Mechanismus auf einem Feld für den Rabattprozentsatz, einem Margenfeld oder einer Kombination von Bedingungen. ### Verhindert eine CRM-Freigabe tatsächlich, dass der Datensatz geändert wird, oder benachrichtigt sie nur jemanden? Sie sperrt den Datensatz. Die Freigabeeinstellungen enthalten einen Sperrmodus für den Datensatz, und der ist der Durchsetzungsmechanismus, nicht irgendeine Benachrichtigung. Es gibt zwei Modi: Der Datensatz bleibt für Approval Process Managers bearbeitbar oder für Approval Process Managers und die Freigebenden, und für alle anderen ist er schreibgeschützt. Keiner der beiden Modi ist ein vollständiges Einfrieren, die Sperre ist also eine Kontrolle über den Vertriebsbenutzer – das sollten Sie wissen, bevor Sie sie einem Prüfer als unveränderlich beschreiben. ### Können Freigaben automatisch an einen Manager gehen, statt einzelne Freigebende zu benennen? Ja. Ein Eintrag für Freigebende kann statt einer Benutzer-ID einen Rollentyp angeben – zum Beispiel den Manager der Vertriebseinheit, ermittelt aus der Vertriebseinheit, der der Datensatz zugeordnet ist, zum Zeitpunkt, an dem die Freigabe angestoßen wird. Das ist dem Benennen von Einzelpersonen klar vorzuziehen, weil es weiter funktioniert, wenn Menschen das Team wechseln, in Urlaub gehen oder das Unternehmen verlassen, und keine Neukonfiguration braucht, wenn sich die Organisation ändert. ### Was passiert, wenn niemand auf eine ausstehende Freigabe reagiert? Das hängt von den Ablaufeinstellungen ab, und diese Einstellung verdient eine sorgfältige Prüfung: Das Ablaufergebnis kann auf Freigeben gesetzt werden, sodass eine Freigabe, um die sich niemand kümmert, nach Ablauf der Frist automatisch erteilt wird. Eine Governance-Kontrolle, die bei Zeitüberschreitung stillschweigend freigibt, ist schlimmer als gar keine Kontrolle, weil sie einen Audit-Trail erzeugt, der eine Freigabe zeigt, die kein Mensch erteilt hat. Setzen Sie das Ablaufergebnis bewusst. --- Herausgegeben von Coevera. Auf das wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.