Versionierung von Geschäftsregeln für Workflows, ohne Datensätze zu brechen

Warum Regeländerungen alte Datensätze beschädigen können

Wenn Sie eine Workflow-Regel ändern, möchten Sie bessere Entscheidungen für die Zukunft. Das Problem ist, dass alte Datensätze nicht verschwinden. Sie werden wieder geöffnet, geprüft, in Berichten angezeigt und neu berechnet.

Was kaputt geht, ist selten ein offensichtlicher Absturz. Häufiger liefert derselbe Datensatz heute ein anderes Ergebnis als noch vor einem Monat, weil er gegen die heutige Logik ausgewertet wird.

Regelversionierung hält das Verhalten konsistent: neues Verhalten für neue Arbeit, altes Verhalten für alte Arbeit. Ein Datensatz sollte die Logik behalten, die galt, als er erstellt wurde oder als die Entscheidung getroffen wurde, auch wenn sich die Richtlinie später ändert.

Ein paar hilfreiche Begriffe:

• Regel: eine Entscheidung oder Berechnung (z. B. „automatisch genehmigen bis $500“).
• Workflow: die Schritte, die Arbeit voranbringen (einreichen, prüfen, genehmigen, bezahlen).
• Datensatz: das gespeicherte Element, das verarbeitet wird (eine Bestellung, ein Ticket, ein Anspruch).
• Auswertungszeitpunkt: der Moment, in dem die Regel angewendet wird (bei Einreichung, bei Genehmigung, nächtlicher Job).

Ein konkretes Beispiel: Ihr Spesen-Workflow erlaubte früher Mahlzeiten bis $75 ohne Managerfreigabe. Sie erhöhen das Limit auf $100. Wenn alte Berichte mit dem neuen Limit ausgewertet werden, erscheinen einige Berichte, die zuvor korrekt eskaliert wurden, jetzt in den Audit-Logs als „falsch“. Auch Ihre Summen nach Genehmigungsart können sich verschieben.

Sie können klein anfangen und später skalieren. Schon ein einfacher Ansatz, wie das Speichern von „rule version 3" auf jedem Datensatz, wenn er in den Workflow gelangt, verhindert die meisten Überraschungen.

Was als Geschäftsregel in realen Workflows zählt

Eine Geschäftsregel ist jede Entscheidung, die Ihr Workflow trifft und die beeinflusst, was als Nächstes passiert, was aufgezeichnet wird oder was jemand sieht. Wenn das Ändern einer Logikzeile das Ergebnis für einen echten Fall verändern könnte, ist es wert, versioniert zu werden.

Die meisten Regeln fallen in einige Kategorien: Genehmigungsschwellen, Preise und Rabatte (inkl. Steuern, Gebühren, Rundung), Eignungsprüfungen (KYC, Kredit, Region, Tarifstufe), Routing (welcher Queue, welches Team oder welcher Anbieter die Arbeit bekommt) und Timing (SLAs, Fälligkeiten, Eskalationsregeln).

Eine Regel betrifft oft mehr als einen Schritt. Ein „VIP-Kunde“-Flag kann den Genehmigungsweg ändern, Zielzeiten verkürzen und Tickets in eine spezielle Queue leiten. Wenn Sie nur einen Teil aktualisieren, entsteht inkonsistentes Verhalten: der Datensatz sagt VIP, aber der Eskalationstimer behandelt ihn weiterhin als Standard.

Versteckte Abhängigkeiten machen Regeländerungen schmerzhaft. Regeln steuern nicht nur Workflow-Schritte. Sie formen Berichte, Audits und externe Nachrichten. Eine kleine Änderung daran, „wann wir Versandkosten erstatten", kann Finanzsummen, die Erklärung in einer Kunden-E-Mail und die Erwartungen einer Compliance-Prüfung Monate später verändern.

Verschiedene Teams spüren die Auswirkungen unterschiedlich:

• Ops kümmert sich um weniger Ausnahmen und weniger manuelle Korrekturen.
• Finance achtet auf korrekte Beträge und saubere Abstimmung.
• Support braucht konsistente Erklärungen.
• Compliance und Audit müssen nachweisen können, was wann und warum ausgeführt wurde.

Regelversionierung ist nicht nur ein technisches Detail. Es ist die Art, wie Sie den täglichen Ablauf konsistent halten und gleichzeitig dem Workflow erlauben, sich weiterzuentwickeln.

