This tutorial explains the daily operation of a dbxWorkflow sequence: Start, input, automatic exams, domain modules, decisions, pause and controlled completion.
1. Starting workflow
Active workflows are opened from the workflow list, from a domain module or via a prepared start link. Check title and goal before starting. If an instance already exists, use its continuation action if possible instead of unintentionally creating a second pass.
- New start: Creates a new instance.
- Continuation: opens an existing instance with its stored values.
- Pre-selection: a domain record may already be selected via the starting context.
2. Understanding the interface
A running instance shows:
- Workflow name and technical objective
- Status and overall progress
- Step navigation with completed, current and blocked tasks
- Note on the current task
- Enter, select or link to the domain module
- Results of automatic checks
- Review and completion once all applicable steps are completed
For long processes, step navigation can be scrolled horizontally. A blocked step awaits a prerequisite; It is not a technical error.
3. Read step states correctly
| Display | Meaning |
|---|---|
| Current | This task can now be dealt with. |
| Completed | A valid value or confirmation has been stored. |
| Locked | An earlier requirement is missing or the branch has not yet been decided. |
| Optional | The step can be deliberately skipped. |
| Automatic | The system tries to perform a safe test itself. |
4. Capture and Apply Values
- Read note and expected interim result.
- For single selection, select or enter exactly one value.
- For multiple selection, mark all required values.
- Takeover Select.
- Read feedback and check if the next step becomes active.
An already completed, still applicable step can be opened again. Change a value there, then check the rest of the process again, because decisions or tests can change.
5. Optional step skip
Optional tasks can be completed via the intended skip action. The skip is explicitly stored and remains traceable. Skip one step only if the domain objective can be achieved without this evidence.
6. Evaluation of automatic testing
An automatic ObservedExam runs as soon as it is the next applicable step. It reads a secure technical value and stores the result and message.
Save the previous step→ Next step is determined
→ Domain module delivers test value
→ Result and message are stored
Next manual step opens
If no unique value can be determined, the task remains manually editable. Read the message in full. It often specifically mentions missing information such as category, policies, access data or mapping.
7. Open the domain module and return
A module step can include links such as Articles editing, eBay mapping or Open contact request offer.
- Open a suitable domain form via the offered link.
- Process data in the domain module and store it there.
- Return to the workflow window.
- Activate requested confirmation.
- Step with Takeover finalised.
8. Decisions and branches
A decision stores a unique result value. Only the appropriate branch is then required for the conclusion.
Approval = approved→ “Execute order” becomes applicable
→ “Processing queries” does not belong to the active branch
If the decision is changed later, the workflow recalculates the active branch. After that, check all subsequent steps and messages.
9. Explicitly confirm external actions
Publication, mailing, payment or other difficult to reverse actions remain visible. Check before confirmation:
- Right record and right target system
- complete mandatory data and current preliminary check
- Test/sandbox or production mode
- Possible costs, publication or notification
- whether the action with the provider was already successful
10. Understanding progress correctly
The percentage value is based on the currently relevant steps. Before a decision is taken, both branches may still be included in the total; then unselected branches are removed. 100 percent means only after successful finish a completed workflow.
11. Pause, continue, cancel and restart
| Commander | Effects | When to use? |
|---|---|---|
| Pause | Stop processing, get values | Lack of consultation or external input |
| Continuation | Continue processing paused instance | Condition is fulfilled again |
| Abortions | Instance controlled | Goal should no longer be pursued |
| Restart | Starting a new run according to planned rules | Definition or starting point has changed significantly |
12. Review and conclusion
Once all applicable steps are completed, the final review opens.
- Read all the summarized results.
- Compare the target and selected record.
- Check automatic messages and external IDs.
- Confirmation of the conclusion.
- Success reporting and status Finished control.
The completion logic can update a technical record, send a message or recheck a provider status. If the listing ID is missing, the record is invalid or the export status is negative, the completion must be clearly refused.
13. Ongoing instances and history
In the instance report, administrators find start time, workflow key, destination, status, current task, progress, and last message. The step history documents position, step key, action, value, message, processor and time.
Troubleshooting
| Problem | Test |
|---|---|
| Next step is blocked | Previous mandatory step, check stored decision value and dependency. |
| Automatic does not work | Is it the next applicable step? Can the domain module deliver value? |
| Progress is unexpected | Consider later blocked steps and still open decision branches. |
| Finish is denied | Completely check review message, domain record, provider status and external ID. |
| Change missing in the designer | Start a new instance; Current instances use their definition snapshot. |
Service checklist
- Proper workflow and correct technical record started
- No unintentional second instance
- Current task and goal understood
- Mandatory values stored, optional steps explicitly processed
- Automatic messages read and domain modules really saved
- External action only confirmed after target and mode check
- Review complete and technically plausible
- Completion Reports Domain Success, Not Just UI Progress
Creating a workflowAll tutorials
Text walkthrough
The slideshow remains the visual tutorial. These steps provide a complete text fallback.
- Starting workflow
Active workflows are opened from the workflow list, from a domain module or via a prepared start link. Check title and goal before starting. If an instance already exists, use its continuation action if possible instead of unintentionally creating a second pass. - Understanding the interface
A running instance shows: - Read step states correctly
- Capture and Apply Values
An already completed, still applicable step can be opened again. Change a value there, then check the rest of the process again, because decisions or tests can change. - Optional step skip
Optional tasks can be completed via the intended skip action. The skip is explicitly stored and remains traceable. Skip one step only if the domain objective can be achieved without this evidence. - Evaluation of automatic testing
An automatic ObservedExam runs as soon as it is the next applicable step. It reads a secure technical value and stores the result and message. - Open the domain module and return
A module step can include links such as Articles editing, eBay mapping or Open contact request offer. - Decisions and branches
A decision stores a unique result value. Only the appropriate branch is then required for the conclusion. - Explicitly confirm external actions
Publication, mailing, payment or other difficult to reverse actions remain visible. Check before confirmation: - Understanding progress correctly
The percentage value is based on the currently relevant steps. Before a decision is taken, both branches may still be included in the total; then unselected branches are removed. 100 percent means only after successful finish a completed workflow. - Pause, continue, cancel and restart
- Review and conclusion
Once all applicable steps are completed, the final review opens.
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.