Creating a workflow template

The minimum configuration: when is a workflow template "valid"?

A workflow template is only fully usable in this app once at least these criteria are met:

  1. Active = Yes (the template must be active)
  2. Primary Table is set
  3. Rule Set exists (is created/updated automatically when the primary table is set)
  4. At least one normal step (Step Type = Normal) exists
  5. At least one workflow trigger exists and is active

When you activate the template, the app runs a validation and shows an error list if necessary.

image-1766411421921.png

Step 0 – Check supported tables & events (must-know)

What are "AWF Supported Tables"?

In "AWF Supported Tables" you maintain which tables can be selected as the primary table at all.

Important:

image-1766411778422.png

Initialize default tables

Since AWF Supported Tables is not directly searchable via Tell Me, open the page as follows:

  1. Open AWF Workflow Templates.
  2. Open a template (or create a new template).
  3. In the "Primary Table" area, open the lookup of "Primary Table ID"..
  4. In the opened list AWF Supported Tables Action "Initialize Default Tables" run it (it is also initialized directly when opening).
  5. Confirm.

This action initializes or repairs the default configuration.

image-1770031600177.png

View workflow events per table

On AWF Supported Tables:

image-1770031630214.png

 

Create a workflow template

Create a new workflow template

  1. Open AWF Workflow Templates.
  2. New.
  3. Fill in the area General:
    • Code (unique)
    • Description
    • Active initially No (recommended)

image-1766414874909.png

Set the primary table (decisive, as this is the table the workflow is started for)

  1. In the workflow template (card), go to the area "Primary Table".
  2. Field "Primary Table ID" select.
    • The list opens: AWF Supported Tables.
  3. Select a table.
  4. Check whether "Primary Table Caption" is filled automatically.

What happens in the background:

  • The app automatically creates/updates a Rule Set for the template.
  • The primary table is automatically stored as the Primary Table in the rule set.

Filter document type

Older versions had a Primary Document Type directly in the workflow template. This configuration was replaced by the Rule Engine .

If you want to start the workflow only for certain document types, or model different steps per document type, you now solve this via Rule Conditions:

1. Open the appropriate area (e.g. Workflow Trigger → Show Rules))
2. Create a rule condition (action Show Conditions).
). 3. Choose as the source field e.g. "Document Type" (a field of the primary table or a related table).
4. Set operator/value (e.g. "= Order").

Save the audit trail as PDF

When a workflow completes successfully, the audit trail can be saved automatically as a PDF file in the document attachments of the source record.

Configuration

  1. In the AWF Workflow Template → field "Save Audit Trail to Attachments" = Yes.
  2. On successful completion of the workflow, the audit trail report is generated automatically as a PDF and attached as a document attachment to the source record.

Attachments FactBox

In the AWF Workflow Instance card attachments from two sources are shown combined:

  • Attachments of the source record (e.g. scanned invoices)
  • Attachments of the workflow instance (e.g. generated audit-trail PDFs)

This gives approvers and administrators all relevant documents in one place.

Configure related tables (optional)

Why do I need related tables?

The rule engine can check conditions not only on the primary table, but also on related tables (e.g. header/lines).

You define these related tables in the template in the area:

  • Related Tables (technically: "DXP Rule Set Tables")

Add a related table

  1. In the template, in the section, Related Tables create a new line.
  2. Table ID select (lookup).
  3. Define the relation to the primary table:
    • Relation Field 1 (field number in the related table)
    • Primary Field 1 (field number in the primary table)
    • Optionally also Relation Field 2 / Primary Field 2 etc.

Rule of thumb:

image-1770031936324.png

Important: Without a correctly defined relation, the rule engine cannot cleanly evaluate fields of the related table against the current record.

Define steps

Basic structure of the steps

In the template there is the section Steps. A step contains, among others:

  • Step Code
  • Step Name
  • Order
  • Step Type (Normal / Error / Final)
  • Allow Record Editing
  • Assignment logic
  • Approvals / Related Approvals: optionally enable line approvals (Enable Related Approval) and set the Approval Mode .

image-1766415665254.png

Create the first "Normal" step

  1. In the section → Steps → New.
  2. Step Type = Normal.
  3. Step Code and Step Name assign.
  4. In the card, set the Assignee Type and set the Assignee .

Important system behavior:

  • When the first normal step is created, the app automatically generates:
    • an Errorstep (code e.g. ERROR)
    • an Finalstep (code e.g. FINAL)

Configure assignment

On the AWF Stepcard you maintain:

Notes:

If a step cannot resolve a valid assignee, the workflow is typically moved to the error step at runtime.

image-1766415688087.png

Due Date Formula (Due Date)

On the AWF Stepcard a Due Date Formula can be configured:



Step rules: how does the workflow move to the next step?

The app uses the DEXPRO Rules Engine to determine:

If no rule is defined, the respective step configuration applies.

Rule group per step ("Show Rules")

  1. In the Stepslist, mark the desired step.
  2. Action "Show Rules".

If no rule group is stored yet, the app automatically creates a Rule Group and enters it on the step.

image-1766416116752.png

Create rules (DEXPRO Core)

On the opened page Rules:

  1. New.
  2. Rule Code and Rule Name set.
  3. Sequence/Priority assign.
  4. Active = Yes.
  5. Optional:
    • Condition Conjunction (AND/OR)
    • Record Matching Type (Any Record / All Records)

image-1766416253261.png

 

Maintain Advanced Workflow fields on the rule (Next Step, Auto-Approve, Override Assignee)