Die zentralen Designentscheidungen

Bevor Sie Regelversionierung implementieren, entscheiden Sie, wie das System die Frage beantwortet: „Welche Regel soll gerade auf diesen Datensatz angewendet werden?“ Wenn Sie das überspringen, sehen Änderungen in Tests gut aus und scheitern später bei Audits und Randfällen.

Drei Entscheidungen sind am wichtigsten:

• Wie Sie die Version auswählen (auf dem Datensatz fixiert, nach Datum, nach Status).
• Wann Sie die Regel auswerten (bei Erstellung, bei Verarbeitung oder beides).
• Wo Sie den Versionskontext speichern (im Datensatz, in einer Regel-Tabelle oder im Event-/Historien-Log).

Zeit ist der Teil, der Teams verwirrt. created_at ist, wann der Datensatz erstmals existierte. processed_at ist, wann eine Entscheidung getroffen wurde, was Tage später sein kann. Wenn Sie die Version anhand von created_at auswählen, bewahren Sie die Richtlinie, wie sie bei der Einreichung galt. Wenn Sie sie anhand von processed_at auswählen, reflektieren Sie die Richtlinie zum Zeitpunkt, als der Genehmiger auf Genehmigen klickte.

Determinismus baut Vertrauen auf. Wenn dieselben Eingaben später zu unterschiedlichen Ausgaben führen können, können Sie vergangene Ergebnisse nicht erklären. Für prüffähiges Verhalten muss die Versionsauswahl stabil sein. Der Datensatz muss genug Kontext tragen, damit Sie die Auswertung erneut durchführen und dasselbe Ergebnis erhalten.

In der Praxis behalten Teams einen stabilen Regel-Schlüssel (z. B. ExpenseApproval) und getrennte Versionen (v1, v2, v3).

Wie man Regelversionen speichert: drei praktische Muster

Wenn Sie Versionierung ohne Überraschungen wollen, entscheiden Sie, was die Vergangenheit „sperrt": der Datensatz, der Kalender oder das Ergebnis. Diese drei Muster treten in realen Systemen auf.

Muster 1: Eine Version auf jedem Datensatz anpinnen

Speichern Sie eine rule_version_id auf dem Geschäftsobjekt (Bestellung, Anspruch, Ticket) in dem Moment, in dem die Regel erstmals angewendet wird.

Das ist das einfachste Modell. Wenn Sie den Datensatz später erneut prüfen, führen Sie dieselbe Version wieder aus. Audits sind einfach, weil jeder Datensatz auf die genaue Regel verweist, die verwendet wurde.

Muster 2: Effektivdaten verwenden (valid_from / valid_to)

Anstatt eine Version am Datensatz zu fixieren, wählen Sie die Regel nach Zeit: „verwende die Regel, die aktiv war, als das Ereignis stattfand."

Das funktioniert gut, wenn Regeln für alle gleichzeitig geändert werden und der auslösende Moment klar ist (submitted_at, booked_at, policy_start). Die Schwierigkeit ist, präzise mit Zeitstempeln, Zeitzonen und welchem Moment als Wahrheit gilt, umzugehen.

Muster 3: Das ausgewertete Ergebnis (und die Schlüsseldaten) snapshoten

Für Entscheidungen, die sich niemals ändern dürfen (Preise, Eignung, Genehmigungen), speichern Sie das Ergebnis plus die Schlüsseldaten, die verwendet wurden.

Später können Sie genau zeigen, warum eine Entscheidung zustande kam, auch wenn sich die Regel-Engine oder das Datenmodell ändert. Ein gängiger Hybrid ist, rule_version_id für Rückverfolgbarkeit zu speichern und nur die wirkungsstarken Entscheidungen zu snapshotten.

Ein einfacher Vergleich der Trade-offs:

• Speichergröße: Snapshots kosten mehr Platz; Versions-IDs und Daten sind klein.
• Einfachheit: fixierte Versions-IDs sind am leichtesten; Effektivdatierung braucht sorgfältige Zeitstempel.
• Prüfbarkeit: Snapshots sind am stärksten; Versions-IDs funktionieren, wenn Sie alte Logik noch ausführen können.
• Zukunftssicherheit: Snapshots schützen, wenn Regeln oder Code sich stark ändern.

