ProcWorks – Anleitung für Modellierer (Prozesse erstellen und freigeben)

Diese Anleitung richtet sich an Modellierer (Rolle modeler oder admin), die einen Prozess von Grund auf erstellen, mit Daten und Bearbeitern verdrahten, testen und freigeben. Sie führt Schritt für Schritt durch alle dafür nötigen Sichten des Web-Clients.

Grundprinzip Correctness by Construction (CbC): Das Werkzeug bietet nur Änderungen an, die das Modell korrekt halten. Einen „Validieren"-Knopf gibt es bewusst nicht – Korrektheit ist ein Zustand, kein nachträglicher Prüflauf. Unzulässiges weist der Kern ab; das bestehende Modell bleibt dabei unverändert.

⚠️ Hinweis zur Haftung. ProcWorks wird ohne jede Gewährleistung und – soweit gesetzlich zulässig – ohne jede Haftung bereitgestellt; die Nutzung erfolgt auf eigenes Risiko. Details: DISCLAIMER.md.

0. Überblick: die zwei Korrektheitsstufen

ProcWorks trennt zwei Stufen – das erklärt, warum man jederzeit weitermodellieren kann, aber erst am Ende freigeben darf:

Stufe	Was sie sichert	Wann erzwungen
(A) Struktur	Blockstruktur, Erreichbarkeit, Datenfluss (K-, D-, C-, Z-, A-Regeln)	bei jeder Operation – immer erfüllt
(B) Release-Reife	jeder interaktive Schritt hat einen Bearbeiter (B2)	bei der Freigabe

Ein halbfertiges Modell ist strukturell immer korrekt, aber noch nicht zwingend ausführbar. Die beiden Stufen bedeuten Unterschiedliches, und die Oberfläche hält sie deshalb auseinander:

