Creating a workflow

With dbxWorkflow_admin, administrators define traceable processes. dbxWorkflow then executes these definitions step by step. This tutorial shows how a testable workflow definition emerges from a technical goal.

Authoritative source: The active definitions are executed from dbxWorkflow_admin. An unknown or deactivated workflow key does not start a replacement or demo process.

From Idea to Definition

Clarifying the objective

What should be achieved in the end technically?

Modeling steps

Order inputs, actions, tests and decisions.

Domain modules binding

Connect selection, prefill and finish logic.

Validation

Save, restart and test each branch.

1. Write down technical objective

Do not start with fields, but with a clear result. A workflow is well tailored when users understand what is achieved after completion and what evidence to support it needs to be.

“An existing shop article is published with verified channel data and has an external offer ID.”

From this, selection, readiness testing, data maintenance, explicit export and status control can be derived.

2. Creating a new definition

Open Workflow definitions and choose New workflow. Fill in the header data completely first.

Field	Meaning	Example
Workflow Key	Stable technical key, do not change it after publication without a migration plan	`shop_ebay_publish`
Name	Understandable title for users	Publish products on eBay
Objective	Technically achieved final result	eBay offer is published
Description	Limitations and benefits of the process	Checks data, confirms export and controls feedback
Active	Only active definitions can be restarted	Activate only after successful test

Key rule: The Workflow Key is a stable interface. Use lower case, numerals and underscores. The meaning should be technical, not “workflow 1”.

3. Select building blocks

The visual designer offers four building block types:

Building block	Suitable for	Example
Entry	Capture a value or select a record	Selecting Articles
Action	Explicit domain action or external process	Exporting
Test	Control completeness or status	Examine channel readiness
Decision	Create a result that determines the further branch	Release granted?

Click on a building block or drag it into the process. Change the order on the handle. After each change, connecting lines and step positions are recalculated.

4. Describe each step clearly

Open the details of the building block and maintain at least label, internal key, result and editing path.

Title: Describes the current task as action.
Internal key: within the workflow, e.g. B. approval_result.
Result / Status afterwards: understandable intermediate status.
Processing: Form, selection, new installation or module form.
Values: one or more values.
Duty: necessary or optional.
Note: specific work instructions without technical internals.

5. Defining choices and decisions

Options are recorded line by line. With wert=Beschriftung Separate stored value and visible text:

approved=Freigegeben
changes=Änderung notwendig
rejected=Abgelehnt

A decision requires at least two results. For later dependencies, use the stored value, not the visible label.

6. Build branches

A dependent step always refers to a previous step and optionally to its result.

Freigabe prüfen
├─ approved → Execution of order
└─ changes Then ask questions.

Place decision before branch steps.
At “Prerequisite / branch” select the key of the decision.
If ‘Only for Result’, enter the expected stored value.
Check at least one traceable path for each permitted decision value.

7. Explicit use of automatic tests

For tests: Automatically check, otherwise manually are selected. Only reliable observations for which the domain module can reliably deliver a value are automated.

Appropriate: Mandatory data complete, mapping available, stored status, internal rule.
Do not invisibly automate: Payment, shipping, publication, mailing or other actions that are difficult to reverse.
If no safe value is determined, the step must remain manually editable.

8. Determining the processing path

Way	Use
Form	Capture a short value or confirmation directly in the workflow.
Selection	Select static options or records loaded via binding.
New plant	Offer simple new investment within the step.
Module form	Open an existing module form and subsequently confirm storage.

9. Complement module binding

A binding connects the general workflow engine to a domain DD. Open Module bindings and choose New binding. The generator can read DD fields and existing summary templates of a module.

Select the module, e.g. B. dbxContact or dbxShop.
Select suitable Data Dictionary (DD) and generate binding.
Name Bind-Key clearly and technically.
Check selection source, pre-occupation and allowed module links.
Limit finish logic only to the intended record.
Save binding and select the bind reference in the workflow step.

10. Validate and store

The designer checks the sequence already when editing; during storage, the server-side binding validation follows. Typical tests:

at least one active step
Name and unique key per step
at least two outcomes for decisions
Dependencies exist and only point to earlier steps
Objective and title are understandable

Only save when validation errors are no longer displayed. Then return to the list and start the workflow via the Start action.

11. Testing changes correctly

Snapshot Rule: At start, the instance stores the current normalized definition status. A later admin change applies to new launches; an already running pass remains unchanged.

Save definition.
Start a new instance – do not continue to use an old instance.
Test mandatory, optional and error paths.
Go through each decision branch separately.
Check automatically with existing and missing technical value.
Test finish with valid and invalid technical data.

Final check for definitions

Workflow key stable, unique and technically named
Name, destination and description understandable to users
Steps in meaningful order with unique keys
Decision values and dependencies completely
External actions remain visible and explicitly confirmed
Bindings, module links and finish logic checked
All branches tested with new instances
Definition only activated after successful test

Further: Using the workflow All tutorials

Text walkthrough

The slideshow remains the visual tutorial. These steps provide a complete text fallback.

Prerequisite: Sign in with an account that has access to the area shown in the tutorial.

From Idea to Definition
Clarifying the objective
What should be achieved in the end technically?
Modeling steps
Order inputs, actions, tests and decisions.
Domain modules binding
Connect selection, prefill and finish logic.
Validation
Save, restart and test each branch.
Write down technical objective
Do not start with fields, but with a clear result. A workflow is well tailored when users understand what is achieved after completion and what evidence to support it needs to be.
Creating a new definition
Open Workflow definitions and choose New workflow. Fill in the header data completely first.
Select building blocks
The visual designer offers four building block types:
Describe each step clearly
Open the details of the building block and maintain at least label, internal key, result and editing path.
Defining choices and decisions
Options are recorded line by line. With wert=Beschriftung Separate stored value and visible text:
Build branches
A dependent step always refers to a previous step and optionally to its result.
Explicit use of automatic tests
For tests: Automatically check, otherwise manually are selected. Only reliable observations for which the domain module can reliably deliver a value are automated.

Checkpoint: After the final step, reload the target page and confirm that the expected state remains active.

Common errors: If a control or record is missing, first check permissions, the active language, filters and whether the preceding step was saved.