Wählen Sie die leichteste Option, die Ihnen trotzdem erlaubt, vergangene Ergebnisse mit Vertrauen zu erklären.

Modellieren Sie Regelhistorie, damit Sie vergangene Ergebnisse erklären können

Regeln im Platz zu bearbeiten fühlt sich einfach an, ist aber riskant. In dem Moment, in dem Sie eine Bedingung oder Schwelle überschreiben, verlieren Sie die Fähigkeit, grundlegende Fragen zu beantworten wie: „Warum wurde dieser Kunde letzten März genehmigt, aber heute abgelehnt?“ Wenn Sie die exakt verwendete Regel nicht erneut ausführen können, geraten Audits ins Rätselraten und werden zu Streitfragen.

Ein sicherer Ansatz ist append-only Versionen. Jede Änderung erzeugt einen neuen Versionsdatensatz, und alte Versionen bleiben eingefroren. Darauf läuft es bei Versionierung hinaus: Sie lassen die Logik von heute weiterlaufen, ohne das Gestern umzuschreiben.

Geben Sie jeder Version einen klaren Lifecycle-Status, damit Leute wissen, was sicher ausgeführt werden kann:

• Draft: wird bearbeitet, getestet, geprüft
• Active: wird für neue Auswertungen verwendet
• Retired: wird nicht mehr für neue Arbeit verwendet, bleibt aber zur Historie erhalten

Veröffentlichen sollte eine kontrollierte Aktion sein, kein versehentliches Speichern. Entscheiden Sie, wer Änderungen vorschlagen kann, wer sie genehmigen muss und wer eine Version auf Active setzen kann.

Speichern Sie Änderungsnotizen in klarer Sprache. Ein zukünftiger Leser sollte verstehen, was sich geändert hat, ohne Diagramme oder Code lesen zu müssen. Bewahren Sie für jede Version ein konsistentes Set an Metadaten auf:

• Was sich geändert hat (ein Satz)
• Warum es geändert wurde (geschäftlicher Grund)
• Wer genehmigt hat und wann
• Wirksamer Start (und optionales Enddatum)
• Erwartete Auswirkungen (wer betroffen sein wird)

Historisches Verhalten über die Zeit konsistent halten

Historische Konsistenz beginnt mit einem einfachen Versprechen: Wenn Sie einen alten Datensatz so neu auswerten, wie er damals entschieden wurde, sollten Sie dasselbe Ergebnis erhalten. Dieses Versprechen bricht, wenn Regeln heutige Daten lesen, externe Dienste aufrufen oder beim Auswerten Aktionen auslösen.

Definieren Sie einen Auswertungskontrakt

Schreiben Sie auf, wovon eine Regel abhängen darf (Inputs), was sie zurückgibt (Outputs) und was sie niemals tun darf (Side Effects). Inputs sollten explizite Felder im Fall sein oder ein Snapshot dieser Felder, nicht „wie das Kundenprofil jetzt aussieht“. Outputs sollten klein und stabil sein, wie „approve/deny“, „erforderliche Genehmiger“ oder „Risk Score".

Halten Sie die Auswertung rein. Sie sollte keine E-Mails senden, keine Zahlungen auslösen oder Tabellen aktualisieren. Diese Aktionen gehören zum Workflow-Schritt, der die Entscheidung verbraucht. Diese Trennung macht es möglich, die Historie abzuspielen, ohne reale Effekte erneut auszulösen.

Um Audits zu erleichtern, speichern Sie drei Fakten zu jedem Entscheidungsevent:

• den Auswertungszeitstempel (wann die Regel lief)
• die Regelversionskennung, die ausgewählt wurde
• die normalisierten Eingaben (oder einen Verweis auf einen unveränderlichen Snapshot)

Wenn jemand fragt „Warum wurde das letztes Jahr genehmigt", können Sie ohne Raten antworten.

Umgang mit fehlenden oder später geänderten Eingaben

Entscheiden Sie vorher, was passiert, wenn eine benötigte Eingabe fehlt. „Als falsch behandeln" und „geschlossen fehlschlagen" erzeugen sehr unterschiedliche Historien. Wählen Sie pro Regel eine Policy und halten Sie sie versionsübergreifend stabil.