On the rule there is the area "DEXPRO Advanced Workflow":

  1. Rule Action set (lookup/drilldown) and choose the desired action, e.g.
    • Step Transition
    • Override Assignee
    • Auto-Approve
  2. For Step Transition additionally choose Next Step (the lookup shows the next possible steps).
  3. If related approvals are active: Applies To set (Header / Related Only / Header and Related).
  4. For Override Assignee: Assignee Type and Assignee maintain.

image-1770032598479.png

Add conditions (rule conditions)

On the Rules page:

  1. Action "Show Conditions".
  2. Add one line per condition:
    • Source Table ID (primary table or related table)
    • Source Field ID (field)
    • Comparison Operator (operator)
    • Value (value; AssistEdit for Enum/Boolean/Between/In Set)

image-1766993224263.png

Tip: If you use conditions over related tables, the relation in Related Tables must be maintained correctly.

Test rules (without a real workflow)

On the Rules page there are:

This lets you check rules/rule conditions against a sample record before starting real workflows.

image-1766993340328.png

Configure workflow triggers

Workflow triggers determine when a new workflow instance is started.

In the template the section is called "Workflow Triggers".

Template triggers: basic fields

  1. In the template → section Workflow Triggers.
  2. New.
  3. Field Workflow Event select (AssistEdit → list "AWF Table Workflow Events").
  4. Active = Yes.
  5. Priority set (order when several matching triggers exist).

image-1766993429832.png

Trigger rules: when may a trigger fire?

On the trigger there is a Rule Group Code. Via the action "Show Rules":

  1. mark the trigger.
  2. Show Rules.
  3. Maintain rules/rule conditions as in Step rules .

Important system behavior:

image-1766993646446.png

 

OnAfterModify: Monitored fields

For the event OnAfterModify there is the action "Monitored Fields".

  1. Mark the trigger with the workflow event OnAfterModify .
  2. Action "Monitored Fields".
  3. select fields (lookup via "Fields Lookup").

image-1766995825420.png

Workflow action on completion

In the template there is the section "Workflow Action".

  1. Run action on completion enable.
  2. Action on Completion choose (depending on the primary table):
    • Release / Reopen (only for certain document tables)
    • Custom action (codeunit/report)
    • Define field value assignments

When Define field value assignments is selected, the section appears Field Value Assignments.

image-1766996199607.png

Cleanup (retention & cleanup)

Under Cleanup Configuration:

In addition there is the action:

image-1766996258454.png

Module: Escalation Engine

The escalation engine automatically monitors overdue approval requests and runs definable escalation steps. This lets you model reminders, automatic delegations, or reassignments on a time-based schedule.

How it works

Prerequisites


Configure escalation steps

At template level (default for all steps)

  1. In the AWF Workflow Template → section "Escalation Steps".
  2. New.
  3. Fill in the fields:
    • Step No.: running number (determines the order).
    • Description: description of the escalation step (e.g. "Reminder after 1 day").
    • Overdue Duration: date formula relative to the due date (e.g. <+1D> = 1 day after due, <+1W> = 1 week after due).
    • Escalation Action: action that runs when the overdue duration is reached.
    • Enabled: Yes/No.

At step level (overrides template level)

  1. In the AWF Stepcard → section "Escalation Steps".
  2. Create steps as described above.
  3. If a workflow step has its own escalation steps, the template escalation steps are not considered for this step.

Escalation actions

Action Description
Send Notification Sends an escalation notification (via the standard BC notification mechanism).
Delegate Delegates the approval automatically via the BC standard substitute chain (from "Approval User Setup").
Reassign Reassigns the approval to a defined recipient. Recipient Type and Recipient Code are configured (user or workflow user group).
Custom Action Runs a custom object (codeunit or report). Optionally the source record can be passed (Pass Source Record).

Configure recipient (for "Send Notification" and "Reassign")


Rule-based escalation (optional)

Escalation steps can optionally have a Rule Group Code . When set, the escalation step only runs if the rule conditions of the rule group match for the current record.

Due date and escalation

For the escalation to work meaningfully, a Due Date Formula must be maintained in the step:

  1. In the step: set the field "Due Date Formula" (e.g. <+3D> = due 3 days after the approval is created).
  2. The escalation duration is added on top of the due date: if the due date formula is <+3D> and the overdue duration is <+1D> the escalation step runs 4 days after the approval is created.

If an approval entry has no due date , a prompt for manual entry is shown if necessary.

Module: Rejection Handling

The rejection behavior in Advanced Workflow is configurable and controls what happens when an approver rejects an approval request.

Default behavior (without special configuration)

Rejection group for related approvals (lines)

If you use related approvals (line approvals), you can specify to whom rejected line approvals are reassigned:

Configuration at template level

  1. In the AWF Workflow Template → area Rejection Settings:
    • Use Rejection Group for Related = Yes
    • Default Assignee Type for Rejection Approver / Workflow User Group / Salesperson/Purchaser
    • Default Assignee for Rejection: specific user or group

Configuration at step level (overrides template level)

  1. In the AWF Stepcard → area Rejection Behavior:
    • Use Rejection Group for Related = Yes
    • Default Assignee Type for Rejection and Default Assignee for Rejection as above
  2. If a step has its own rejection settings, these override the template settings.

Rejection group for header approvals

Normally, rejecting the header approval leads back to the previous step (or cancellation in the first step). Alternatively, you can configure the header rejection to keep the workflow on the current step and reassign it to a rejection group:

  1. Use Rejection Group for Header Rejection = Yes
  2. Assignee Type for Header Rejection: Approver / Workflow User Group / Salesperson/Purchaser
  3. Assignee for Header Rejection: specific user or group

The configuration is possible at both template and step level (step level overrides template level).

Rejection reason and reassignment for lines

When rejecting a related approval, a dialog opens: