Die zentrale Idee bei der Aktualisierung der Datenbank in der Applikation ist, sämtliche notwendigen Aktualisierungen der Datenbank während des endgültigen Speicherns bei jeder Geschäftstransaktion durchzuführen. Demnach werden beim Speichern einer Transaktion in einem einzigen Schritt und in einer Datenbanktransaktion sämtliche Aktualisierungen ausgeführt und sämtliche Dateien erzeugt. Für den unwahrscheinlichen Fall, dass diese Geschäftstransaktion nicht durch den Workflow läuft (z.B. weil sie nicht freigegeben wird oder weil sie von einer anderen Transaktion abhängig ist, die nicht genehmigt wird), wird der Kontraktstatus wie er vor Ausführung der Transaktion war, durch Verwendung einer Vorabbildung jedes Kontraktes, welcher gespeichert und aktualisiert wird, sobald die Geschäftstransaktion gespeichert wird, automatisch wiederhergestellt.

Um die logische Übereinstimmung zu überprüfen, passiert die Transaktion normalerweise die folgenden Hauptschritte und Service, die wiederum die übergreifende Reihenfolge der Transaktionen überprüfen:

1. Start einer Geschäftstransaktion
2. Speichern einer Geschäftstransaktion
3. Prüfung nach vollständigen Unterschriften
4. Prüfung nach Vorgängern
5. Schwebende Geschäfte endgültig machen (unumkehrbar)
6. Clean Up der spezifischen Daten schwebender Geschäfte

Zusätzlich werden so viele Service benutzt, wie für die individuelle Installation benötigt werden. Die Bearbeitung der Reihenfolge der Service ist in der Datenbanktabelle SRO festgelegt, welche die logische Abhängigkeit der verschiedenen Service durch Vorgängerregeln definiert.

Während des Startens einer Geschäftstransaktion werden logische Prüfungen hinsichtlich der Existenz der betroffenen Kontrakte, einschließlich der Subkontrakte wie Dokumentensätze, durchgeführt und sie werden optional gesperrt. Wenn die Logik einen betroffenen Kontrakt entdeckt, der noch nicht abgeschlossene Transaktionen enthält - diese können auf Freigabe oder auf die Ausführung anderer Service warten - wird eine Warnung zur Information des Benutzers ausgegeben, dass die benutzten Daten noch nicht endgültig sind. Falls ein Kontrakt, der gesperrt werden soll, bereits von einem anderen Benutzer oder Auftrag gesperrt ist, wird eine Fehlermeldung ausgegeben und die Transaktion beendet.

Zunächst werden alle logischen Prüfungen der Geschäftstransaktion ausgeführt. Falls keine Fehler enthalten sind, wird der Kontrakt aktualisiert und alle Nachrichtendateien und alle abhängigen Daten werden geschrieben. Während dieses Prozesses wird der Plan für sämtliche Service für dieses schwebende Geschäft bewertet und die gespeicherte Transaktion wird zusammen mit diesem Plan an das Workflow-System zur weiteren Bearbeitung übergeben. Die Benutzer-Id des erstellenden Benutzers wird an die Funktion zur Unterschriftenabwicklung übergeben und in den Transaktionsdaten gespeichert.

Abhängig von der implementierten Kontrolle & Freigabe-Methode und den Unterschriftsinformationen des gegenwärtigen Benutzers könnte die Transaktion bereits alle erforderlichen Unterschriften haben und das schwebende Geschäft kann demnach den Freigabe-Service beim ersten Versuch passieren.

Der Zweck der Prüfung nach vollständigen Unterschriften ist es, zu prüfen ob alle erforderlichen Unterschriften für ein schwebendes Geschäft vorhanden sind. Wenn eine Kombination von Unterschriften für ein schwebendes Geschäft vorliegt, welche die implementierte Kontrolle & Freigabe-Methode erfüllt, passiert das schwebende Geschäft den Freigabe-Service.

Dieser Service ist unabhängig von der Freigabetransaktion, die für den Benutzer sichtbar ist. Die sichtbare Freigabefunktion speichert die Freigabeunterschriften und ruft den “Prüfung auf vollständige Unterschriften” Service auf. Der Service selbst prüft, ob die eingegebenen Unterschriften des schwebenden Geschäfts die Freigabeanforderungen erfüllen. Falls ja, wird der Service erfolgreich passiert. Anderenfalls wartet das schwebende Geschäft auf mehr und/oder andere Unterschriften.

Dieser Service bietet eine Möglichkeit, für die Ausführung bestimmter Service eine serielle Reihenfolge zu erstellen, um in der Lage zu sein, die korrekte Reihenfolge zu garantieren. Um dies zu tun, prüft der Service, ob es irgendeinen vorhergehenden, schwebenden Vorgang gibt, der noch nicht als endgültig markiert ist. Wenn alle Vorgänger als endgültig markiert sind, ist der Service erfolgreich und der nachfolgende Service des schwebenden Geschäfts kann ausgeführt werden.

Mit diesem Service wird das schwebende Geschäft als unumkehrbar markiert, damit nachfolgende Service ausgeführt werden können. Demnach können andere schwebenden Geschäfte, die von dem betroffenen Kontrakt abhängig sind, die Prüfung nach Vorgängern passieren.

Nachdem alle Service ausgeführt wurden, kann ein Clean-up-Service in den Workflow eingetragen sein, um die Vorabbildung und andere schwebenden Transaktionsdaten und/oder historische Transaktionsdaten zu bereinigen. Der Datentyp, der bereinigt werden soll, kann auch die erzeugten Nachrichten einschließen, falls die Bank wirklich nicht will, diese im System zu belassen (was relativ unüblich wäre).