Using the workflow

This page explains the operation of a dbxapp workflow from start to controlled completion. It is aimed at users, administrators and testers. Creating a definition describes Creating a workflow.

Starting workflow

An active workflow is started via its stable workflow key:

The start creates a new workflow instance. A retrieval of the start route therefore generates another instance and does not automatically open the previous one. At the same time, the current definition status is stored so that subsequent admin changes do not change this pass.

Unknown and deactivated workflow keys are rejected with a warning; dbxWorkflow does not start a replacement or demo process.

If an existing technical record is to be preselected, the binding can receive the rid:

Direct call of an existing entity:

Users only see instances for which they are authorized by owner or admin rules.

Understanding the interface

A running instance shows:

• the name and technical objective;
• status and overall progress;
• all steps in their order;
• completed, current and blocked steps;
• the current task with indication and input capability;
• reporting of automatic tests and domain modules;
• the statutory audit once all applicable steps have been completed.

Step navigation can be scrolled horizontally for long workflows. A blocked step indicates in its tooltip the still missing prerequisite.

Conditions of a step

Display	Meaning
Current	This step can now be processed
Completed	a value or valid confirmation has been stored
Locked	a condition is not yet fulfilled
Optional	The step can be skipped if necessary
Automatic	the system tries to perform a safe test itself

Completed, still applicable steps can be reopened. A change can affect subsequent decisions. Therefore, after a correction, the rest of the process should be checked again.

Enter values

Individual value

In mode = single Exactly one value is selected or entered. With Takeover The engine stores the value and moves to the next applicable step.

Multiple selections

In mode = multiple Several options can be chosen. All selected values are stored together in the instance.

Optional step skip

An optional step can be skipped. The engine explicitly saves this as a completed step so that the process remains traceable.

Open the domain module

A module step shows links such as Articles editing, eBay mapping or Open contact request. The domain form is opened in the dbxapp window. After that date:

1. Process data in the domain module and store it there.
2. Close windows or return to workflow.
3. Activate the confirmation requested in the workflow.
4. Step with Takeover finalised.

The confirmation shall not replace the validation of the domain module. During the finish, the crucial data is checked again.

Decisions and branches

A decision stores a unique result value. Only steps with suitable depend value subsequently become applicable.

When the result is changed later, the engine recalculates the active branch. Unselected branches are not required for financial statements.

Automatic tests

One step with automation = observe is executed as soon as it is the next applicable step. The user does not have to press an additional button for this.

The sequence is:

If the automatic cannot determine a safe value, the step remains manually editable. An unreachable API must not cancel the entire workflow without an understandable message.

Automatic messages are technically relevant. Example:

The user corrects the mentioned data in the relevant domain module and can then retrieve the check.

Example: Post articles on eBay

Start:

The current process consists of:

1. Selecting Articles Determine existing shop items.
2. Check eBay Readiness Automatically – Control channel, assignment, access data, category, policies, SKU and title.
3. Process and confirm eBay data Open article maintenance and eBay mapping and add missing information.
4. Exporting – Explicitly confirm the external publication.
5. Check status messages – automatically evaluate existing connector status; check manually if there is no clear feedback.
6. View eBay offer – Control optional result link.
7. Closure – only complete if the export status is successful and the listing ID is available.

Export is intentionally not invisibly automated. Pre-checking and status evaluation are automatic, the external publication remains a visible user action. As a result, page views or repetitions do not accidentally lead to a renewed offer.

Progress

The percentage also includes later, still blocked steps. Once a decision is made, unselected branches are removed from the applicable total scope.

Example with six steps:

A workflow receives status only after successful finish Finished and 100 percent. Visible progress is therefore not a technical message of success.

Pause, continue, cancel and restart

Process commands are sent to the same instance:

Commander	Effects
Pause	Stop processing, get values
Continuation	Reopen paused instance
Abortions	Instance controlled
Restart	start new processing according to the intended rules

For external actions, it must be checked before a restart whether the action was already successful with the provider. The local authority is not always the only truth.

Review and conclusion

Once all applicable steps have been completed, Closure Open. The review shows the recorded results and the planned goal.

Upon confirmation, the engine executes the completion logic. Depending on the definition, completion can:

• Complete only the instance;
• update a technical record via a binding;
• send a message after successful operation;
• re-check a shop or provider status;
• refuse to close with an understandable error message.

A failed export, a missing listing ID or an invalid domain record must not be stored as successfully completed.

Managing ongoing instances

Administrators can find all instances here:

The report shows startup time, workflow key, goal, status, current task, progress, last message, and an action to resume or view.

The Step History in dbxWorkflow|workflowStep Documented:

• instance and position;
• internal step key;
• manual action, skipping or automatic;
• stored value;
• notification and processor;
• Date of completion.

This history facilitates support and troubleshooting, but does not replace a domain audit log if legal retention rules apply.

Typical problems

Next step is blocked

• Check whether the previous mandatory step has really been taken.
• value stored for branches; and depend value Compare.
• Check whether the dependency in the designer is before the target step.

Automatic does not work

• The step must be the next applicable step.
• Automation Must Observed be.
• The domain module must provide a value for this workflow key and need.
• Read provider or record message in the workflow.

Progress is unexpected

• Blocked later steps belong to the entire scope until the decision.
• Unselected branches are removed only after the decision.
• Optional steps are saved as completed when skipped.

Finish is denied

• Read the review report completely.
• Check the technical record and external feedback.
• On eBay, in particular, check export status and listing ID.
• Fix errors in the domain module and try to finish again.

Control and test checklist

• Proper workflow key was started.
• No unintentional second instance is generated via the start route.
• Current task and goal are understandable.
• Mandatory values were stored, optional steps were deliberately processed or skipped.
• Automatic messages were read and technically checked.
• Module forms were actually stored.
• Before external action, data and target system were controlled.
• Review contains the expected values.
• Finish reports domain success and not only 100 percent UI progress.
• For problems, instance report and step history were checked.

Further pages

• Creating a workflow
• dbxWorkflow
• Shop guide
• Developing modules