The fastest way to understand workflows is to build one. In this tutorial, you’ll create a simple dunning run: after a case is created, it checks the open amount and – only if something is outstanding – automatically sends a dunning letter. Otherwise, the case is closed immediately.

What we’re building

Read claim balance × open > 0 else Create dunning letter Send via beA Closure

Goal: After reading the balance, an exclusive gateway decides. Only the upper path (open > 0) creates and sends the dunning letter; otherwise, the workflow ends directly.

Step by step

  1. Create the process and make it startable

    In the workflow editor, create a new process and set the Startable property under Custom Properties. Only then can it later be started within a case. Drag a StartEvent onto the canvas.

  2. Define the trigger

    Determine when the workflow runs. For automatic operation, set up a start rule on the "New case" event. To try it out, a manual start in the case's Workflow tab is enough.

  3. Insert the first step: read the balance

    Using Create element, insert a ServiceTask that provides the claim balance. This makes the FORDERUNG_OFFEN variable available, among others (see variable reference). Connect the StartEvent to this task with a sequence flow.

  4. Model the decision

    Place an exclusive gateway after the task. On the upper sequence flow, write the FEEL condition = bigDecimal(FORDERUNG_OFFEN) > 0. The lower flow becomes the default path ("else") – this way, the workflow never runs into an incident when nothing is outstanding.

  5. Generate and send the dunning letter

    On the "open > 0" path, attach two ServiceTasks: one creates the dunning letter (from a text block with placeholders such as FORDERUNG_OFFEN), the second sends it. Format amounts using euro(...).

  6. Merge the endings

    Merge both paths into one EndEvent. The "else" path ends directly (closure), the dunning path after sending.

  7. Save and test

    Save the process. Start it on a case and follow the progress by color: green = completed, blue = current position, red = error. FEEL conditions can be tested directly on the case.

  8. Monitor

    Check the incidents daily. For large case volumes, later start the same process in a throttled way via batch processing.

Where to go from here

  • Extract recurring parts (e.g. the dunning block) as a subworkflow and reuse them.
  • Instead of fixed values, consistently calculate with placeholders & FEEL – for example deadlines with parseDate(...) or fees with calcRVGwithDate(...).
  • Wait for responses: use an event-based gateway to react to a response in the case or a timer.