# Erstellung einer Workflowvorlage

# Die Mindestkonfiguration: Wann ist eine Workflowvorlage „gültig“?

Eine Workflowvorlage ist in dieser App erst dann vollständig einsetzbar, wenn mindestens diese Kriterien erfüllt sind:

<div id="bkmrk-aktiv-%3D-ja%C2%A0%28die-vorl">1. **Aktiv = Ja** (die Vorlage muss aktiv sein)
2. **Primäre Tabelle** ist gesetzt
3. <div><div>**Regelsatz** ist vorhanden (wird beim Setzen der Primärtabelle automatisch erstellt/aktualisiert)</div></div>
4. **Mindestens ein normaler Schritt (Schritttyp = Normal)** ist vorhanden
5. **Mindestens ein Workflowauslöser** ist vorhanden und **aktiv**

</div>Wenn Sie die Vorlage aktivieren, führt die App eine Validierung aus und zeigt ggf. eine Fehlerliste an.

[![image-1766411421921.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766411421921.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766411421921.png)

# Schritt 0 – Unterstützte Tabellen & Ereignisse prüfen (Pflichtwissen)

### Was sind „AWF Unterstützte Tabellen“?

In **„AWF Unterstützte Tabellen“** pflegen Sie, welche Tabellen überhaupt als Primärtabelle auswählbar sind.

Wichtig:

<div id="bkmrk-in-der-workflowvorla">- In der Workflowvorlage können **nur unterstützte Tabellen** als Primärtabelle gewählt werden.
- Pro unterstützter Tabelle werden zusätzlich gepflegt: 
    - **Workflowereignisse** (welche Events als Auslöser genutzt werden dürfen)

</div>[![image-1766411778422.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766411778422.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766411778422.png)

### Default-Tabellen initialisieren

Da **AWF Unterstützte Tabellen** nicht direkt per Tell Me suchbar ist, rufen Sie die Seite so auf:

<div id="bkmrk-%C3%96ffnen-sie%C2%A0awf-workf">1. Öffnen Sie **AWF Workflowvorlagen**.
2. Öffnen Sie eine Vorlage (oder legen Sie eine neue Vorlage an).
3. Im Bereich **„Primäre Tabelle“** öffnen Sie das Lookup von **„Primäre Tabellen-ID“**.
4. In der geöffneten Liste **AWF Unterstützte Tabellen** Aktion **„Standardtabellen initialisieren“** ausführen (wird auch direkt beim Öffnen initialisiert).
5. Bestätigen.

</div>Diese Aktion initialisiert bzw. repariert die Standardkonfiguration.

[![image-1770031600177.png](https://docs.squeeze.one/uploads/images/gallery/2026-02/scaled-1680-/image-1770031600177.png)](https://docs.squeeze.one/uploads/images/gallery/2026-02/image-1770031600177.png)

### Workflowereignisse pro Tabelle ansehen

Auf **AWF Unterstützte Tabellen**:

<div id="bkmrk-aktion%C2%A0%E2%80%9Eworkflowerei">- Aktion **„Workflowereignisse“**: zeigt gültige Workflowereignisse für die Tabelle

</div>[![image-1770031630214.png](https://docs.squeeze.one/uploads/images/gallery/2026-02/scaled-1680-/image-1770031630214.png)](https://docs.squeeze.one/uploads/images/gallery/2026-02/image-1770031630214.png)

# Workflowvorlage erstellen

### Neue Workflowvorlage anlegen

<div id="bkmrk-%C3%96ffnen-sie%C2%A0awf-workf"><div>1. Öffnen Sie **AWF Workflowvorlagen**.
2. **Neu**.
3. Füllen Sie im Bereich **Allgemein**: 
    - **Code** (eindeutig)
    - **Beschreibung**
    - **Aktiv** zunächst **Nein** (empfohlen)

</div></div>[![image-1766414874909.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766414874909.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766414874909.png)

<div id="bkmrk--0"></div>### Primärtabelle setzen (entscheidend, da dies die Tabelle ist, für den der Workflow gestartet wird)

<div id="bkmrk-in-der-workflowvorla">1. In der Workflowvorlage (Karte) zum Bereich **„Primäre Tabelle“**.
2. Feld **„Primäre Tabellen-ID“** auswählen. 
    - Es öffnet sich die Liste **AWF Unterstützte Tabellen**.
3. Tabelle auswählen.
4. Prüfen, ob **„Primäre Tabelle Bezeichnung“** automatisch gefüllt wird.

</div>Was dabei im Hintergrund passiert:

<div id="bkmrk-die-app-erstellt%2Fakt"><div>- Die App erstellt/aktualisiert automatisch einen **Regelsatz** für die Vorlage.
- Die Primärtabelle wird automatisch als **Primäre Tabelle** im Rule Set hinterlegt.

</div></div>### Dokumenttyp/Belegart filtern

Ältere Versionen kannten eine **Primäre Belegart** direkt in der Workflowvorlage. Diese Konfiguration wurde durch die **Regel-Engine** ersetzt.

Wenn Sie den Workflow z. B. nur für bestimmte Belegarten starten oder unterschiedliche Schritte je Belegart abbilden möchten, lösen Sie das jetzt über **Regelbedingungen**:

<div id="bkmrk-1.-%C3%96ffnen-sie-den-pa"><div>1. Öffnen Sie den passenden Bereich (z. B. **Workflowauslöser** → **Regeln anzeigen**)   
2. Legen Sie eine Regelbedingung an (Aktion **Bedingungen anzeigen**).   
3. Wählen Sie als Quellfeld z. B. "Belegart" (Feld der Primärtabelle bzw. einer zugehörigen Tabelle).   
4. Setzen Sie Operator/Wert (z. B. „= Auftrag“).  
  
</div></div>### Audit Trail als PDF speichern

Wenn ein Workflow erfolgreich abgeschlossen wird, kann der Audit Trail automatisch als PDF-Datei in den **Dokumentanhängen** des Quelldatensatzes gespeichert werden.

#### Konfiguration

<div id="bkmrk-in-der%C2%A0awf-workflowv"><div>1. In der **AWF Workflowvorlage** → Feld **„Audit Trail in Anhänge speichern"** = Ja.
2. Beim erfolgreichen Abschluss des Workflows wird der Audit-Trail-Bericht automatisch als PDF generiert und als Dokumentanhang an den Quelldatensatz angehängt.

</div></div>### Anhänge-FactBox

In der **AWF Workflowinstanz-Karte** werden Anhänge aus zwei Quellen kombiniert angezeigt:

<div id="bkmrk-anh%C3%A4nge-des-quelldat"><div>- **Anhänge des Quelldatensatzes** (z. B. eingescannte Rechnungen)
- **Anhänge der Workflowinstanz** (z. B. generierte Audit-Trail-PDFs)

</div></div>Damit haben Genehmiger und Administratoren alle relevanten Dokumente an einem Ort.

# Zugehörige Tabellen konfigurieren (optional)

### Warum brauche ich zugehörige Tabellen?

Die Rule Engine kann Bedingungen nicht nur auf der Primärtabelle prüfen, sondern auch auf **zugehörigen Tabellen** (z. B. Kopf/Zeilen).

Diese zugehörigen Tabellen definieren Sie in der Vorlage im Bereich:

<div id="bkmrk-zugeh%C3%B6rige-tabellen-"><div>- **Zugehörige Tabellen** (technisch: „DXP Rule Set Tables bzw. Regelsatztabellen“)

</div></div>### Zugehörige Tabelle hinzufügen

<div id="bkmrk-in-der-vorlage-im-ab">1. In der Vorlage im Abschnitt **Zugehörige Tabellen** eine neue Zeile anlegen.
2. **Tabellen-ID** wählen (Lookup).
3. Beziehung zur Primärtabelle definieren: 
    - <div><div>**Beziehungsfeld 1** (Feldnummer in der Related Table)</div></div>
    - **Primärfeld 1** (Feldnummer in der Primärtabelle)
    - <div><div>Optional zusätzlich **Beziehungsfeld 2 / Primärfeld 2** usw.</div></div>

</div>Faustregel:

<div id="bkmrk-beziehungsfeld%28er%29-%3D">- <div><div>Beziehungsfeld(er) = „Fremdschlüssel“ in der zugehörigen Tabelle</div></div>
- <div><div>Primärfeld(er) = die passenden Schlüssel-/Referenzfelder in der Primärtabelle</div></div>

</div>[![image-1770031936324.png](https://docs.squeeze.one/uploads/images/gallery/2026-02/scaled-1680-/image-1770031936324.png)](https://docs.squeeze.one/uploads/images/gallery/2026-02/image-1770031936324.png)

**Wichtig:** Ohne korrekt definierte Relation kann die Regel-Engine Felder der zugehörigen Tabelle nicht sauber gegen den aktuellen Datensatz auswerten.

# Schritte definieren

### Grundstruktur der Schritte

In der Vorlage gibt es den Abschnitt **Schritte**. Ein Schritt enthält u. a.:

<div id="bkmrk-schritt-code-schritt"><div>- **Schritt Code**
- **Schritt Name**
- **Reihenfolge**
- **Schritttyp** (Normal / Error / Final)
- **Datensatzbearbeitung erlauben**
- Zuständigkeitslogik
- <div><div>**Genehmigungen / Zugehörige Genehmigungen**: optional Zeilen-Genehmigungen aktivieren (**Zugehörige Genehmigung aktivieren**) und **Genehmigungsmodus** festlegen</div></div>

</div></div>[![image-1766415665254.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766415665254.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766415665254.png)

<span style="color: #222222; font-size: 2.333em; font-weight: 400;">Ersten „Normal“-Schritt anlegen</span>

<div id="bkmrk-im-abschnitt%C2%A0schritt"><div><div>1. Im Abschnitt **Schritte** → **Neu**.
2. **Schritttyp = Normal**.
3. **Schritt Code** und **Schritt Name** vergeben.
4. In der Karte **Art des Zuständigen** festlegen und **Zuständiger** setzen.

</div></div></div>Wichtiges Systemverhalten:

<div id="bkmrk-beim-anlegen-des-ers"><div><div>- Beim Anlegen des ersten Normal-Schritts erzeugt die App automatisch: 
    - einen **Error**-Schritt (Code z. B. `ERROR`)
    - einen **Final**-Schritt (Code z. B. `FINAL`)

</div></div></div>### Zuständigkeit konfigurieren

Auf der **AWF Schritt**-Karte pflegen Sie:

<div id="bkmrk-art-des-zust%C3%A4ndigen-">- **Art des Zuständigen**
- **Zuständiger
- **Einschränkungsart Genehmiger**

</div>Hinweise:

<div id="bkmrk-bei%C2%A0salesperson%2Fpurc">- Bei **Salesperson/Purchaser** wird der Zuständige automatisch aus dem Datensatz (Verkäufer/Einkäufer) abgeleitet.
- Bei **Workflow User Group** muss eine Workflow-Benutzergruppe existieren und Mitglieder haben.

</div>Wenn ein Schritt keinen gültigen Zuständigen auflösen kann, wird der Workflow zur Laufzeit typischerweise in den Fehlerschritt verschoben.

[![image-1766415688087.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766415688087.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766415688087.png)

### Fälligkeitsdatumsformel (Due Date)

In der **AWF Schritt**-Karte kann eine **Fälligkeitsdatumsformel** konfiguriert werden:

- Feld: **Fälligkeitsdatumsformel** (z. B. `<+3D>`, `<+1W>`, `<+2W>`)
- Wenn gesetzt, erhalten Genehmigungseinträge, die in diesem Schritt erzeugt werden, automatisch ein Fälligkeitsdatum.
- Das Fälligkeitsdatum ist relevant für: 
    - Die Anzeige in **„Zu genehmigende Anforderungen"**
    - Die **Eskalations-Engine** (Eskalationsschritte basieren auf dem Fälligkeitsdatum)
    - Standard-BC-Fälligkeitsbenachrichtigungen

# Schritt-Regeln: Wie wechselt der Workflow zum nächsten Schritt?

Die App nutzt die DEXPRO Rules Engine, um zu bestimmen:

<div id="bkmrk-welche-regel-passt-z">- welche Regel passt
- zu welchem **nächsten Schritt** gewechselt wird
- ob der Zuständige überschrieben wird
- ob automatisch genehmigt wird
- und ob die Aktion für die Kopfgenehmigung, zugehörige Genehmigungen (Zeilen) oder beides gilt.

</div>Wenn keine Regel definiert ist, ist die jeweilige Konfiguration des Schrittes gültig.

### Regelgruppe pro Schritt („Regeln anzeigen“)

<div id="bkmrk-in-der%C2%A0schritte-list">1. In der **Schritte**-Liste den gewünschten Schritt markieren.
2. Aktion **„Regeln anzeigen“**.

</div>Wenn noch keine Regelgruppe hinterlegt ist, erstellt die App automatisch eine **Regelgruppe** und trägt sie im Schritt ein.

[![image-1766416116752.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766416116752.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766416116752.png)

### Regeln anlegen (DEXPRO Core)

In der geöffneten Seite **Regeln**:

<div id="bkmrk-neu.-regelcode%C2%A0und%C2%A0r"><div>1. **Neu**.
2. **Regelcode** und **Regelname** setzen.
3. **Sequenz/Priorität** vergeben.
4. **Aktiv = Ja**.
5. Optional: 
    - **Bedingungsverknüpfung** (UND/ODER)
    - **Datensatzabgleichsart** (Beliebiger Datensatz / Alle Datensätze)

</div></div>[![image-1766416253261.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766416253261.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766416253261.png)

### Advanced-Workflow Felder auf der Regel pflegen (Nächster Schritt, Automatisch Genehmigen, Zuständigen Überschreiben)

In der Regel gibt es den Bereich **„DEXPRO Advanced Workflow“:**

<div id="bkmrk-regelaktion-setzen-%28"><div>1. **Regelaktion** setzen (Lookup/Drilldown) und die gewünschte Aktion auswählen, z. B. 
    - **Schrittübergang**
    - **Zuständigen überschreiben**
    - **Automatisch genehmigen**
2. Bei **Schrittübergang** zusätzlich **Nächster Schritt** wählen (Lookup zeigt die nächsten möglichen Schritte).
3. Wenn zugehörige Genehmigungen aktiv sind: **Gilt für** setzen (Kopf / Nur Zugehörige / Kopf und Zugehörige).
4. Bei **Zuständigen überschreiben:** **Art des Zuständigen** und **Zuständiger** pflegen.

</div></div>[![image-1770032598479.png](https://docs.squeeze.one/uploads/images/gallery/2026-02/scaled-1680-/image-1770032598479.png)](https://docs.squeeze.one/uploads/images/gallery/2026-02/image-1770032598479.png)

### Bedingungen (Regelbedingungen) hinzufügen

In der Regeln-Seite:

1. Aktion **„Bedingungen anzeigen“**.
2. Pro Bedingung eine Zeile hinzufügen: 
    - **Quelltabellen-ID** (Primärtabelle oder zugehörige Tabelle)
    - **Quellfeld-ID** (Feld)
    - **Vergleichsoperator** (Operator)
    - **Wert** (Wert; AssistEdit bei Enum/Boolean/Between/In Set)

[![image-1766993224263.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766993224263.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766993224263.png)

**Tipp:** Wenn Sie Bedingungen über zugehörige Tabellen nutzen, muss die Relation in **Zugehörige Tabellen** korrekt gepflegt sein.

### Regeln testen (ohne echten Workflow)

Auf der Regeln-Seite gibt es:

- **Regel testen**
- **Regelgruppe testen**

Damit prüfen Sie Regeln/Regelbedingungen gegen einen Beispieldatensatz, bevor Sie echte Workflows starten.

[![image-1766993340328.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766993340328.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766993340328.png)

# Workflowauslöser konfigurieren

Workflowauslöser bestimmen, **wann** eine neue Workflowinstanz gestartet wird.

In der Vorlage heißt der Abschnitt **„Workflowauslöser“**.

### Vorlagenauslöser: Grundfelder

1. In der Vorlage → Abschnitt **Workflowauslöser**.
2. **Neu**.
3. Feld **Workflowereignis** auswählen (AssistEdit → Liste „AWF Tabellen Workflowereignisse“).
4. **Aktiv = Ja**.
5. **Priorität** festlegen (Reihenfolge bei mehreren passenden Auslösern).

[![image-1766993429832.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766993429832.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766993429832.png)

### Trigger-Regeln: Wann darf ein Auslöser feuern?

Im Auslöser gibt es **Regelgruppencode**. Über die Aktion **„Regeln anzeigen“**:

1. Auslöser markieren.
2. **Regeln anzeigen**.
3. Regeln/Regelbedingungen wie in [Schritt-Regeln](https://docs.squeeze.one/books/advanced-workflow-for-dynamics-365-bc-de-de/page/schritt-regeln-wie-wechselt-der-workflow-zum-nachsten-schritt "Schritt-Regeln: Wie wechselt der Workflow zum nächsten Schritt?") pflegen.

Wichtiges Systemverhalten:

- Wenn **keine Regelbedingungen** für diese Trigger-Regelgruppe existieren, gilt der Auslöser als erfüllt (der Trigger feuert dann grundsätzlich).

[![image-1766993646446.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766993646446.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766993646446.png)

### OnAfterModify: Überwachte Felder

Für das Event **OnAfterModify** gibt es die Aktion **„Überwachte Felder“**.

1. Auslöser mit Workflowereignis **OnAfterModify** markieren.
2. Aktion **„Überwachte Felder“**.
3. Felder auswählen (Lookup über „Fields Lookup“).

[![image-1766995825420.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766995825420.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766995825420.png)

- In der aktuellen Implementierung wird ein OnAfterModify-Auslöser **nur dann** gestartet, wenn **mindestens ein überwachtes Feld** gepflegt ist **und** sich dieses Feld tatsächlich geändert hat.
- Wenn keine überwachten Felder gepflegt sind, wird der Auslöser bei OnAfterModify nicht gestartet.

# Workflowaktion bei Abschluss

In der Vorlage gibt es den Abschnitt **„Workflowaktion“**.

1. **Aktion bei Abschluss ausführen** aktivieren.
2. **Aktion bei Abschluss** wählen (abhängig von der Primärtabelle): 
    - Release / Reopen (nur für bestimmte Belegtabellen)
    - Benutzerdefinierte Aktion (Codeunit/Report)
    - Feldwertzuweisungen festlegen

Wenn **Feldwertzuweisungen festlegen** gewählt ist, erscheint der Abschnitt **Feldwertzuweisungen**.

[![image-1766996199607.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766996199607.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766996199607.png)

# Bereinigung (Aufbewahrung & Bereinigung)

Unter **Bereinigungskonfiguration**:

- **Automatische Bereinigung aktiviert**
- **Aufbewahrungsfrist für Bereinigung** (DateFormula, z. B. `-1M`)

Zusätzlich gibt es die Aktion:

- **„Alte Instanzen bereinigen“**

[![image-1766996258454.png](https://docs.squeeze.one/uploads/images/gallery/2025-12/scaled-1680-/image-1766996258454.png)](https://docs.squeeze.one/uploads/images/gallery/2025-12/image-1766996258454.png)

# Modul: Eskalations-Engine

Die Eskalations-Engine überwacht automatisch überfällige Genehmigungsanforderungen und führt definierbare Eskalationsschritte aus. Damit lassen sich Erinnerungen, automatische Delegierungen oder Neuzuweisungen zeitgesteuert abbilden.

### Funktionsweise

- Die Eskalation wird über einen **Aufgabenwarteschlangenposten** gesteuert, der regelmäßig alle offenen Genehmigungseinträge prüft.
- Für jeden überfälligen Eintrag wird geprüft, ob ein Eskalationsschritt fällig ist (basierend auf **„Überfälligkeitsdauer"** relativ zum Fälligkeitsdatum der Genehmigung).
- Eskalationsschritte können auf **Vorlagenebene** (gelten als Standard für alle Schritte) und/oder auf **Schrittebene** (überschreiben die Vorlageneinstellung für diesen Schritt) definiert werden.
- Der höchste bereits ausgeführte Eskalationsschritt wird im Genehmigungseintrag im Feld **„Eskalationsstufe"** nachgehalten, damit kein Schritt doppelt ausgeführt wird.

### Voraussetzungen

<div data-line="653" id="bkmrk-"></div><div id="bkmrk-der%C2%A0eskalations-aufg">- Der **Eskalations-Aufgabenwarteschlangenposten** muss eingerichtet und aktiv sein (siehe [AWF Einrichtung](https://docs.squeeze.one/books/advanced-workflow-for-dynamics-365-bc-de-de/page/awf-einrichtung-setup "AWF Einrichtung (Setup)")).
- Die Genehmigungseinträge müssen ein **Fälligkeitsdatum** haben (konfigurierbar über **„Fälligkeitsdatumsformel"** im Schritt).

<div data-line="658">  
</div></div>### Eskalationsschritte konfigurieren

#### Auf Vorlagenebene (Standard für alle Schritte)

1. In der **AWF Workflowvorlage** → Abschnitt **„Eskalationsschritte"**.
2. **Neu**.
3. Felder ausfüllen: 
    - **Schrittnr.**: Laufende Nummer (bestimmt die Reihenfolge).
    - **Beschreibung**: Beschreibung des Eskalationsschrittes (z. B. „Erinnerung nach 1 Tag").
    - **Überfälligkeitsdauer**: Datumsformel relativ zum Fälligkeitsdatum (z. B. `<+1D>` = 1 Tag nach Fälligkeit, `<+1W>` = 1 Woche nach Fälligkeit).
    - **Eskalationsaktion**: Aktion, die bei Erreichen der Überfälligkeitsdauer ausgeführt wird.
    - **Aktiviert**: Ja/Nein.

<div data-line="673" id="bkmrk--0"></div>#### Auf Schrittebene (überschreibt Vorlagenebene)

1. In der **AWF Schritt**-Karte → Abschnitt **„Eskalationsschritte"**.
2. Schritte anlegen wie oben beschrieben.
3. Wenn ein Workflowschritt eigene Eskalationsschritte hat, werden die Vorlagen-Eskalationsschritte für diesen Schritt **nicht** berücksichtigt.

### Eskalationsaktionen

<table class="code-line" data-line="683" dir="auto" id="bkmrk-aktion-beschreibung-"><thead class="code-line" data-line="683" dir="auto"><tr class="code-line" data-line="683" dir="auto"><th>Aktion</th><th>Beschreibung</th></tr></thead><tbody class="code-line" data-line="685" dir="auto"><tr class="code-line" data-line="685" dir="auto"><td>**Benachrichtigung senden**</td><td>Sendet eine Eskalations-Benachrichtigung (über die Standard-BC-Benachrichtigungsmechanik).</td></tr><tr class="code-line" data-line="686" dir="auto"><td>**Delegieren**</td><td>Delegiert die Genehmigung automatisch über die BC-Standard-Stellvertreterkette (aus „Genehmigungsbenutzereinrichtung").</td></tr><tr class="code-line" data-line="687" dir="auto"><td>**Neu zuweisen**</td><td>Weist die Genehmigung an einen definierten Empfänger neu zu. Dabei werden **Empfängerart** und **Empfängercode** konfiguriert (Benutzer oder Workflow-Benutzergruppe).</td></tr><tr class="code-line" data-line="688" dir="auto"><td>**Benutzerdefinierte Aktion**</td><td>Führt ein benutzerdefiniertes Objekt aus (Codeunit oder Report). Optional kann der Quelldatensatz übergeben werden (**Quelldatensatz übergeben**).</td></tr></tbody></table>

### Empfänger konfigurieren (bei „Benachrichtigung senden" und „Neu zuweisen")

<div data-line="692" id="bkmrk--1"></div><div id="bkmrk-empf%C3%A4ngerart%3A-genehm">- **Empfängerart**: Genehmiger (konkreter Benutzer) oder Workflow-Benutzergruppe.
- **Empfängercode**: Benutzer-ID oder Code der Workflow-Benutzergruppe.
- Bei „Neu zuweisen" wird die Genehmigung auf den neuen Empfänger umgeleitet.
- Bei „Benachrichtigung senden" erhält der Empfänger eine Eskalationsbenachrichtigung.

<div data-line="699">  
</div></div>### Regelbasierte Eskalation (optional)

Eskalationsschritte können optional einen **Regelgruppencode** haben. Wenn gesetzt, wird der Eskalationsschritt nur ausgeführt, wenn die Regelbedingungen der Regelgruppe für den aktuellen Datensatz zutreffen.

### Fälligkeitsdatum und Eskalation

Damit die Eskalation sinnvoll funktioniert, muss im Schritt eine **Fälligkeitsdatumsformel** gepflegt sein:

1. Im Schritt: Feld **„Fälligkeitsdatumsformel"** setzen (z. B. `<+3D>` = Fälligkeit 3 Tage nach Erstellung der Genehmigung).
2. Die Eskalationsdauer addiert sich zum Fälligkeitsdatum: Wenn die Fälligkeitsdatumsformel `<+3D>` und die Überfälligkeitsdauer `<+1D>` beträgt, wird der Eskalationsschritt 4 Tage nach Erstellung der Genehmigung ausgeführt.

Wenn ein Genehmigungseintrag **kein Fälligkeitsdatum** hat, wird eine Eingabeaufforderung zur manuellen Eingabe angezeigt, sofern nötig.

# Modul: Ablehnungseinstellungen (Rejection Handling)

Das Ablehnungsverhalten im Advanced Workflow ist konfigurierbar und steuert, was passiert, wenn ein Genehmiger eine Genehmigungsanforderung ablehnt.

### Standardverhalten (ohne besondere Konfiguration)

- **Ablehnung im ersten Schritt**: Der Workflow wird abgebrochen (Status → Abgebrochen).
- **Ablehnung in einem späteren Schritt**: Der Workflow kehrt zum **vorherigen Schritt** zurück, und die Genehmigung wird neu erstellt.

### Ablehnungsgruppe für zugehörige Genehmigungen (Zeilen)

Wenn Sie zugehörige Genehmigungen (Zeilen-Genehmigungen) nutzen, können Sie festlegen, an wen abgelehnte Zeilen-Genehmigungen neu zugewiesen werden:

#### Konfiguration auf Vorlagenebene

1. In der **AWF Workflowvorlage** → Bereich **Ablehnungseinstellungen**: 
    - **Ablehnungsgruppe für Zugehörige verwenden** = Ja
    - **Art des Standard-Zuständigen für Ablehnung** Genehmiger / Workflow-Benutzergruppe / Verkäufer/Einkäufer
    - **Standard-Zuständiger für Ablehnung**: Konkreter Benutzer oder Gruppe

#### Konfiguration auf Schrittebene (überschreibt Vorlagenebene)

1. In der **AWF Schritt**-Karte → Bereich **Ablehnungsverhalten**: 
    - **Ablehnungsgruppe für Zugehörige verwenden** = Ja
    - **Art des Standard-Zuständigen für Ablehnung** und **Standard-Zuständiger für Ablehnung** wie oben
2. Wenn ein Schritt eigene Ablehnungseinstellungen hat, überschreiben diese die Vorlageneinstellungen.

### Ablehnungsgruppe für Kopf-Genehmigungen

Normalerweise führt eine Ablehnung der Kopf-Genehmigung zum Rücksprung in den vorherigen Schritt (oder zum Abbruch im ersten Schritt). Alternativ können Sie konfigurieren, dass die Kopf-Ablehnung den Workflow **im aktuellen Schritt** behält und an eine Ablehnungsgruppe neu zuweist:

1. **Ablehnungsgruppe für Kopfablehnung verwenden** = Ja
2. **Art des Zuständigen für Kopfablehnung**: Genehmiger / Workflow-Benutzergruppe / Verkäufer/Einkäufer
3. **Zuständiger für Kopfablehnung**: Konkreter Benutzer oder Gruppe

Die Konfiguration ist sowohl auf **Vorlage-** als auch auf **Schrittebene** möglich (Schrittebene überschreibt Vorlagenebene).

### Ablehnungsgrund und Neuzuweisung bei Zeilen

Beim Ablehnen einer zugehörigen Genehmigung öffnet sich ein Dialog:

- **Ablehnungsgrund**: Pflichtfeld – warum wird die Zeile abgelehnt?
- **Neuer Zuständiger**: Vorausgefüllt mit der konfigurierten Ablehnungsgruppe, kann aber manuell angepasst werden. 
    - **Empfängertyp**: Genehmiger / Workflow-Benutzergruppe / Verkäufer/Einkäufer
    - **Benutzer** oder **Workflow-Benutzergruppe** (je nach Art)