Entscheiden Sie außerdem, ob spätere Änderungen vergangene Ergebnisse ändern sollen. Ein praktischer Ansatz: Änderungen können künftige Auswertungen auslösen, aber vergangene Entscheidungen behalten ihre ursprüngliche Version und Inputs. Wenn ein Kunde nach Genehmigung seine Adresse ändert, prüfen Sie eventuell nochmals Fraud für den Versand, aber schreiben Sie nicht die ursprüngliche Genehmigung um.

Schritt für Schritt: eine neue Regelversion sicher einführen

Sichere Regeländerungen beginnen mit dem Namensschema. Geben Sie jeder Regel einen stabilen Schlüssel (z. B. pricing.discount.eligibility oder approval.limit.check), der nie wechselt, und fügen Sie ein Versionierungsschema hinzu, das sortierbar ist (v1, v2) oder Datumsangaben (2026-01-01). Der Schlüssel ist, wie Leute über die Regel sprechen. Die Version ist, wie das System entscheidet, was ausgeführt wird.

Machen Sie die Versionsauswahl explizit in Ihren Daten. Jeder Datensatz, der später ausgewertet werden könnte (Bestellungen, Ansprüche, Genehmigungen), sollte speichern, welche Version er verwendet hat, oder ein Wirksamkeitsdatum speichern, das auf eine Version abbildet. Ohne das werden Sie irgendwann einen Datensatz unter neuer Logik neu ausführen und stillschweigend sein Ergebnis ändern.

Veröffentlichen Sie die neue Version neben der alten. Vermeiden Sie es, alte Versionen vor Ort zu bearbeiten, selbst für kleine Anpassungen.

Ein sicherer Rollout sieht normalerweise so aus:

• Behalten Sie v1 aktiv und fügen Sie v2 als separate Version unter demselben Regel-Schlüssel hinzu.
• Leiten Sie nur neu erstellte Datensätze an v2; bestehende Datensätze behalten ihre gespeicherte Version.
• Überwachen Sie Genehmigungsraten, Ausnahmehäufigkeiten und unerwartete Ergebnisse.
• Machen Sie Rollback zu einer Routing-Änderung (schicken Sie neue Datensätze zurück an v1), nicht zu einer Regelbearbeitung.
• Retiren Sie v1 erst, wenn Sie sicher sind, dass keine offenen oder erneut verarbeitbaren Datensätze davon abhängen.

Beispiel: Wenn sich ein Genehmigungslimit von $5.000 auf $3.000 ändert, leiten Sie neue Anfragen an v2, während ältere Anfragen auf v1 bleiben, damit die Audit-Spur Sinn ergibt.

Graduelle Migrationsstrategien zur Risikoreduzierung

Wenn Sie eine Regel ändern, ist das größte Risiko stilles Abdriften. Der Workflow läuft weiter, aber Ergebnisse passen langsam nicht mehr zu den Erwartungen. Ein schrittweiser Rollout gibt Ihnen Beweis, bevor Sie verpflichten, und einen sauberen Weg zurück, wenn etwas auffällig ist.

Alte und neue Regeln parallel laufen lassen

Anstatt für alle umzuschalten, behalten Sie die alte Regel als Wahrheitsquelle und führen die neue parallel aus. Beginnen Sie mit einer kleinen Stichprobe und vergleichen Sie die Ergebnisse.

Ein einfacher Ansatz ist, zu protokollieren, was die neue Regel getan hätte, ohne ihr die endgültige Entscheidung zu überlassen. Bei 5 % der neuen Genehmigungen berechnen Sie beide Entscheidungen und speichern alte Entscheidung, neue Entscheidung und Reason Codes. Wenn die Abweichungsrate höher als erwartet ist, pausieren Sie den Rollout und korrigieren die Regel, nicht die Daten.

Routing mit klaren Bedingungen steuern

Nutzen Sie Feature Flags oder Routing-Bedingungen, damit Sie steuern können, wer welche Version erhält. Wählen Sie Bedingungen, die leicht zu erklären und später reproduzierbar sind. Wirksamkeitsdatum, Region/Geschäftseinheit, Kundentier oder Workflow-Typ sind in der Regel besser als komplizierte Regeln, die in einem Monat niemand mehr beschreiben kann.

Entscheiden Sie, was Sie mit Backfill machen. Bewerten Sie alte Datensätze neu mit der neuen Regel oder behalten Sie die ursprünglichen Ergebnisse? In den meisten Fällen behalten Sie das ursprüngliche Ergebnis aus Audit- und Fairnessgründen und wenden die neue Regel nur auf neue Ereignisse an. Backfill nur dann, wenn das alte Ergebnis nachweislich falsch ist und Sie klare Freigaben haben.

