How "low" a low-code project should be and why?

How much work can a low-coder do in your project? Is a low-code team self-sufficient? Or do they need to ask for help with coding? Where do we draw a line: should “this” be hard coded in a programming language, or defined in a low-code manner (e.g. in the BPMN process or eximee form template)?

Low-code as much as you can

The low-coded parts of your project are easier to maintain and change. Those parts are also easier to understand thanks to self-documenting notation. Unless a project has some particular requirements (e.g. efficiency) it is better to stay on the low-coded side.


Send an encrypted email to the customer - a reusable sub-process

Scenario: we’re implementing many business processes for a corporation. Most of those processes are required to send an encrypted email to the customer. To send an encrypted email a process needs to:

  1. define message attributes (e.g. user identifier, message subject, body template, attachments, etc.)
  2. call a Webservice which prepares email and puts it on a sending queue
  3. send a decryption password to the user via SMS
  4. wait for a message to be sent to the user (from sending queue)

A business process needs to wait until it gets the confirmation of sending a message.

First, let’s examine a “hard-coded” approach.

Our dev team created a straightforward BPMN process, that has one external task with no input parameters. The general concept is: as long as Java code does not have confirmation of sending a message it does not complete a task and therefore it’s blocking the execution of a business process.

To be more specific: upon execution, the Java handler checks whether a messageId variable is set in a process instance:

final String messageId = externalTask.getVariable(DELIVERY_MESSAGE_ID);
if (StringUtils.isBlank(messageId)) {
verifyEmailDelivery(externalTask, externalTaskService);

If messageId is empty - we’re sending a new message. It’s not empty - we’re requesting a confirmation:

if (verifyEmailDelivery.verify(details)) {"Email with messageId {} is properly send", details.getMessageId());
} else {
        verifyTimeout(externalTask, details);
        externalTaskService.extendLock(externalTask, verifyTimeout);

Only if we get a confirmation a message is sent we’re completing the external task, i.e. we’re letting the process go on.

The whole processing algorithm in this case is hidden from low-code developers in Java code. To change behavior or to monitor specific parts of it we need to dive into Java.

How this process would look like if we took a more low-code-oriented approach?

In this approach, the algorithm is visible in the BPMN diagram. It is easier to understand. We can also modify the algorithm with low-code tools (e.g. if we were to add some steps after raising an incident).

:bulb: You should consider using a subprocess to keep main process clutter-free.

Each of the external tasks, implemented in Java, is simpler and more focused on its task - it has narrower requirements.