Gaps in Flowable Modeler

Flowable Engine
1

Hi,

I work at a company that has been using Flowable for about 3 years.
We’ve recently started using CMMN and we’ve found some gaps in Flowable Modeler that I’d like to address here. I know that Flowable Modeler hasn’t been getting much attention lately but I’d like to know your position about some of the issues. Mainly I need to know if you’re planning on adding this features or if you’re willing to accept contributions regarding this matter.

All issues referred here refer to version 6.6.0.

1. Supported activity types

When modeling in BPMN, there is no such activity as “Case Task”, the activity that lets you instantiate a case instance through a BPMN process. We know that open-source Flowable Engine is prepared for this activity type but Flowable Modeler is not. This means that if we want this feature we need to stop using Flowable Modeler and that reduces the productivity, specifically because our models are quite big at the moment.
There is also no way to add a signal event listener for CMMN models.

2. Lifecycle listeners

Once again, the Flowable Engine is prepared for working with case lifecycle listeners but there is no way to configure them using Flowable Modeler.

3. Definition of groups for cases

We’re currently using the concept of “potential start groups” in both processes and cases for defining who can see the process or case in your frontend application. Even though the Flowable Engine supports this concept when parsing the model, Flowable Modeler doesn’t currently support adding potential start groups in a case. It only supports this concept for processes.

4. Sentry placement bug
This is an old bug. It’s been there since version 6.4.2. When modelling in CMMN, if you pick the sentry activity (either the Entry Criterion or Exit Criterion) and drag it to a plan item, it doesn’t stay attached to that plan item the first time. After you drop the sentry the first time, you are obliged to pick it up again and drop it a second time. If you forget to drop-and-drop a second time, it’s like that sentry never existed in the first place.

5. Boolean properties
I think this bug has appeared in version 6.6.0, but I’m not sure about this one. Basically, all activity properties that represent a boolean value and are usually represented with checkboxes are not working at the moment. For some reason, Flowable Modeler is not showing the checkbox which prevents you from changing the default value of that property.

2

Dear David,

thanks for your blog post and being so engaged to write down all the inputs.
May I ask if you mean with Modeler Flowable Design and are you using Flowable Work in your organization?
Also for the Lifecycle listener did you check this:Third-Party Messenger Developer Guide | Flowable Enterprise Documentation ?

For the rest we are happy having you on board and always happy to get inputs and notifications like this.

3

Hello,

I belong to the same team @DavidPLamas did, and the gaps found are from Flowable Modeler and not from the Flowable Designer.

We use flowable Modeler and our Customers also use flowable modeler.
We (still) are too small and we cannot afford flowable designer licensing.

These gaps are critical to our solution, do you intend to address this gaps in a future release of flowable modeler?

4

(Do note that some points above have been fixed in 6.7.0)

As any open-source project or software company for that matter, we have a group of people that works on Flowable and it’s not unlimited ;-). As such, we need to make choices where we invest our time and effort. As you can see on the github repo, we’re very active on the engine side, but indeed less so on the Modeler side of things. One of the reasons is that (with the exception of I believe @DavidPLamas in the past), there’s not many contributions happening in this area. We’re currently evaluating what we want to do in the future here (as you know, it’ based on AngularJS …) and what that would be. Once that’s decided, we’ll of course communicate this to the community.

1 Like
5

Thank you for the insight @joram and @Max. Our team will evaluate the possibility of addressing some of the bugs and gaps identified by @DavidPLamas.