I don't understand the message: 'Incoming flows do not join'

[ingorichtsmeier]

Describe the Bug

In my BPMN diagram I find a warning on a Task: "Incoming flows do not join".

I don't understand what happens here.

Steps to Reproduce

1. do this
2. do that
3. now this happens

Expected Behavior

Provide a message like "Insert an XOR gateway to join the incoming sequence flows".

Environment

Camunda Web Modeler in Firefox 114.0.2 (64-Bit)

[nikku]

A common misconception is that these flows have join semantics, but they don't. To not confuse users (that may not be fluent in BPMN) we rather want to model this explicitly.

Does https://github.com/bpmn-io/bpmnlint/blob/master/docs/rules/fake-join.md help you to make more sense of this error?

[ingorichtsmeier]

A common misconception is that these flows have join semantics, but they don't.

Sorry @nikku, I don't understand this either. The sequence flows in my example split in the XOR Gateway C and join before the Task B again. Two sequence flows entering a task are (from the BPMN spec) allowed to join a splitting gateway from somewhere else.

Does https://github.com/bpmn-io/bpmnlint/blob/master/docs/rules/fake-join.md help you to make more sense of this error?

Yes, it does. And I tried to propose a message to get closer to the desired action (which is to insert a gateway where the sequence flows should join).

Maybe there is even a better message?

[nikku]

@ingorichtsmeier The point of the message + rule name fake-join is to convey that this is not the join semantics you expect from an exclusive gateway. The recommendation featured in the documentation is to model the join explicitly. Not sure how we want to improve the message.

What we want to do is to refer users to the rules page so they can learn more about individual rules. This is one of our future work items. Closing this issue.

---

Update: What you propose is provide the user actionable feedback. The way our rules are currently phrased are not actionable but descriptive and I'm hesistant to change this for just a single rule. Example for label rule failing: Descriptive message is "Start event is missing a label" while actionable advice is "Add a label to this start event".

Why can you argue that descriptive is better? Because not always these changes are required or better; they are just recommendations.

[ingorichtsmeier]

What about "Incoming flows do not join in a joining gateway"?

I don't know out of my head if the BPMN spec differentiates between joining and not-joining elements and if there is anything else for joining than a gateway.

This message will keep the descriptive character and shows me what could be improved.

[nikku]

Taking your original example:

The message would be something like this:

B - Incoming flows do not join at task?

[ingorichtsmeier]

do not join at task

the message flows enter both a task, so somehow they DO join at task. And it works as expected (from the developer perspective): Once one of the flows is taken, the task is activated.

For this reason, would stick to my proposal from above: "Incoming flows do not join in a joining gateway".

A more action orientated message is: "Incoming flows should not join at task."

It could be that my English skills are not good enough to get the small differences here. What about a short talk on Zoom?

[nikku]

After follow-up discussions the simplest way would be to link the documentation for this issue.

[nikku]

Proposal by Eric:

Incoming flows should join at a gateway

[nikku]

Closing this (again). Let's follow up via https://github.com/bpmn-io/internal-docs/issues/856.

We'd want to see the (short) error messages + documentation as a unit.