Workflow Blueprint

Ein Workflow Blueprint ist das "Gehirn" jedes Geschäftsprozesses in ConnectWorkflow. Er definiert nicht nur die Abfolge von Schritten, sondern legt fest, wer wann welche Informationen sieht und welche Entscheidungen an welchen Stellen getroffen werden müssen.

Blueprint als Prozess-Definition

Man kann sich den Blueprint wie einen Bauplan vorstellen: Er beschreibt die statische Struktur des Prozesses, während eine Workflow-Instanz die konkrete Ausführung für einen bestimmten Beleg darstellt.

Die hierarchische Struktur

Ein Blueprint ist modular aufgebaut. Die folgende Grafik verdeutlicht die Abhängigkeiten zwischen den einzelnen Elementen:

Identität und Trigger

Jeder Blueprint benötigt eine eindeutige Identität und ein Kriterium, wann er "anspringen" soll.

Kopfdaten

Neben einer eindeutigen id verfügt jeder Blueprint über eine version. Diese Versionierung ist entscheidend für die Stabilität: Laufende Instanzen verbleiben in der Version, in der sie gestartet wurden, während neue Instanzen immer die aktuellste Version nutzen.

Syntax & Beispiel:

json

{
  "id": "rechnungspruefung_v1",
  "version": 1
}

Übersichtssfelder (`overviewField1` & `overviewField2`)

Über die optionalen Kopf-Eigenschaften overviewField1 und overviewField2 können bis zu zwei Belegfelder zentral im Blueprint definiert werden, die schrittübergreifend in der Benutzeroberfläche hervorgehoben werden.

Jedes Übersichtssfeld besteht aus folgenden Eigenschaften:

Eigenschaft	Beschreibung
Name (`name`)	Technischer Feldname aus dem microtech ERP (z. B. `fldAdrNr`). Die definierten Felder werden beim Instanz-Start automatisch im Backend via GraphQL abgefragt und in den Instanzdaten gespeichert.
Label (`label`)	Anzeigename für die Feldbezeichnung in Tabellen und Formularen (z. B. `Lieferant` oder `Gesamtbetrag`).

Verwendungszweck & Verhalten in der Benutzeroberfläche:

Aufgabenübersicht (TasksPage): In der Aufgabenliste werden overviewField1 und overviewField2 in eigenen Tabellenspalten dargestellt (z. B. inline als Label: Wert).
Aufgabendetailansicht (TaskDetailPage): Übersichtssfelder dienen ausschließlich der Hervorhebung in der Aufgabenübersicht und werden nicht automatisch in der Aufgabendetailansicht angezeigt. Wenn ein Feld in der Detailansicht sichtbar sein soll, muss es explizit in den fields des jeweiligen Bearbeitungsschritts konfiguriert werden.

Syntax & Beispiel:

json

{
  "overviewField1": {
    "name": "fldAdrNr",
    "label": "Adressnummer"
  },
  "overviewField2": {
    "name": "fldDat",
    "label": "Datum"
  }
}

Der Trigger-Mechanismus

Der Trigger definiert den Einstiegspunkt aus dem microtech ERP.

ObjectType (objectType): Legt fest, welche microtech-Tabelle überwacht wird (z. B. tblTransactions für Verkaufsvorgänge).
Condition (condition): Ein logischer Ausdruck, der prüft, ob der Beleg für diesen Workflow relevant ist. So kann sichergestellt werden, dass z. B. nur "Rechnungen über 5.000 €" in einen speziellen Genehmigungsprozess laufen.
Erster Schritt (nextStep.step): Sobald der Trigger zündet, wird die Instanz erzeugt und in den ersten definierten Schritt (Start-Step) versetzt.

Syntax & Beispiel:

json

"trigger": {
  "objectType": "tblTransactions",
  "nextStep": {
    "condition": "acoGPreis.totalNetAmount > 5000",
    "step": "department_approval"
  }
}

Die Bearbeitungsschritte

Die Schritte sind die Bausteine des Workflows. In ConnectWorkflow wird zwischen zwei grundlegenden Arten unterschieden:

UserStep (Fachliche Bearbeitung)

Dies ist der Standard-Schritt für menschliche Interaktionen. Hier wird festgelegt, wer die Aufgabe bearbeiten darf:

Zuständigkeit: Über das Feld group (bevorzugt) oder user wird die Aufgabe einer Bearbeitergruppe oder einer Einzelperson zugewiesen.
Rückfragen: Durch allowInquiry = true kann der Bearbeiter diesen Schritt temporär pausieren, um Informationen von anderen Nutzern einzuholen.
Benachrichtigungen: Pro Schritt können notificationEmail oder ein teamsWebhookUrl hinterlegt werden, um Bearbeiter proaktiv über neue Aufgaben zu informieren.

