#Test steps in the workbench
The workbench runs single steps of the diagram you are editing — service tasks call their system for real in a development or test environment, everything else is only evaluated — without deploying and without an instance.
#How a test builds up
flowchart LR S["Scenario<br/>'Credit check fails'"] --> A["Fetch customer<br/>▶ real call"] A -- "its result" --> G["Credit approved?<br/>▶ evaluated"] M["Set result<br/>(by hand)"] --> G G --> R["Review by finance<br/>▶ form shown, not sent"]
Each step is run on its own, in any order. The results of earlier steps in the same scenario fill the inputs of later ones.
#Open the workbench
- Open the process, click Edit, and switch the BPMN tab from Edit to Test.
- The diagram is frozen, and each element shows its test state: never run, successful, with findings, failed, outdated, or set by hand.
- Click an element's Play badge. The Element workbench opens in place of the properties panel.
The workbench runs the diagram as it is in the editor, unsaved changes included. No deployment is needed, no instance is created, and nothing appears in monitoring. Saving or discarding leaves test mode.
#What each step does
| Element | What Run does |
|---|---|
| Service task, message throw event | A real call to the system. You first confirm the target: an environment of kind Development or Test, and optionally other credentials |
| Send task | Dry run — recipients, subject and body are worked out. No email is sent |
| Exclusive and inclusive gateway | Evaluates the conditions and shows the path taken |
| User task | Shows the prefilled form, the assignee and the title; you can fill the form in and use it as the result. No task is created |
| Message start and catch, signal catch | Runs filter and transformations on a payload you enter. No webhook, no delta query |
| Start event | Shows the start data and the input schema |
| Sub-process, call activity | Works out the inputs; the inner part is not started |
| Timer | Shows when it would fire |
| Agent | Shows model, tools and credential. The model is not called |
| Parallel and event-based gateway | Not available |
A multi-instance step runs its items one after another, at most 10.
⚠️ Every Run of a service task is a new real call: a step that creates something creates it again.
⚠️ An environment that is not classified as Development or Test cannot be used — ask an administrator to classify it under Systems → Environments. The step's own environment is not preselected.
#Inputs and results
- Input data is filled from the results of earlier steps; change a value per field or in the JSON view. ⚠️ Changes apply to that one run and are not kept.
- Set result gives a step a result by hand; Take from run copies one from a real process run; Reset clears it.
- The result shows the status, the duration, the call made, the element's result and, on failure, what you can do and technical details.
⚠️ Only real calls, results set by hand, filled-in forms and imported results reach later steps. The results of evaluated steps — a message payload, a gateway decision — do not; use Set result.
#Scenarios
A scenario keeps the results and confirmed targets of one test case. New scenario, Rename, Copy, Delete and Reset all results are in the bar above the diagram, with how many elements have been tested. Scenarios are shared with everyone who works on the process.
Let the agent check opens an assistant that runs and inspects steps for you — at most eight real calls per request.
#What the workbench cannot do
- ❌ Run the whole process end to end. Deploy it as development for that.
- ❌ Send a real email.
- ⚠️ Some labels are German, such as the element type in the panel header (SYSTEMAUFRUF) and some messages kept from earlier runs.