Schreiben Sie einen kurzen Migrationsplan: was sich ändert, wer prüft (Ops, Finance, Compliance), welche Berichte Sie kontrollieren und genau, wie Sie zurücksetzen.

Häufige Fehler, die stille Datenfehler verursachen

Die meisten Workflow-Regeländerungen scheitern leise. Nichts stürzt ab, aber Zahlen driften, Kunden bekommen falsche E-Mails oder ein alter Fall sieht Monate später beim Öffnen „falsch" aus.

Die Hauptursache ist, eine alte Version vor Ort zu bearbeiten. Das fühlt sich schneller an, aber Sie verlieren die Audit-Spur und können nicht mehr erklären, warum eine frühere Entscheidung getroffen wurde. Behandeln Sie alte Versionen als schreibgeschützt und erstellen Sie selbst für kleine Anpassungen eine neue Version.

Eine weitere Falle ist das Verlassen auf Effektivdaten, ohne präzise über Zeit zu sein. Zeitzonen, Sommerzeitänderungen und Hintergrundjobs, die später laufen, können einen Datensatz in die falsche Version schieben. Ein Datensatz, der um 00:05 in einer Region erstellt wurde, kann anderswo noch „gestern" sein.

Weitere stille Fehlerquellen:

• Vergangene Datensätze nach Regeländerung neu auswerten, ohne zu protokollieren, dass Sie die Entscheidung neu ausgeführt haben (und welche Version Sie verwendet haben).
• Regeln mit manuellen Overrides vermischen, ohne zu speichern, wer übersteuert hat und warum.
• Downstream-Effekte wie Rechnungen, Benachrichtigungen oder Analytics vergessen, die vom ursprünglichen Ergebnis abhängen.
• Idempotenz brechen, sodass ein Retry eine zweite Nachricht sendet oder eine doppelte Belastung erzeugt.
• Nur den „aktuellen Status" speichern und die Ereignishistorie, die ihn erzeugt hat, verlieren.

Ein einfaches Beispiel: Sie ändern ein Genehmigungslimit, dann berechnet ein nächtlicher Job „Benötigt Genehmigung" für alle offenen Bestellungen neu. Wenn Sie nicht markieren, welche Bestellungen neu berechnet wurden, sieht der Support ein anderes Ergebnis als der Kunde letzte Woche.

Schnelle Checkliste vor einer Regeländerung

Bevor Sie eine Regeländerung ausliefern, entscheiden Sie, wie Sie beweisen, was gestern passiert ist und was morgen passieren soll. Gute Versionierung dreht sich weniger um ausgefeilte Logik als darum, Entscheidungen erklären und reproduzieren zu können.

Fangen Sie damit an zu prüfen, wie ein Datensatz die erhaltene Entscheidung „erinnert“. Wenn eine Bestellung, ein Ticket oder ein Anspruch später neu ausgewertet werden kann, braucht er einen klaren Verweis auf die Version, die beim Schlüsselmoment (Genehmigung, Preisbildung, Routing, Eignung) verwendet wurde.

Checkliste:

• Speichern Sie die Regelversion und den EntscheidungstimeStamp auf jedem Datensatz, der durch einen Schlüsselfallpunkt geht.
• Behandeln Sie Regeln als append-only: veröffentlichen Sie eine neue Version, behalten Sie die alte lesbar und setzen Sie sie mit einem expliziten Status außer Betrieb.
• Machen Sie Berichte änderungsbewusst: filtern Sie nach Version und Wirksamkeitsdatum, damit Metriken „vorher" und „nachher" nicht vermischt werden.
• Bestätigen Sie Reproduzierbarkeit: Sie können eine alte Entscheidung aus gespeicherten Eingaben plus referenzierter Version erneut abspielen und dasselbe Ergebnis erhalten.
• Planen Sie Rollback als Routing: leiten Sie neue Datensätze zurück zur vorherigen Version, ohne die Historie umzuschreiben.

Noch etwas, das Teams später rettet, ist Ownership. Setzen Sie eine namentliche Person (oder kleine Gruppe) für Freigaben und Dokumentation ein. Schreiben Sie auf, was sich geändert hat, warum und welche Datensätze betroffen sind.