Stufe A ist eine Zusicherung. Sie gilt nach jeder Operation. Was sie verletzen würde, weist der Kern ab – das Modell bleibt unverändert.
Stufe B ist ein Reifegrad. Ein Entwurf darf sie offen haben, solange man daran arbeitet – die Statusleiste weist sie als eigenen, milderen Zustand aus („n Schritt(e) ohne Bearbeiter"). Erst die Freigabe verlangt sie: ein Schema mit unbesetzten Schritten wird abgelehnt, benennt die betroffenen Schritte und bleibt unverändert im Entwurf.

Warum das zählt: Ein Schritt ohne Bearbeiterzuordnung wird zur Laufzeit zwar aktiviert, erscheint aber in keiner Arbeitsliste – der Vorgang sieht laufend aus und steht still. Das fällt nicht beim Modellieren auf, sondern später den Bearbeitenden. Genau davor bewahrt Sie die Freigabeprüfung.

Hinweis: Eine Dienstzuordnung ist für interaktive Schritte ausdrücklich nicht nötig – sie laufen über ihre Eingabemaske. Ein Dienst ist der Weg für automatische Schritte; die brauchen dafür keinen Bearbeiter.

Die strukturellen Befunde (Stufe A) zeigt die Befunde-Liste in der Modellieren-Sicht laufend an.

Tipp: Sichten im Browser-Verlauf. Jede Sicht hat ihre eigene Adresse (etwa …/#/model für Modellieren, …/#/data für die Datensicht). Die Zurück-Taste des Browsers führt zur vorigen Sicht, Neuladen und Lesezeichen öffnen dieselbe Sicht. Die Adresse nennt nur die Sicht, nie Prozess- oder Vorgangsdaten; eine Sicht, für die Ihre Rolle nicht freigeschaltet ist, öffnet sie nicht.

1. Neues Schema anlegen

Sicht Modellieren öffnen (links in der Navigation).
Oben rechts auf „+ Neu" klicken, einen sprechenden Namen vergeben (z. B. Urlaubsantrag) und mit Enter oder „Anlegen" bestätigen. Das neue Schema öffnet sich direkt in der Modellieren-Sicht – egal, von welcher Seite aus Sie es angelegt haben (gilt ebenso für Vorlage und Import).
Es entsteht ein Schema im Zustand ENTWURF mit einem START- und einem END-Knoten. Nur ein Entwurf ist editierbar.

Alternativ: „BPMN-Import" liest eine BPMN-2.0-Datei ein – per Dateiauswahl (.bpmn/.xml) oder durch Einfügen des XML. Gängige Schreibweisen anderer Werkzeuge werden dabei verstanden: Ein Schritt mit mehreren eingehenden Pfeilen bekommt eine Zusammenführung derselben Art wie die Verzweigung davor – nach einer parallelen Verzweigung also eine, die auf alle Zweige wartet (streng nach BPMN liefe der Schritt dort je Zweig einmal; das bildet ProcWorks bewusst nicht nach). Mehrere unbedingte ausgehende Pfeile gelten als parallel, und Bedingungen wie Betrag >= 1000 oder ${Betrag < 1000} werden zur Entscheidung – fehlt das Merkmal, wird es angelegt und vom Schritt davor gesetzt. Zahlengrenzen versteht der Import nur halboffen: Merkmal < Zahl, Zahl <= Merkmal < Zahl und Merkmal >= Zahl – der Grenzwert gehört dabei immer zum oberen Zweig. Bedingungen mit > oder <= (etwa ${Betrag > 1000} / ${Betrag <= 1000}, ebenso gt/le oder umgedrehte Vergleiche wie 1000 < Betrag) lehnt der Import mit einer eigenen Meldung ab, statt sie umzurechnen: Sie legen den Grenzwert in den unteren Zweig, und jede Umrechnung würde genau diesen Fall still verschieben. Schreiben Sie die Bedingungen im Ursprungswerkzeug auf </>= um und prüfen Sie dabei, in welchen Zweig der Grenzwert gehören soll. Bedingungen, die eine Lücke lassen (Betrag < 1000 und Betrag >= 2000) oder sich überschneiden (Betrag < 2000 und Betrag >= 1000), lehnt der Import mit genau diesem Grund und dem betroffenen Wertebereich ab; eine Bedingung mit vertauschten Grenzen (2000 <= Betrag < 1000), die gar keinen Wert zulässt, mit beiden Grenzen. Nicht regelkonforme Konstrukte (z. B. OR-Gateways, überkreuzte Blöcke) werden mit einer Begründung abgelehnt – nie als inkorrektes Modell gespeichert und auch nicht still „repariert". Den umgekehrten Weg geht „BPMN-Export" in der Kopfzeile der Modellieren-Sicht: Er lädt das aktuelle Schema als .bpmn-Datei herunter – mit fertigem Diagramm (andere BPMN-Werkzeuge zeigen den Ablauf sofort, statt einer leeren Fläche) und einer Bahn („Lane") je Bearbeiterregel, damit ablesbar bleibt, wer was erledigt. Wird dieselbe Datei wieder eingelesen, kommen auch Bearbeiterregeln, Eingabemasken, Termine und Prioritäten zurück; nicht mitreisen können Verweise auf andere Prozessmodelle (Teilprozesse und Folgeprozesse), weil das Zielsystem sie in der Regel nicht kennt.

1a. Aus einer Vorlage starten

Statt bei einem leeren START→END zu beginnen, können Sie ein neues Schema aus einer Vorlage erstellen:

Oben rechts auf „Aus Vorlage" klicken.
In der Galerie eine Vorlage auswählen. ProcWorks bringt zehn eingebaute Vorlagen für Prozesse mit, die es in den meisten Firmen gibt: Urlaubsantrag, Rechnungsfreigabe, Onboarding neuer Mitarbeiter, Bestellfreigabe (Freigabe je nach Betrag), Reisekostenabrechnung, Reklamation, Vier-Augen-Freigabe (die vorgesetzte Person der erfassenden gibt frei), Störungsmeldung (mit begrenzter Nacharbeit), Lieferantenfreigabe und Zugriffsantrag. Jede Karte zeigt die Zahl der Schritte und wer was erledigt. Eigene, gespeicherte Vorlagen sind mit „Eigene" gekennzeichnet.
„Erstellen" legt daraus ein frisches, editierbares Schema an – eine Kopie des Vorlagen-Bauplans, die Sie wie jeden anderen Entwurf anpassen und freigeben.

Eigene Vorlage speichern: Öffnen Sie ein Schema und klicken Sie in der Kopfzeile auf „Als Vorlage". Vergeben Sie Name, optional Kategorie und Beschreibung. Die Vorlage steht danach in der Galerie „Aus Vorlage" für alle zur Verfügung. Eigene Vorlagen lassen sich wieder löschen; die eingebauten Vorlagen sind fester Bestandteil und bleiben erhalten.

Eine Vorlage ist ein in sich geschlossener Bauplan (mit eingebetteter Organisation). Beim Erstellen wird er als neues Schema kopiert und wie üblich vollständig geprüft – aus einer Vorlage kann also nie ein inkorrektes Modell entstehen.

2. Schritte einfügen (geführtes Modellieren)

Im Kontrollfluss-Diagramm sitzt an jeder Kante ein „+". Ein Klick darauf öffnet den Einfüge-Dialog mit vier Mustern:

Muster	Bedeutung	Ergebnis
Seriell	ein Schritt nach dem anderen	eine neue Aktivität in der Reihe
Parallel (UND)	mehrere Zweige laufen gleichzeitig	AND-Split mit zugehörigem AND-Join
Bedingt (XOR)	genau ein Zweig wird gewählt	XOR-Split mit zugehörigem XOR-Join, je Zweig eine Bedingung
Schleife	ein Schritt wird wiederholt, bis ein Merkmal die Runde beendet	Schleifenanfang und -ende mit dem Wiederhol-Schritt dazwischen

Verzweigung mit neuem Merkmal: Im Muster Bedingt (XOR) wählen Sie das Merkmal, nach dem entschieden wird. Gibt es noch keins, wählen Sie „＋ Neues Merkmal anlegen …", geben Name und Art an (Zahl, Ja/Nein, Text) – der Dialog legt es an und lässt den Schritt vor der Einfügestelle es setzen (Schreibbindung). Bei einem vorhandenen Merkmal ist das Häkchen „… setzt dieses Merkmal" vorbelegt, solange der Schritt davor es noch nicht schreibt. Ohne Schreiber davor lehnt die Prüfung die Verzweigung ab (K7): Die Entscheidung muss auf einem gesetzten Wert beruhen.

Wichtig: Verzweigungen und Schleifen werden immer als vollständiger, symmetrischer Block erzeugt – ein Split bringt seinen Join, ein Schleifenanfang sein Schleifenende automatisch mit (Blockstruktur, K1/K6). Das freie Ziehen von Kanten oder Rücksprüngen gibt es bewusst nicht.

Schleifen im Detail: Eine Schleife braucht ein Datenelement als Wiederholen-Merkmal. Am einfachsten ist ein Ja/Nein-Merkmal (z. B. „Nacharbeit nötig" – ein Ankreuzfeld in der Eingabemaske ist der natürliche Weg, es zu setzen); genauso funktionieren aber Zahlen („wiederholen, solange die Fehlerzahl ≥ 1 ist" – der Dialog fragt nach der Grenze) und Texte („wiederholen, solange der Status nacharbeit lautet" – der Dialog fragt nach den Wiederhol-Werten, alle anderen verlassen die Schleife). Der Wiederhol-Schritt läuft mindestens einmal; an seinem Ende entscheidet der Wert des Merkmals automatisch, ob eine weitere Runde folgt – niemand muss gefragt werden, und die Entscheidung ist in jeder Runde eindeutig. Gibt es das Merkmal noch nicht, wählen Sie wie bei der Verzweigung „＋ Neues Merkmal anlegen …" – vorgeschlagen ist Ja/Nein; der Dialog legt es beim Einfügen an. Eine Regel, die nie enden könnte (oder nie wiederholen würde), lässt sich gar nicht erst speichern. Damit das garantiert so bleibt, schreibt der Wiederhol-Schritt das Merkmal verbindlich (das System richtet diese Bindung beim Einfügen selbst ein; sie lässt sich auf einen anderen Schritt der Schleife verlagern, aber nicht ersatzlos entfernen). Eine Höchstzahl an Durchläufen ist mit 10 vorbelegt (mindestens 2; leeren nur, wenn die Schleife wirklich unbegrenzt laufen darf): Am Limit wird die Schleife automatisch verlassen, selbst wenn die Daten noch „wiederholen" sagen – ein Sicherheitsnetz; mit gesetzter Grenze rechnet auch die Terminprüfung den Wiederhol-Bereich entsprechend oft. Die Bedingung steht am Rücksprung-Bogen unter dem Wiederhol-Bereich und am Schleifenende. Im Wiederhol-Bereich ist alles erlaubt, was sonst auch geht – auch Teilprozesse (jede Runde startet einen frischen Durchlauf) und automatische Schritte. Entfernt wird die Schleife über ihren Schleifenanfang (löscht Anfang, Rumpf und Ende); das Löschen des letzten Schritts im Rumpf löst die Schleife ebenfalls auf. Der BPMN-Export schreibt Schleifen als übliches Gateway-Paar mit Rücksprungfluss, und der Import erkennt genau dieses Muster wieder.

Praxis-Tipp (Benennung): Aktivitäten als „Objekt + Verb" benennen („Antrag prüfen", „Bestellung freigeben"). Das verbessert die Lesbarkeit und folgt den anerkannten Modellierungsrichtlinien (7PMG).

Schritte umbenennen, verschieben oder entfernen

Einen Knoten anklicken → die Schritt-Karte (bzw. in der klassischen Ansicht der Knoten-Inspektor rechts) erlaubt Umbenennen, Verschieben und Entfernen.
Verschieben: Über „Verschieben…" wandert ein Schritt an eine andere Stelle des Ablaufs – mit allen seinen Bindungen (Daten, Bearbeiter, Dienst, Eingabemaske, Zeitvorgabe, Benachrichtigung). Das unterscheidet das Verschieben vom Löschen und Neuanlegen, bei dem die Bindungen verloren gingen. Man wählt im Dialog den Schritt, hinter dem der Schritt künftig liegen soll. Ein Ziel, das eine Regel verletzen würde – etwa weil ein Schritt dann Daten läse, die erst später geschrieben werden –, lehnt das System mit Begründung ab; das Modell bleibt unverändert. Verschiebt man die letzte Aktivität eines XOR-Zweigs heraus, bleibt der Zweig als leerer Zweig stehen (siehe unten) – genau wie beim Entfernen.
Eine Verzweigung wird über ihren öffnenden Split entfernt (der ganze Block inkl. Join verschwindet). Join-Knoten lassen sich nicht einzeln löschen.
Beim Entfernen werden abhängige Bindungen (Daten, Dienste, Bearbeiterregeln) automatisch mit bereinigt – es entstehen keine verwaisten Verweise.
Leerer Zweig bei bedingten (XOR) Verzweigungen: Entfernt man die letzte Aktivität eines XOR-Zweigs, verschwindet der Zweig nicht – er bleibt als leerer Zweig stehen (er wird bei passender Bedingung einfach übersprungen). So lässt sich modellieren, dass nur in einem Zweig eine Aktivität anfällt. Die Verzweigung bleibt dabei garantiert vollständig und überschneidungsfrei. Möchte man den leeren Zweig ganz loswerden, wählt man den Split an und klickt „Leeren Zweig entfernen"; bleibt danach nur noch ein Zweig übrig, löst sich die gesamte Verzweigung auf und der verbleibende Zweig wird als gewöhnlicher Schritt eingefügt. Der leere Zweig hat im Kontrollfluss eine eigene Bahn mit der Beschriftung „leerer Zweig“ und seiner Bedingung; über das „+“ auf dieser Bahn lässt er sich wieder füllen. Ebenso fügt das „+“ am Anfang jedes Zweigs dort einen Schritt ein (die Bedingung des Zweigs bleibt erhalten).

Zwei Oberflächen zur Wahl

Für das Modellieren gibt es zwei gleichwertige Oberflächen. Umgeschaltet wird oben rechts in der Kopfzeile; die Wahl bleibt im Browser gespeichert. Beide arbeiten auf denselben Operationen – es geht ausschließlich um die Darstellung, nie um das, was erlaubt ist.

	Karten-Ansicht (Standard)	Klassische Ansicht
Kontrollfluss	volle Breite	linke Spalte
Arbeiten am Schritt	Schritt-Karte erscheint bei Auswahl am Rand und trägt alles zu diesem Schritt	Knoten-Inspektor + Bindungs-Palette in der rechten Spalte
Binden	Knopf „⊕ Datenelement binden" / „⊕ Bearbeiter zuordnen" in der Karte	⊕ in der Palettenliste, nachdem links ein Schritt gewählt wurde
Korrektheit	Ampel am Schritt, Marker am Knoten, Statusleiste unten	Panel „Korrektheit" rechts

Karten-Ansicht: alles am gewählten Schritt

Einen Schritt anklicken – die Karte daneben zeigt in dieser Reihenfolge: Befunde (falls der Kern etwas beanstandet), Ablauf, Daten, Bearbeiter, Dienst, Eingabemaske, Zeit & Priorität, Benachrichtigung, Klassifikation. Was für die Freigabe nötig ist, ist aufgeklappt; das Übrige klappt man bei Bedarf auf – die Wahl wird gemerkt.

Am gewählten Schritt selbst erscheint ein kleiner Schnellring: + (Schritt danach einfügen), ✎ (umbenennen), ⊕ (binden), ✕ (entfernen). Ein farbiger Punkt im Kartenkopf zeigt, ob dem Schritt für die Freigabe noch etwas fehlt (grün/gelb) oder ob der Kern ihn beanstandet (rot). Der Punkt ist eine Anzeige – geprüft wird ausschließlich im Kern.

Binden in der Karte:

Im Abschnitt Daten auf „⊕ Datenelement binden" klicken → Liste mit Suchfeld; ganz oben stehen die Elemente, die ein vorgelagerter Schritt bereits schreibt (die üblichen Lese-Kandidaten). Fehlt eines, legt „＋ Neues Datenelement anlegen" es an und führt zurück in den Dialog. Danach Richtung (Lesen/Schreiben) und Pflicht/optional wählen.
Im Abschnitt Bearbeiter auf „⊕ Bearbeiter zuordnen" → Rollen, Abteilungen und Agenten, ebenfalls mit Suchfeld. Weitergehende Regeln (Bearbeiter bzw. Vorgesetzte:r eines früheren Schritts) öffnet der Link „Erweiterte Regel …".

Ist ein Prozess noch leer, bietet die Fläche direkt „Ersten Schritt anlegen" an. Esc hebt die Auswahl wieder auf.

Ohne Maus durch den Prozess (die Statusleiste unter dem Kontrollfluss nennt die Tasten):

Taste	Wirkung
← / →	einen Schritt zurück/weiter im Ablauf; an einer Verzweigung geht → in den Zweig hinein
↑ / ↓	zwischen den Zweigen einer Verzweigung wechseln (nur dort, wo tatsächlich ein Zweig über bzw. unter dem Schritt liegt)
↵ Enter	Fokus in die Schritt-Karte holen – die Schreibmarke steht dann im Bezeichnungsfeld
Esc	Auswahl aufheben (bzw. das Vollbild verlassen)

Der gewählte Schritt rückt dabei von selbst ins Bild. Die Tasten wirken auch in der klassischen Ansicht; während in einem Feld getippt wird oder ein Dialog offen steht, bleiben sie wirkungslos.

„⤢ Einpassen" (oben rechts im Ablauf) holt ein verschobenes Modell zurück. Bei großen Modellen bleibt die Schrift dabei lesbar, und der Ablauf wird ab dem Start gezeigt; ein zweiter Klick direkt danach zeigt die ganze Übersicht.

Klassische Ansicht: Palette in der rechten Spalte

Damit man beim Modellieren nicht ständig zwischen den Sichten wechseln muss, liegt rechts – unter dem Knoten-Inspektor – eine Bindungs-Palette mit zwei Tabs:

Datenelemente – alle Prozessvariablen mit Typ/Quelle. „+ Datenelement" legt ein neues an (bitte einen sprechenden Namen vergeben, z. B. Bestellwert, nicht Daten 1), das Stift-Symbol bearbeitet es.
Ressourcen – Rollen, Abteilungen und Agenten der Organisation, jeweils mit „+" zum Anlegen und Stift-Symbol zum Bearbeiten.

Binden per Klick:

Links im Kontrollfluss einen Schritt anklicken (nur Aktivitätsschritte können Bindungen tragen). Die Palette zeigt oben „Ziel: …".
In der Liste beim gewünschten Eintrag auf ⊕ „An Schritt binden" klicken. - Datenelement → Richtung (Lesen/Schreiben) und Pflicht/optional wählen → Lese-/Schreibbindung (D1–D4). - Rolle/Abteilung/Agent → Bearbeiterzuordnung (BZR, Z1–Z4); eine bestehende wird ersetzt. Neben Rolle und Abteilung lässt sich auch ein konkreter Agent explizit als Bearbeiter binden. Weitergehende Regeln (Bearbeiter bzw. Vorgesetzte:r eines früheren Schritts, Verknüpfung zweier Angaben per UND/ODER/AUSSER) legt der Dialog „Erweiterte Regel" im Bearbeiter-Dialog an. Beispiel: Sachbearbeitung AUSSER Person Erika. Findet eine Verknüpfung niemanden, lehnt die Prüfung sie mit Z2 ab.

Hinweis: Das Binden geschieht per Klick (nicht per Ziehen), weil das in allen Browsern – auch Safari – zuverlässig funktioniert.

Der Knoten-Inspektor rechts spiegelt und pflegt alle Angaben des gewählten Schritts direkt:

Daten und Bearbeiter (BZR) – „+ Daten binden" / „Bearbeiter zuordnen"; einzelne Datenbindungen („✕") und die BZR („Entfernen") lassen sich wieder lösen.
Dienst (A1–A3) – ausführbaren Dienst zuweisen (optional automatisch bzw. an ein Activity-Repository-Template gebunden), Automatik konfigurieren, wieder entfernen.
Frist (T1) – maximale erwartete Dauer des Schritts, optional dazu die Soll-Reaktionszeit ab Aktivierung und das Ankreuzfeld „Pause hält die Uhr an (Netto-Zeit)": Ist es gesetzt, zählt angehaltene Zeit nicht auf die Soll-Zeit – die Aufgabe wird um die Pausendauer später fällig (gilt für Arbeitslisten-Reihung und Eskalation). Ohne Häkchen läuft die Uhr in Pausen bewusst weiter. Jeder Zeitwert – Dauer, Soll-Zeit, Termin und der Abstand einer Eskalationsstufe – darf höchstens 100 Jahre betragen; ein größerer Wert wird abgewiesen. Ob eine Eskalationsstufe fällig ist, prüft der Server im Hintergrund in einem festen Takt (standardmäßig einmal je Minute) – eine Stufe feuert also bis zu einer Minute nach ihrem Fälligkeitszeitpunkt, nicht erst, wenn jemand eine Arbeitsliste öffnet.
Priorität (E8) – Auswirkung + Dringlichkeit; die Arbeitslisten-Reihung ergibt sich daraus.
Wertklasse (E3) – rein beratende Klassifikation (wertschöpfend usw.).

Den prozessweiten Termin/Deadline (T2 – der kritische Pfad muss hineinpassen) setzt der Knopf „Termin …" oben im Kopf der Modellieren-Sicht.

Jede Bindung – ob setzen oder lösen – läuft über den Validate-before-Commit-Pfad des Kerns: Unzulässiges wird sofort abgewiesen (z. B. das Lösen des einzigen Schreibers hinter einem Pflichtlesen, D1).

Datenherkunft sichtbar machen: Ein Klick auf ein Datenelement (in der Karten-Ansicht auf den Namen in der Bindungsliste, in der klassischen Ansicht in der Palette – oder schlicht die Auswahl eines Schritts) blendet gestrichelte Linien ein, die von jedem Schreib-Schritt zu jedem Lese-Schritt dieser Größe zeigen – so ist auf einen Blick klar, woher ein gelesener Wert stammt.

Für die vollständige Tabellen-Ansicht (inkl. aller Zeilen-Aktionen) führt der Knopf „Vollansicht" je Tab weiterhin in die Datensicht bzw. Ressourcensicht.

3. Daten verdrahten (Datensicht)

Aktivitäten kommunizieren über Datenelemente (Prozessvariablen), nicht über versteckte Kanäle. Das geschieht in der Sicht Datensicht – oder direkt über die Datenelement-Palette der Modellieren-Sicht (siehe oben).

Datenelement anlegen: „+ Datenelement" → Name und Typ wählen (Ganzzahl, Kommazahl, Betrag, Text, Datum, Ja/Nein, Link). Für Geldbeträge den Typ Betrag nehmen: Er nimmt höchstens zwei Nachkommastellen an (eine dritte wird abgelehnt statt still gerundet) und wird immer mit zwei Stellen angezeigt, etwa „1.234,50“. Entscheidungen können nach Beträgen wie nach Zahlen verzweigen. Ein Datum ist ein echter Kalendertag (JJJJ-MM-TT), ein Link beginnt mit http://, https:// oder mailto: – andere Werte werden abgewiesen. Vorgang benennen: Mit „Benennt Vorgang" wählen Sie bis zu zwei Datenelemente (etwa Bestellnummer und Lieferant), deren Werte einen Vorgang in Listen benennen: in „Meine Aufgaben" unter der Aufgabe, im Monitoring statt der internen Vorgangsnummer. Zahlen und Ja/Nein-Werte erscheinen mit ihrem Namen („Urlaubstage: 8“). Solange die Werte noch leer sind, heißt der Vorgang nach seinem Start („Vorgang vom 01.10., 14:03“); die interne Nummer steht nur klein darunter.
Schreiben/Lesen verbinden: je Aktivität festlegen, welche Elemente sie schreibt und welche sie liest.
Bearbeiten/Löschen (nur im Entwurf): Über die Zeilen-Aktionen lässt sich ein Datenelement umbenennen, sein Typ ändern, es löschen oder – bei extern angebundenen Elementen – seine Quelle zurücksetzen (die externe Bindung entfernen und es wieder als Instanz-Datenelement führen). Auch diese Änderungen sind Correct by Construction: Ein Typwechsel, der eine bestehende Bindung (D3), ein Maskenfeld (U2), eine XOR-Partition (K7) oder eine SQL-Bindung (C4/C7) bräche, wird abgelehnt; beim Löschen werden abhängige Bindungen und Maskenfelder mit entfernt, und noch bestehende Verweise (z. B. das Element ist der Diskriminator einer Verzweigung) verhindern das Löschen mit einer klaren Meldung.

Die goldene Datenfluss-Regel (D1): Ein Pflicht-Eingabeparameter muss auf allen Pfaden, die zu der lesenden Aktivität führen, vorher geschrieben worden sein. Andernfalls lehnt der Kern die Lesebindung ab.

In XOR-Zweigen zählt nur, was in allen Zweigen geschrieben wird (der Join bildet die Schnittmenge). Wer ein Element hinter dem Join verpflichtend lesen will, muss es in jedem Zweig schreiben.
In parallelen (UND-)Zweigen stehen hinter dem Join die Schreibvorgänge aller Zweige zur Verfügung – aber zwei Zweige dürfen nicht dasselbe Element gleichzeitig schreiben (D2).
Reihenfolge beim Bauen: erst schreiben, dann lesen – jede Bindung wird sofort geprüft; ein Lesen ohne vorhandenen Schreiber würde abgelehnt.

Externe Daten (Direktzugriff auf eine Datenbank) werden in der Sicht Integration angebunden (Connector + Entität + Schlüsselelement). Siehe Integrations-Leitfaden.md.

Eingabemaske gestalten: In der Schritt-Karte unter „Eingabemaske" legen Sie fest, welche Felder die bearbeitende Person sieht (Eingabe oder nur Anzeige, Pflicht, Darstellung). Felder lassen sich unter einer Gruppe zusammenfassen (z. B. Person, Adresse); die Maske zeigt dann eine Überschrift je Gruppe. Unter „Anordnung" wählen Sie 1 bis 3 Spalten; am Smartphone ist die Maske immer einspaltig. Die Vorschau im Dialog zeigt genau die spätere Maske. Ein Ankreuzfeld hat immer einen Wert (angehakt = ja, leer = nein); es trägt deshalb keinen Pflicht-Stern, und „Pflicht" wird dafür nicht angeboten. Muss etwas ausdrücklich bestätigt werden, entscheidet ein nachfolgender Schritt oder eine Verzweigung über den Wert.

Prüfregeln je Eingabefeld: Ein Zahlenfeld kann eine Unter- und Obergrenze haben (mindestens 0, höchstens 10 000), ein Textfeld ein Muster (ein regulärer Ausdruck, etwa [A-Z]{2}-\d{4} für AB-1234) und eine Höchstlänge. Die Maske markiert ein Feld, das eine Regel verletzt oder als Pflichtfeld leer ist, direkt am Feld. Der Server prüft dieselben Regeln bei jedem Abschluss (U4), auch wenn ein anderes System den Schritt über die Schnittstelle abschließt, und bei jeder Datenkorrektur – auch durch die Prozessverantwortung. Ein Pflichtfeld braucht beim Abschluss immer einen Wert.

Damit eine Prüfung nie minutenlang rechnet, nimmt der Designer nur Muster an, die das ausschließen: höchstens 200 Zeichen, keine Rückverweise wie \1, und das Muster darf nicht zu viele Wege bieten, dieselbe Eingabe zu erkennen. Der Designer schätzt den Prüfaufwand für eine Eingabe von 300 Zeichen ab und lehnt ein Muster über der Grenze ab. Typische Ursachen und Abhilfen:

eine Wiederholung einer Wiederholung, deren Teile sich überschneiden: statt (a+)+ genügt a+; erlaubt ist sie, wenn die Teile klar getrennt sind, etwa (\.[\w-]+)+ (der Punkt ist kein Wortzeichen) oder ([A-Z]{2}-)+;
Alternativen, die mit denselben Zeichen beginnen: (ab|cd)+ statt (a|ab)+, auch ohne Wiederholung ((a|aa)(a|aa)…);
mehrere aufeinanderfolgende offene Wiederholungen derselben Zeichen wie \d*\d*\d*.

Geprüft werden Eingaben bis 300 Zeichen.

4. Organisation und Bearbeiter (Ressourcensicht)

Wer einen interaktiven Schritt bearbeiten darf, ergibt sich aus dem Organisationsmodell und einer Bearbeiterzuordnungsregel (BZR) je Schritt.

Organisation modellieren (Sicht Ressourcensicht): - „+ Rolle" (z. B. Sachbearbeiter, Leitung), - Organisationseinheiten, - „+ Agent" (die konkreten Personen) und ihre Rollen/Einheiten. - Rechts unter „Ressourcen-Befunde" stellt ein Organigramm die Abteilungs-Hierarchie (mit Vorgesetztem und Agenten-Anzahl je Einheit) dar. Ein Klick auf eine Abteilung hebt sie samt ihrer Agenten – inklusive Vorgesetztem – in der Agentenliste hervor; ein Klick auf das ★-Badge eines Vorgesetzten im Bereich „Abteilungen" hebt diesen gezielt hervor.
Bearbeiterregel je Schritt festlegen (Tabelle Schritt → Bearbeiterregel): z. B. „Rolle = Sachbearbeiter". Die Regelsprache kennt neben Rolle und Abteilung auch den konkreten Agenten (explizite Auswahl einer Person), den Bearbeiter eines früheren Schritts (NodePerformingAgent(nodeId)) und – relativ zum Ausführer – die/den Vorgesetzte:n dieses Bearbeiters (NodePerformingAgentSupervisor(nodeId), z. B. genehmigt der Vorgesetzte des Antragstellers dessen Urlaubsantrag). Leitet der Antragsteller seine Abteilung selbst, ist die Leitung der übergeordneten Abteilung zuständig – niemand genehmigt die eigene Arbeit, auch nicht als Vertretung. Dasselbe gilt für eine Vier-Augen-Regel mit AUSSER („Sachbearbeitung außer Bearbeiter von Schritt 1“): Wer Schritt 1 erledigt hat – auch als Vertretung einer abwesenden Kollegin –, erhält den späteren Schritt weder als Vertretung noch über eine Eskalationsstufe. Angaben lassen sich im Dialog „Erweiterte Regel" mit UND, ODER und AUSSER verknüpfen; bei einer Abteilung lässt sich wählen, ob ihre Unterabteilungen mitzählen.

Mehrere Schritte auf einmal: Im Bearbeiter-Dialog lässt sich die gewählte Regel über „Auch weiteren Schritten zuordnen …" zusätzlich anderen Schritten geben; „Alle ohne Bearbeiter wählen" markiert genau die, die vor der Freigabe noch fehlen. Jede Zuordnung wird einzeln geprüft – passt sie bei einem Schritt nicht, nennt die Meldung ihn, die anderen bleiben zugeordnet.

Korrektheitsregeln dahinter:

Z1 – die Regel ist syntaktisch gültig und referenziert nur existierende Rollen/Einheiten/Agenten.
Z2 – die Regel ist erfüllbar: sie muss mindestens einen Agenten liefern (eine Rolle ohne Träger ist eine gemeldete Inkonsistenz; eine Vorgesetzten-Regel setzt voraus, dass mindestens eine Abteilung eine:n Vorgesetzte:n hat).
Z3 – ein NodePerformingAgent(x)- bzw. NodePerformingAgentSupervisor(x)-Bezug verweist nur auf Schritte, die garantiert vorher laufen.
Automatische Schritte brauchen keine BZR, interaktive schon (Z4).

Geteilte Organisation: Ein Organisationsmodell kann einmal angelegt und in mehreren Schemata wiederverwendet werden (verknüpfen/lösen über das Organisations-Banner). Verknüpfte Organisationen bleiben auch nach der Freigabe editierbar; Bearbeiterregeln bleiben Entwurf-gebunden. Als Modellierer pflegen Sie eine geteilte Organisation (Rollen, Abteilungen, Vorgesetzte, Personen, Vertretungen, Postfächer); jede Änderung wird gegen alle verknüpften Prozesse geprüft. Eine neue geteilte Organisation legt die Administration an – im Verknüpfen-Dialog wählen Sie dann eine vorhandene.

5. Dienste & Automatik (optional)

Manuell/interaktiv (Standard): ein Mensch erledigt den Schritt über „Meine Aufgaben".
Automatisch: in der Sicht Integration lässt sich einer Aktivität eine Automatik zuweisen – als External-Task (ein externer Worker holt und erledigt die Aufgabe) oder als HTTP-Push (ProcWorks ruft ein Zielsystem auf). Details: Integrations-Leitfaden.md.

Die Regeln A1–A3 prüfen, dass ein zugeordneter Dienst (Template) typkonform an die Datenelemente gebunden ist; I1–I4 prüfen die Wohlgeformtheit der Automatik-Bindung.

5a. Wiederverwendbare Subprozesse & Submodell-Bibliothek

Wiederkehrende Abläufe müssen nicht in jedem Modell neu gebaut werden. Ein eigenständig entwickeltes Schema lässt sich als Submodell bereitstellen und dann in beliebig vielen Hauptprozessen als Subprozess wiederverwenden – die Datenübergabe eingeschlossen.

Ein Submodell bereitstellen:

Das wiederverwendbare Schema wie gewohnt modellieren und – noch im Entwurf – im Kopf der Modellieren-Sicht den Schalter „☆ Als Submodell" aktivieren. Das Flag ist reine Katalog-Markierung und ändert nichts an der Prüfung des Modells.
Das Schema freigeben (nur freigegebene Schemata sind bindbar, H1). Erst dann erscheint es in der Bibliothek und steht anderen Modellen zur Wiederverwendung bereit. Am freigegebenen Schema zeigt der Kopf nur noch „★ Submodell"; setzen oder entfernen lässt sich die Markierung – wie jede Änderung nach der Freigabe – nur über eine neue Revision. Die Bibliothek bietet je Submodell nur die jüngste freigegebene Version an, und nur, wenn sie markiert ist: Wird eine Revision ohne Markierung freigegeben, verschwindet das Submodell aus der Bibliothek; eine markierte Revision ersetzt dort die ältere Version. Bestehende Subprozess-Bindungen anderer Modelle bleiben davon unberührt: Sie verweisen auf eine bestimmte freigegebene Version. „Aus der Bibliothek verschwunden“ heißt nur „nicht mehr angeboten“: Die ältere Version bleibt freigegeben, und über die Schnittstelle (POST /schemas/{id}/subprocess) lässt sie sich weiterhin binden – die Prüfung verlangt nur eine freigegebene Version.

Eingänge eines Submodells: Ein Wert, den der Hauptprozess übergibt (etwa „Betrag“), wird im Submodell von niemandem geschrieben. Den lesenden Schritt darum ohne „Pflichtbindung“ binden – als Pflicht würde D1 die Bindung ablehnen, weil im Submodell allein nichts den Wert setzt. Dass er trotzdem ankommt, sichert der Hauptprozess: Eine Eingabe-Zuordnung ist nur möglich, wenn sein Element vor dem Subprozess auf jedem Weg gesetzt ist (H2).

Eine Aktivität in einen Subprozess umwandeln:

Im Entwurf des Hauptprozesses die betreffende Aktivität anklicken und im Knoten-Inspektor „In Subprozess umwandeln" wählen.
Ein Submodell aus der Bibliothek auswählen.
Die Datenübergabe zuordnen: je Datenelement des Submodells lässt sich optional eine Eingabe von (ein Datenelement des Hauptprozesses versorgt den Subprozess) und ein Ergebnis nach (der Subprozess schreibt sein Ergebnis in ein Datenelement des Hauptprozesses zurück) festlegen. Angeboten werden nur typgleiche Elternelemente.
Bestätigen. Die bisherige Aktivität wird zu einem SUBPROCESS-Knoten; ihre aktivitätsspezifischen Angaben (Eingabemaske, Datenzugriffe, Bearbeiterregel, Dienst, Priorität, Zeitangabe) entfallen, da nun das Submodell den Ablauf übernimmt.

Die Zuordnung eines bestehenden Subprozess-Knotens lässt sich später über „Zuordnung / Datenübergabe ändern" anpassen (anderes Submodell oder anderes Mapping).

Correctness by Construction dahinter: Die Verbindung wird nur gesetzt, wenn das resultierende Gesamtmodell konsistent und lauffähig bleibt. Der Kern prüft vor der Übernahme

H1 – das Ziel ist freigegeben und auf eine feste Version gepinnt;
H2 – die Zuordnung ist typkonform, und eine als Ergebnis übernommene Ausgabe muss vom Submodell auf jedem Pfad erzeugt werden (sonst wäre das Elternelement danach undefiniert). Übergebene Ergebnisse gelten im Hauptprozess als gesetzt und dürfen nachfolgend gelesen werden (D1);
H3 – die Aufrufhierarchie bleibt zyklenfrei;
H4 – die gepinnte Zielversion ist unveränderlich; eine neue Version des Submodells wird nur über eine neue Revision des Hauptprozesses übernommen.

Ist eine dieser Bedingungen verletzt, weist der Kern die Umwandlung ab und nennt den betroffenen Regel-Code – am Modell vorbei lässt sich keine inkonsistente Verbindung setzen.

6. Fortschritt prüfen: Befunde & Revision

Die Modellieren-Sicht zeigt laufend:

Befunde: alle noch offenen Punkte mit Regel-Code und betroffenem Knoten (z. B. B2: Schritt ohne Bearbeiter [n3]). Solange hier Stufe-B-Punkte stehen, ist die Freigabe blockiert. Eine Erläuterung aller Codes findet sich in der In-App-Sicht „Hilfe". In der Karten-Ansicht stehen sie dort, wo sie entstehen: ein Marker am betroffenen Knoten (Klick öffnet den Abschnitt „Befunde" der Karte), alles ohne Knotenbezug in der Statusleiste unter dem Kontrollfluss. In der klassischen Ansicht stehen sie als Liste im Panel „Korrektheit" rechts.
Revision: erzeugt aus einem freigegebenen Schema eine neue, editierbare Version (siehe §9).

7. Testlauf vor der Freigabe

Als Modellierer dürfen Sie einen Entwurf durchspielen, ohne ihn freizugeben. Eine solche Test-Instanz ist als TEST markiert und hinterlässt über ihren gesamten Lebenszyklus (Start, Schritt-Abschluss, Ad-hoc-Änderung, Abschluss) keine Spur im Monitoring, in den KPIs, im Audit-Log oder in den Integrations-Webhooks – Sie können also gefahrlos so oft durchspielen, wie Sie möchten. Ihre Aufgaben erscheinen nicht in „Meine Aufgaben“ der Bearbeiter (auch nicht bei Vertretungen), und sie lösen keine E-Mails und Eskalationen aus; durchgespielt wird im Prüfinstanz-Cockpit. Auch angebundene Systeme bleiben unberührt: Automatische Schritte (externe Aufgabe oder Push) werden nicht an Worker oder Tools gegeben – das Ergebnis geben Sie von Hand ein (siehe 7a). Sehen und bedienen können eine Test-Instanz nur Modellierer und Administratoren; Bearbeiter und Leser erhalten „nicht gefunden“, auch wenn ein Schritt sie beträfe.

7a. Prüfinstanz-Cockpit (4-Quadranten-Analyse)

Der komfortabelste Weg ist die Sicht Prüfinstanz (nur für Modellierer/Administratoren). Trägt der Entwurf noch einen Befund aus einer später verschärften Prüfregel (siehe „Reparaturweg“), startet die Prüfinstanz nur, wenn dieser Befund zur Laufzeit unschädlich ist (zu große Zeitwerte, ein zu aufwendiges Eingabemuster); sonst nennt ProcWorks den Befund, der zuerst behoben werden muss.

In der Modellieren-Sicht oben rechts auf „⚗ Prüfinstanz" klicken (oder den Navigationseintrag Prüfinstanz öffnen und dort starten).
Ein Dialog fragt, wer die Instanz startet. Diese Person erscheint anschließend als angemeldeter Starter.
Es öffnet sich ein Cockpit aus vier Quadranten:

Quadrant	Inhalt
oben links – Monitoring	Live-Prozesslandkarte, Fortschritt, Instanzdaten und eine Schrittübersicht – nur für diese eine Instanz
oben rechts – Starter	die angemeldete Person mit Rollen und Abteilung
unten links / rechts – Arbeitslisten A & B	zwei frei wählbare beteiligte Agenten; jede Liste zeigt die offenen Aufgaben gefiltert auf diese Instanz

Über „Erledigen" in einer der beiden Arbeitslisten spielen Sie die Schritte aus Sicht des jeweiligen Agenten durch; das Monitoring links aktualisiert sich sofort. Ist ein automatischer Schritt bereit, steht er unter „Automatische Schritte": Mit „Ergebnis simulieren" geben Sie ein, was das angebundene System gemeldet hätte. Mit „⚗ Neue Prüfinstanz" starten Sie einen frischen Durchlauf, mit „Analyse schließen" verlassen Sie die Instanz.

So lässt sich der Ablauf inkl. Datenerfassung, Bearbeiterzuordnung und XOR-Entscheidungen realistisch aus mehreren Rollen durchspielen, bevor echte Instanzen laufen.

7b. Einfacher Testlauf (Ausführungs-Sicht)

Alternativ startet die Sicht Ausführung bei einem nicht freigegebenen Schema eine einzelne „▶ Test-Instanz" – dieselbe TEST-Markierung, aber ohne das Mehr-Rollen-Cockpit.

Schritt einer freigegebenen Instanz selbst abschließen? Als Modellierer sind Sie meist keinem Bearbeiter zugeordnet. Schließen Sie dann einen Schritt ab, den laut Bearbeiterregel eigentlich jemand anderes erledigt, fragt ProcWorks nach einer Begründung („Aufsichtseingriff") und hält sie im Audit-Verlauf fest. Test-Instanzen sind davon ausgenommen. Bei aktiver Lizenzierung ist ein solcher Eingriff nicht möglich.

Dasselbe gilt für einen automatischen Schritt, den ein angebundenes System erledigt (externe Aufgabe oder Push), etwa wenn es einen Fehler gemeldet hat: Ihn schließen nur Modellierer und Administratoren von Hand ab, immer mit Begründung. Die offene Aufgabe des Systems wird dabei beendet, damit es den Schritt nicht später noch einmal ausführt. Bearbeiter können einen solchen Schritt nicht abschließen.

8. Freigeben (RELEASED)

Sind alle Befunde behoben (Stufe A und B erfüllt), wird der Button „Freigeben" in der Modellieren-Sicht grün. Vorher zeigt er beim Klick, welche Schritte noch eine Bearbeiterzuordnung brauchen.
Vor der Freigabe fragt ProcWorks einmal nach, denn sie lässt sich nicht zurücknehmen: Danach ist das Schema unveränderlich (Kennzeichen „freigegeben“) und kann instanziiert werden – Bearbeiter sehen ab jetzt echte Aufgaben.

Erst ein freigegebenes Schema lässt sich von Bearbeitern produktiv nutzen. Die Vorbereitung der Logins beschreibt die Mitarbeiter-Anleitung.md.

9. Ändern nach der Freigabe: Revisionen

Ein freigegebenes Schema wird nicht direkt geändert. Stattdessen:

Eine Revision erzeugen. Dafür gibt es in der Modellieren-Sicht drei gleichwertige Wege — der Knopf heißt überall „Neue Revision": in der Kopfzeile neben „Zur Ausführung", im Knoten-Inspektor (dort, wo der Hinweis „Schema ist freigegeben" steht) und im Panel „Schema-Evolution" am Ende der rechten Spalte. Die Revision trägt denselben Namen, aber eine neue Schema-ID und eine erhöhte Version (z. B. Urlaubsantrag (v2)); die Knoten-IDs bleiben erhalten, damit laufende Instanzen migrierbar sind. Je Version gibt es höchstens eine offene Revision: Solange der Entwurf von v2 nicht freigegeben ist, lässt sich keine zweite Revision von v1 anlegen – der Entwurf wird weiterbearbeitet. Nach seiner Freigabe geht es mit einer Revision von v2 weiter: Revidiert wird immer die jüngste freigegebene Version. Eine Revision von v1 lehnt ProcWorks dann ab – sonst entstünde eine zweite „Version 2“. An einer solchen Version ist der Knopf „Neue Revision“ gesperrt; ein Klick darauf (auch per Tastatur) nennt den Grund, ebenso der Hinweis unter der Karte und das Panel „Schema-Evolution“. Gibt es aus früheren Versionen von ProcWorks zwei Versionen mit derselben Nummer, bleiben beide erhalten; eine weitere Dublette entsteht aber nicht mehr: Hat eine von ihnen schon eine Revision, lässt sich die andere nicht mehr revidieren, und ein zweiter Entwurf mit einer bereits freigegebenen Nummer lässt sich nicht freigeben (die Änderungen in die Revision der neuesten Version übernehmen).
Die Revision wie gewohnt bearbeiten und erneut freigeben.
Laufende Instanzen können – sofern verträglich – kontrolliert auf die neue Version migriert werden (Kriterien M1–M5). Unverträgliche Instanzen laufen sicher auf der alten Version weiter; sie werden nie in einen Mischzustand gezwungen.

Modelle, die eine neue Prüfregel betrifft (Reparaturweg)

ProcWorks schärft seine Prüfregeln mit Updates gelegentlich nach – etwa die Obergrenze von 100 Jahren für Zeitwerte oder die Prüfung von Eingabemustern auf zu aufwendige Formen. Ein Modell, das vorher gespeichert oder freigegeben wurde, kann danach einen Befund tragen, den es bei seiner Freigabe noch nicht gab. So ein Modell bleibt bearbeitbar:

Revision anlegen: Auch aus einem freigegebenen Schema mit solchen Befunden entsteht wie gewohnt eine Revision. Sie übernimmt die Befunde; sie stehen in der Befundliste.
Schrittweise korrigieren: Jede Änderung am Entwurf ist erlaubt, solange sie keinen neuen Befund hinzufügt. Die alten Werte lassen sich also einzeln berichtigen, auch wenn noch ein anderer alter Befund offen ist. Eine Änderung, die einen neuen Befund erzeugt, wird wie immer mit diesem Befund abgelehnt. Als neu gilt dabei auch jeder andere ungültige Wert an der Stelle eines alten – ein anderes zu aufwendiges Muster ebenso wie ein kleinerer, aber immer noch zu großer Zeitwert. Setzen Sie also gleich einen gültigen Wert. Ein Maskenfeld mit einem alten Befund lässt sich dagegen umbenennen.
Freigabe erst ohne Befunde: Freigegeben wird die Revision erst, wenn alle Befunde – alte wie neue – behoben sind. Ein ungültiges Modell wird also nie neu freigegeben.
Laufende Vorgänge: Ad-hoc-Änderungen an Vorgängen des alten Schemas sind weiter möglich, sofern sie keinen neuen Befund hinzufügen. Vorgänge einer früheren Version können auf eine solche Version migriert werden, wenn ihre alten Befunde zur Laufzeit unschädlich sind (zu große Zeitwerte gelten dann als „keine Frist“, ein zu aufwendiges Eingabemuster wird nicht geprüft); bei allen anderen Befunden lehnt die Migration ab.
Vorlagen: Als Vorlage speichern lässt sich nur ein Modell ohne Befunde. Eine ältere Vorlage, die eine neue Regel betrifft, ergibt beim Anlegen einen Entwurf mit diesen Befunden, den Sie vor der Freigabe korrigieren.

Laufende Instanzen migrieren

Sobald die neue Revision freigegeben ist, steht in der Kopfzeile „Laufende Instanzen migrieren (N)" – N ist die Zahl der Instanzen, die noch auf einer früheren Version laufen. Der Knopf öffnet den Migrationsassistenten:

Je Instanz steht, ob sie wechseln kann („migrierbar") oder auf ihrer Version bleibt – dann mit Grund in Klartext, etwa „Der bereits bearbeitete Schritt ‚Prüfen' fehlt in der neuen Version". Bereits Erledigtes wird nie verändert; deshalb kann eine Instanz, die schon hinter einer geänderten Stelle steht, nicht wechseln.
Verlangt die neue Version ein neues Pflichtfeld, das für eine Instanz kein Schritt mehr liefern würde, fragt der Assistent einen Startwert ab. Er gilt für alle ausgewählten Instanzen, wird aber nur dort eingesetzt, wo der Wert fehlt – vorhandene Werte bleiben unangetastet. „Mit diesen Startwerten erneut prüfen" zeigt das Ergebnis, ohne etwas zu ändern.
„Ausgewählte migrieren" führt den Wechsel aus – je Instanz einzeln: Passt eine nicht, bleibt sie unverändert, die anderen wechseln trotzdem. Jeder Wechsel steht im Audit-Verlauf der Instanz („Instanz migriert").

In der Ausführungs-Sicht steht bei jedem bereiten Schritt, wer zuständig ist. Abschließen können Sie ihn dort, wenn Sie zuständig sind. Als Modellierer ohne eigene Bearbeiterrolle heißt der Knopf „Als Aufsicht abschließen"; er fragt nach einer Begründung (siehe Abschnitt 7b). Bestimmt ein späterer Schritt seinen Bearbeiter aus der Person, die diesen Schritt erledigt (etwa „Vorgesetzte:r des Bearbeiters von Schritt 1“), lehnt ProcWorks den Aufsichtsabschluss ab – danach gäbe es diese Person nicht, und der spätere Schritt fände niemanden. Ebenso bei einer Vier-Augen-Regel („Sachbearbeitung außer Bearbeiter von Schritt 1“): Ohne Bearbeiter ließe sich nicht nachweisen, dass zwei verschiedene Personen beteiligt waren; diese Regel lässt sich auch per Aufsicht nicht übergehen. Den Schritt erledigt dann eine zuständige Person. In der Ausführungs-Sicht ist „Als Aufsicht abschließen“ bei solchen Schritten deshalb gesperrt; ein Klick darauf (auch per Tastatur) nennt den betroffenen Folgeschritt. Auch eine Ad-hoc-Änderung hebt die Regel nicht auf: Einen Schritt, der eine Vier-Augen-Regel trägt oder auf den sie sich bezieht, bietet „Schritt entfernen“ nicht an, und ProcWorks lehnt das Entfernen ab. Soll die Regel entfallen, legen Sie eine neue Revision an und migrieren den Vorgang.

Einzelne Instanzen lassen sich auch aus der Ausführungs-Sicht migrieren: Gibt es eine neuere freigegebene Version, zeigt die Instanz den Hinweis „Neue Version verfügbar" mit dem Knopf „Auf neue Version migrieren". Nicht angeboten werden Test-Instanzen und Instanzen, die als Teilprozess eines anderen Vorgangs laufen.

Rückweg auf eine ältere Version: Wurde eine Revision versehentlich freigegeben, lässt sich eine Instanz auch auf eine ältere freigegebene Version zurückführen – über die Schnittstelle (POST /instances/{id}/migrate mit der Schema-ID der älteren Version). Es gelten dieselben Kriterien M1–M5 wie in die andere Richtung: Bereits Erledigtes muss in der Zielversion erhalten sein, sonst wird der Wechsel abgelehnt. Die Oberfläche bietet nur neuere Versionen an.

10. Häufige Befunde und was zu tun ist

Code	Bedeutung	Lösung
B2	interaktiver Schritt ohne Bearbeiter	Bearbeiterregel in der Ressourcensicht setzen
D1	Lesen vor Schreiben	Element auf allen Pfaden vor dem Lesen schreiben
D2	konkurrierende Schreibzugriffe	nicht zwei Parallelzweige dasselbe Element schreiben lassen
D3	Typkonflikt	Typen von Quelle und Senke angleichen
Z2	Bearbeiterregel liefert niemanden	Rolle mit Trägern hinterlegen oder Regel anpassen

B2 ist die einzige Prüfung, die erst bei der Freigabe greift. Die Kürzel B1 und B3 aus dem Regelkatalog erscheinen nie als Befund: Ein Schritt braucht keinen Dienst (ein interaktiver Schritt wird über seine Maske erledigt, ein Dienst ist nur für automatische Schritte nötig), und ob alle Pflichtdaten versorgt und alle Entscheidungen vollständig sind, prüfen schon D1, K6 und K7 bei jeder Änderung – ein Modell, dem das fehlt, entsteht gar nicht erst.

Die vollständige Liste aller Regel-Codes erklärt die In-App-Hilfe (Sicht „Hilfe").

Kurzreferenz: der typische Weg

Modellieren → „+ Neu" → Schritte über „+" einfügen (seriell/parallel/bedingt).
Modellieren → Schritt anklicken und Daten/Bearbeiter direkt an ihm binden (Karten-Ansicht) bzw. über die Paletten rechts (klassische Ansicht) – für die volle Tabellensicht Datensicht bzw. Ressourcensicht.
(optional) Integration → Automatik/externe Daten.
Ausführung → Test-Instanz starten und durchspielen.
Modellieren → alle Befunde lösen → Freigeben.
Bei Änderungswunsch → Revision → bearbeiten → freigeben → ggf. migrieren.