Syntax & Beispiel:

json

{
  "name": "department_approval",
  "stepType": "UserStep",
  "group": "Einkauf",
  "allowInquiry": true,
  "notificationEmail": "einkauf@firma.de"
}

SystemStep (Automatisierung)

Ein SystemStep erfordert keine manuelle Interaktion. Er führt eine vordefinierte action aus (z. B. eine automatische Statusänderung oder den Abschluss eines Teilprozesses) und leitet basierend auf dem Ergebnis direkt zum nächsten Schritt weiter.

Syntax & Beispiel:

json

{
  "name": "auto_archive",
  "stepType": "SystemStep",
  "action": "archive_document"
}

Feldsichtbarkeit und UI-Steuerung

Innerhalb eines UserSteps steuert die Liste der fields, was der Bearbeiter in der Workflow-Oberfläche sieht und tun kann. Jedes Feld referenziert dabei einen technischen Pfad aus den microtech-Daten (z. B. acoGPreis.totalNetAmount).

Begrenzung der Datentiefe

Aus den GraphQL-Tabellen können maximal 2 Ebenen abgeholt werden. Die Felder werden dabei mit einem Punkt (.) getrennt angegeben (z. B. Objekt.Feld).

Explizite Typangabe (as:TEXT)

Bei bestimmten Feldern (insbesondere RTF-Feldern aus microtech) muss der Rückgabetyp explizit angegeben werden, damit die Daten korrekt in der Workflow-UI dargestellt werden können. Dies erfolgt durch das Anhängen von (as:TEXT) an den technischen Feldnamen.

Eigenschaft	Wirkung
Visible (`visible`)	Steuert, ob das Feld überhaupt angezeigt wird. Hilfreich, um nur prozessrelevante Daten einzublenden.
Editable (`editable`)	(Aktuell nicht unterstützt) War ursprünglich geplant, um Werte direkt in der Cloud zu ändern. Aktuell dient der Workflow primär der Entscheidungsfindung basierend auf ERP-Daten.
Required (`required`)	Macht das Feld zum Pflichtfeld. Der Schritt kann erst abgeschlossen werden, wenn hier ein Wert vorliegt.

Syntax & Beispiel:

json

"fields": [
  {
    "name": "acoGPreis.totalNetAmount",
    "label": "Netto-Gesamtbetrag",
    "visible": true,
    "required": true
  },
  {
    "name": "fldInfo(as:TEXT)",
    "label": "Zusatzinformation (RTF)",
    "visible": true
  }
]

Übergänge und Entscheidungslogik

Die nextSteps definieren die Ausgänge eines Schritts. Sie erscheinen in der Oberfläche als Interaktions-Buttons für den Benutzer.

Bedingungen (Conditions)

Jeder Übergang kann an eine condition geknüpft sein. Dabei handelt es sich um Ausdrücke, die gegen die aktuellen Daten des Belegs geprüft werden.

Ist eine Bedingung erfüllt, wird der definierte Ziel-step angesteuert.
Ist das Feld step leer, bedeutet dies den Abschluss des gesamten Workflows.

Visuelle Gestaltung (Farben und Icons)

Über color und icon kann die Wirkung der Buttons gesteuert werden (z. B. ein grüner Button mit Haken für "Freigeben", ein roter für "Ablehnen"). Dies sorgt für eine intuitive Bedienung und eine klare Darstellung in der Prozess-Historie.

Icon-Konfiguration (`icon`)

Lucide Icon Name: Es können kurze Lucide Icon-Namen (z. B. check-circle, x-circle, thumbs-up, trash) oder Namen mit dem Präfix i-lucide- (z. B. i-lucide-check-circle) angegeben werden.
Fallback: Wird icon weggelassen oder ist leer, verwendet die Oberfläche automatisch den Standard-Icon i-lucide-arrow-right.
Icon-Übersicht: Eine Übersicht aller verfügbaren Icons ist auf lucide.dev zu finden.

Farb-Konfiguration (`color`)

Semantische Farben: Direkt unterstützt werden primary, error, success, warning und neutral.
Farb-Aliase: Für einfache Konfiguration werden auch grundlegende Farbnamen automatisch zugeordnet:
- red oder danger → error
- green → success
- yellow oder amber → warning
- blue → primary
- gray oder grey → neutral
Fallback: Wird color weggelassen, gilt standardmäßig primary.