Beispiel: Ein Genehmigungs-Workflow aktualisieren, ohne die Historie umzuschreiben

Ein häufiger Fall sind Rückerstattungen. Früher brauchten Sie Managerfreigabe für Rückerstattungen über $200, die Richtlinie ändert sich jetzt und das Limit ist $150. Das Problem: Sie haben noch ältere Tickets offen und deren Entscheidungen müssen erklärbar bleiben.

Behandeln Sie die Genehmigungslogik als versionierten Regelbestand. Neue Tickets verwenden die neue Regel. Bestehende Tickets behalten die Version, mit der sie begonnen haben.

Hier ist eine kleine, konkrete Datensatzform, die Sie auf jedem Fall (oder Ticket) speichern können:

case_id: "R-10482"
created_at: "2026-01-10T09:14:00Z"
rule_version_id: "refund_threshold_v1"
decision: "auto-approved"

Jetzt ist das Verhalten klar:

• v1: Managerfreigabe, wenn Betrag > 200
• v2: Managerfreigabe, wenn Betrag > 150

Wenn ein Ticket letzte Woche mit rule_version_id = refund_threshold_v1 erstellt wurde, wird es weiterhin mit der $200-Schwelle bewertet, selbst wenn es heute verarbeitet wird. Ein Ticket, das nach dem Rollout erstellt wurde, erhält refund_threshold_v2 und verwendet $150.

Gradueller Rollout, mit dem Support leben kann

Release v2, aber weisen Sie es zuerst einer kleinen Auswahl neuer Tickets zu (einen Kanal oder ein Team). Support-Mitarbeiter sollten zwei Dinge auf dem Fall-Bildschirm sehen: die Version und eine leicht verständliche Erklärung (z. B. „v1 Schwelle $200"). Wenn ein Kunde fragt „Warum wurde das genehmigt?", kann der Mitarbeiter antworten, ohne zu raten.

Was Sie nach der Änderung messen sollten

Verfolgen Sie ein paar Signale, um zu bestätigen, dass die Richtlinie wie erwartet funktioniert:

• Genehmigungsrate nach Regelversion (v1 vs v2)
• Eskalationen und Größe der Manager-Queue
• Audit-Fragen: wie oft jemand nach dem „Warum" fragt und wie schnell Sie antworten können

Nächste Schritte: Versionierung in Ihren Workflow-Prozess integrieren

Starten Sie einfach. Fügen Sie jedem Datensatz, der von einer Regel betroffen ist, ein rule_version_id (oder workflow_version) Feld hinzu. Wenn sich eine Regel ändert, erstellen Sie eine neue Version und kennzeichnen die alte als retired, aber löschen Sie sie nie. Alte Datensätze verweisen weiterhin auf die Version, die verwendet wurde, als sie in den Workflow gelangten oder als die Entscheidung getroffen wurde.

Damit dies Bestand hat, behandeln Sie Regeländerungen wie einen echten Prozess, nicht als Ad-hoc-Edit. Ein leichtgewichtiger Regel-Registry hilft, selbst wenn er als Tabelle oder Spreadsheet beginnt. Verfolgen Sie Owner, Zweck, Liste der Versionen mit kurzen Änderungsnotizen, Status (Draft/Active/Retired) und Scope (auf welche Workflows und Datensatztypen es angewendet wird).

Mit wachsender Komplexität fügen Sie die nächste Ebene nur hinzu, wenn Sie sie benötigen. Wenn Leute fragen „Welche Entscheidung wäre an diesem Datum gewesen?", fügen Sie Effektivdaten hinzu. Wenn Prüfer fragen „Welche Eingaben wurden verwendet?", speichern Sie Snapshots der Fakten, die die Regel verwendet hat (Schlüsselfelder, Schwellen, Genehmigerliste). Wenn Änderungen risikoreich sind, verlangen Sie Freigaben, damit eine neue Version nicht ohne Review live gehen kann.

Wenn Ihr Team schneller werden will, ohne die Historie zu verlieren, kann eine No-Code-Plattform helfen. AppMaster (appmaster.io) ist darauf ausgelegt, komplette Anwendungen mit Geschäftslogik zu bauen, sodass Sie ein Regel-Register modellieren, Versions-IDs auf Datensätzen speichern und Workflows weiterentwickeln können, während ältere Fälle an die Logik gebunden bleiben, die sie ursprünglich verwendet haben.