Creating a workflow

This page describes how a new dbxapp workflow is planned, built in the visual process designer, tested and connected to a domain module. The overall technical architecture and the complete JSON scheme are in the dbxWorkflow.

When a workflow makes sense

A workflow is right if a domain goal requires several comprehensible steps, for example:

• prepare a quotation of customer data, services and release;
• review, reply and close a contact request;
• prepare a shop article, review and publish channel data;
• make a decision and proceed differently depending on the outcome;
• Check data automatically before a user confirms an external action.

A workflow is not a substitute for an extensive domain form. Existing article, customer, CRM or ERP forms are opened as a module step and are not replicated in the workflow.

Designers open

Workflow management is in the admin menu under Workflow reachable.

A new definition is created here:

To edit an existing definition, its record ID is used:

The processing is limited to administrators. dbxRunAsAdmin is not a normal registration mechanism and may only be used temporarily in a protected test system.

Specify header data

Field	Purpose	Example
Workflow Key	Stable technical key	project offer
Name	visible title of the expiry	Prepare quotation
Objective	Result to be achieved at the end	Ready-to-ship tender
Description	Short technical statement	Check customer, services and release.
Active	Controls whether new instances can be started	Activated

The workflow key is stored in URLs, instances and bindings. It should be written in lower case, contain no spaces and should not be renamed after production use.

Only definitions from dbxWorkflow admin are executed. An unknown or deactivated key does not fall back on a demo workflow. The included examples are only added during installation if their key is still missing; Later admin adjustments are not automatically overwritten.

Building process with building blocks

The visual designer has a palette on the left and the sequence of Start up to Objective. A module can be clicked on or dragged into the sequence. Existing building blocks are moved on the handle. The connecting lines are redrawn after each change.

Building block	Use
Entry	Capture a value or select it from a list
Action	Open a domain form or carry out a explicitly confirmed action
Test	Controlling data or a provider status
Decision	generate a result value on which later branches depend

The details of a building block are opened by clicking on its header. For a clear sequence, the detail regions can be closed before pulling.

Properties of a step

Field	Meaning
Building block	Input, Action, check or Decision
Designation	understandable name for users
Internal key	A unique key within the workflow
Result / Status afterwards	visible event after successful processing
Permitted processing	one or more possibilities: Form, selection, new installation or module form
Standardisation	preferred processing path from the permitted possibilities
Automation	Check manually or automatically
Values	Single value or multiple values
Obligation	Necessary or optional
Prerequisite / line of	Key of an earlier step
Only for results	expected value of the condition
Selection/decision results	Allowed values and labels
Confirmation by module form	Text for the explicit confirmation of a completed module step
Note:	Specific instructions for the processor

A good internal key describes the technical content, not the position. approval result remains understandable even if the step is postponed later; step 4 not.

Selections and decisions

Options are entered line by line. A visible label can be separated from its stored value:

For simple lists, one value per line is also sufficient:

A decision requires at least two results. The stored value is depend value later steps are used.

Build branches

A dependent step always refers to a step already before it. The result determines whether the branch is applicable.

Configuration for the first branch:

second branch configuration:

As long as the decision has not yet been made, both branches remain visible in the drain indicator, but blocked. After that, only the selected branch contributes to the applicable sequence.

Automatic tests

For a test, Automatically check, otherwise manually are selected. Technically, it automation = observe stored.

The engine automates a step only if the workflow module can provide a value for it. Without suitable automation, the step remains visible and can be processed manually. A definition thus remains usable even if an external service is temporarily unreachable.

An automatic system may perform safe observations and validations, such as:

• check the completeness of mandatory data;
• Read existing channel allocations;
• evaluate an already stored export status;
• determine the outcome of an internal rule.

External publications, mailing, payments or other hard to undo actions remain visible and deliberately confirmed actions. An automatic pre-test shall not circumvent this confirmation.

Selecting Processing Types

Form

Form captures a value directly in the workflow. This is suitable for short texts, confirmations or values preset by binding.

Selection

Selected shows static options or records loaded via a binding. With mode = multiple Multiple values can be stored.

New plant

Created offers a simple new investment within the step. Extensive domain objects should instead be maintained in the responsible module.

Module form

Modules opens an existing domain interface, for example article maintenance, eBay mapping or CRM record. After saving, the user confirms the workflow step. The links are in module links filed.

Complement module binding

A binding connects the general workflow engine with a domain DD and optionally with context, pre-occupation and finish logic.

Reference in definition:

Typical binding tasks:

• records with dd select Load as options;
• DD field options with dd field options use;
• an existing cell value with dd field value Preliminary evidence;
• static options with static select define;
• update the intended record during the finish;
• optionally send a message after successful completion.

The complete binding scheme and a real contact example are in dbxWorkflow.

Validation in the Designer

The designer reviews changes immediately. During storage, the same structure is additionally controlled on the server side. Only a conclusive sequence is stored.

In particular:

• at least one active step;
• the name and internal key of each step;
• unique keys;
• at least two outcomes for decisions;
• existing dependencies;
• dependencies only on earlier steps;
• an understandable goal and final label.

The client-side display improves the operation. The server-side check remains binding, because requests can also arrive without browser JavaScript.

Round trip security

The designer updates the already loaded and normalized definition when saving. It no longer only builds a new JSON from the visible fields. As a result, in particular:

• additional top-level fields and schema metadata;
• Need properties not shown in the designer;
• Extensions in resolver, Source, bind and module links;
• Additional characteristics of the Finishblocks;
• Extensions of derived checks with the same Keyboard;
• Several allowed Actions including their existing order.

The well-known designer fields will continue to be deliberately overwritten. A remote step, an emptied optional property or a deleted bind ref should therefore also disappear from the stored definition. When renaming a need key, associated check extensions are carried; The browser also updates dependent steps to the new key.

The technical check fields remain derived from the needs. Own extension fields of a check are received while Labels, Question, Validation, Required, missing message and the processing path is generated again from the associated need.

Changes and ongoing instances

Stores at the start dbxWorkflow the normalized definition as a snapshot in the instance. A later change in the designer therefore applies to new starts and does not retroactively change an already started run. To test a correction, a new instance must be started.

Full example

Test before release

1. Start workflow without a pre-set record.
2. Check mandatory fields and optional steps.
3. Go through every decision with all the results.
4. Check if only the selected branch becomes applicable.
5. Test automatic tests with complete and incomplete data.
6. Open module windows, save them and return to the workflow.
7. Test pause, resume, cancel and restart.
8. Review and finish with a test record.
9. Ensure that external actions are not duplicated.
10. Control instance and step history in administration.

Further pages

• Using the workflow
• dbxWorkflow
• Developing modules
• dbxDB, dbxDD and FD
• dbxForm