Syntax & Beispiel:

json

"nextSteps": [
  {
    "label": "Freigeben",
    "color": "success",
    "icon": "check-circle",
    "condition": "acoGPreis.totalNetAmount < 10000",
    "step": "zahlung_veranlassen"
  },
  {
    "label": "Ablehnen",
    "color": "red",
    "icon": "x-circle",
    "condition": "'reject'.equalsIgnoreCase(#action)",
    "step": "ende_abgelehnt"
  }
]

Vollständiges Praxisbeispiel

Das folgende Beispiel zeigt einen Blueprint für eine Eingangsrechnungsprüfung (ER). Es verdeutlicht das Zusammenspiel von Triggern, Benutzerfeldern (inkl. Punkt-Notation für verknüpfte Daten) und System-Abschlüssen.

yaml

# Identität des Blueprints
id: ER-MBCOM
version: 4

# Übersichtssfelder für die Aufgabenliste
overviewField1:
  name: fldAdrNr
  label: Adressnummer
overviewField2:
  name: fldDat
  label: Datum

# Einstiegspunkt: Wann soll dieser Workflow starten?
trigger:
  objectType: tblTransactions
  nextStep:
    condition: fldArt == 41 || fldArt == 92 || fldArt == 109 # Filter auf bestimmte Belegarten
    step: freigabe_er # Leitet zum ersten Bearbeitungsschritt weiter

# Definition der einzelnen Prozessphasen
steps:
  - name: freigabe_er
    stepType: UserStep
    group: ER Controlling
    allowInquiry: true # Erlaubt Rückfragen in diesem Schritt
    fields:
      # Einfache Felder aus der Haupttabelle
      - name: fldBelegNr
        label: Beleg-Nr
        visible: true
        editable: false
      # Felder aus verknüpften Objekten (2. Ebene) mittels Punkt-Notation
      - name: acoGPreis.totalNetAmount
        label: Gesamtpreis netto
        visible: true
        editable: false
      # Felder aus Untertabellen (Positionen)
      - name: tblTransactionItems.fldArtNr
        label: Artikelnummer
        visible: true
        editable: false
      - name: tblTransactionItems.fldBez(as:TEXT) # Beispiel für eine explizite Typangabe (z.B. für RTF)
        label: Bezeichnung
        visible: true
        editable: false
      # Dokumenten-Referenz für die Anzeige des Beleg-PDFs
      - name: fldDokGUID
        label: Dokument
        visible: true
        editable: false
    nextSteps:
      # Schaltflächen für die Benutzerentscheidung
      - label: Freigabe
        color: success
        icon: i-lucide-check-circle
        step: approve # Verweist auf den SystemStep 'approve'
      - label: Ablehnung
        color: error
        icon: i-lucide-x-circle
        step: reject  # Verweist auf den SystemStep 'reject'
    # Benachrichtigungen (Values für Dokumentationszwecke entfernt)
    teamsWebhookUrl: ''
    notificationEmail: ''

  # Automatischer Abschluss bei Erfolg
  - name: approve
    stepType: SystemStep
    action: approve

  # Automatischer Abschluss bei Ablehnung
  - name: reject
    stepType: SystemStep
    action: reject

Workflow Blueprint ​

Die hierarchische Struktur ​

Identität und Trigger ​

Kopfdaten ​

Übersichtssfelder (overviewField1 & overviewField2) ​

Der Trigger-Mechanismus ​

Die Bearbeitungsschritte ​

UserStep (Fachliche Bearbeitung) ​

SystemStep (Automatisierung) ​

Feldsichtbarkeit und UI-Steuerung ​

Übergänge und Entscheidungslogik ​

Bedingungen (Conditions) ​

Visuelle Gestaltung (Farben und Icons) ​

Icon-Konfiguration (icon) ​

Farb-Konfiguration (color) ​

Vollständiges Praxisbeispiel ​

Workflow Blueprint

Die hierarchische Struktur

Identität und Trigger

Kopfdaten

Übersichtssfelder (`overviewField1` & `overviewField2`)

Der Trigger-Mechanismus

Die Bearbeitungsschritte

UserStep (Fachliche Bearbeitung)

SystemStep (Automatisierung)

Feldsichtbarkeit und UI-Steuerung

Übergänge und Entscheidungslogik

Bedingungen (Conditions)

Visuelle Gestaltung (Farben und Icons)

Icon-Konfiguration (`icon`)

Farb-Konfiguration (`color`)

Vollständiges Praxisbeispiel