Faster and Furiouser

Evel OrangeThe Flowable team have been busy inspecting how the Flowable engines operate at high loads in real-world configurations, the results being discussed in my last post, concluding that the upcoming release is faster allround. As hinted there, this was still just a baseline comparison with previous versions and there was another recent feature that was going to be added to the benchmarking. The results of that are now available here.

This benchmarking compares the upcoming version with a recent feature (“async history”) disabled, as it was in the previous benchmarks, and then with it enabled, which has not been benchmarked before now.  Sadly, this doesn’t tell us directly how the very best performance compares with older releases.  We can do some simple sums to give us a combined percentage improvement, which is shown in the table below:


% Faster than v5.23

% Faster than v6.0/6.1/6.2
















What’s most rewarding about these results is that they allow you to evaluate more complex process structures and configurations that reflect more realistic uses of the Flowable engines. The tests are all available as open source, and we have run them against a couple of other BPM engines, giving us even more confidence of our leadership in performance and scale.

Of course, speed isn’t everything, which is why the next release will have some additional capabilities to help cover wider business use cases. Those are topics I’ll cover in future posts!

Keeping ahead of the zombies

Zombie_1Competition is great, it gives you a marker against which to compare yourself as well as a drive to innovate to keep at the front. The difficulty with competition in the software industry is that everyone starts at different times; it’s very rare to have all the competition starting at the same time (or may be not so rare recently with the cryptocurrency and AI hypes). This means it can be difficult to compare vendors at different stages in their maturity. We’re all used to the beauty parade of feature lists, which tells you what you’ll get now, but may be no indicator of what you might get next year or the year after. It’s very easy to get swayed by all the stuff happening around the outside without noticing the core has gone cold: dead on the inside. It might be a very well-dressed and mobile zombie, but it will start shuffling and groaning before too long.

That’s why the good old performance benchmark can be a great way to show that the heart is beating stronger and stronger. Of course, benchmarks can be gamed, but if you make the benchmarks public and open source with a range of complex scenarios, it makes everything clearer and available for meaningful discussion. Now, some of you will say “making stuff faster doesn’t make it better in the grand scheme of business needs,” and in some cases you may be right. However, in my experience, when I’ve seen a team thinking about how to re-architect, adapt and adjust to get more out of the engine, then they gain new insights that ripple out through the product. I’ve seen it can also help you focus on what’s really important for the product in the real world, not what sounds good in a marketing tweet.

Why am I talking about this now? Obviously, we’ve done some serious conceptual and technical work to boost the performance of the Flowable engines that leaves the opposition shuffling in our wake.

The deep details for the technical types, as well as the easy graphs for types like me, are in this Flowable blog post. There’s more to come after it too, so this isn’t the end of the performance story before the next software release. We think it’s important to push the boundaries of performance for BPM, all the time retaining transactionality and dynamicism. Of course, we also watch what’s happening with technology: Spring Boot 2? Of course we do.


Is your Business Process provider putting all their efforts into trying to dress up to look contemporary? Are they dead on the inside? Are they a zombie?


Machine Learned Decisions in Business Process Management


With all the fluff and buzz made about AI, it’s very easy to either hype or dismiss the benefits of the technology for use in enterprise and government applications.  Business Process Management is a well-established technology that is used to model the flow of work between systems and people: collecting data along the way, branching down different paths, running business rules, and very often relying on human decisions.  With so much context available to a process, you would hope machine learning could offer something of real value.

This is precisely what some of our customers have been looking for.  Remove the mundane human decision-making activities, leaving people to work on more valuable tasks.  Take this scenario: you have a process where someone has to review some citizen or client information and make a decision about what should happen next.  Now imagine a machine is watching this; patiently analysing possible correlations between what is known and what is decided.  Eventually, the machine reaches a level of confidence that you allow it to advise the users (I don’t necessarily mean like 2001, HAL: “I’m afraid I can’t let you do that Dave”).  Take things a step further and it may reach a level of confidence that you just let the machine make the decision alone.

All sounds wonderful, but what might happen if the machine makes the wrong decision in one instance? When processes are audited, how can you explain what happened and why?  Well, it’s hard if the machine learning is a black box that you can’t look into or understand.  What’s really needed is that the machine learned decisions are represented and executed in a well-understood way, both by systems and humans.  Sounds fantastic.

That’s what you can do with Flowable.

Look at the simple loan request process below.  There’s some initial data gathering and then a user task, “Loan Review”, to check the information and decide whether to accept, reject, or pass for further review.



You can use Flowable to automatically locate human decisions in a process and record all the data reviewed by users, along with the decision made.  This historical data is fed to a machine learning algorithm that analyses it and ultimately generates a decision tree.  We can now use this to predict what decision should be taken.  You can show or use that in many different ways with user.



To take it to the next level, we can convert the decision tree into rules in a decision table (DMN standard, or course).  This is something that can be readily understood by business users, as well as executed by systems.  At this stage, you might just get the derived rules validated and signed off as part of a process improvement lifecycle, and a new process defined using the table instead of a human task.  Alternatively, you could use one of Flowable’s unique capabilities to dynamically modify a running process and switch the user task out automatically.  You could define confidence levels in predictions to trigger a transform of the menial decision-making from human to machine.

You can see such a system being run live with full technical detail in front of an audience at Devoxx 2017

Engines of Disruption

FlowPistols_4No, not another punk or metal band, but another open source engine that joins the BPMN (Business Process Model Notation) and DMN (Decision Model Notation) engines already in the Flowable Project. There was a gap between B and D acronyms, so we’ve filled it with a C. The CMMN (Case Management Model and Notation) standard is now at version 1.1 and we’ve seen it being used increasingly at customers for business critical solutions for a while.  This prodded us to develop a completely new CMMN engine written from the ground up with the same principles as the BPMN engine that has served many so well.  Those principles are to be lightweight, fast and efficient processing at scale.

Before the techno-babble: why is any of this interesting to business people trying to solve the digital transformation project that their CEO/CTO/CIO/CDO has dumped on them? Well, CMMN offers a different way of looking at things – a more declarative, or data-driven view. Many business problems are case-like: an insurance claim, recruiting an employee, on-boarding a client, dealing with a citizen request. There’s an event, person or thing that a range of different activities and data are focused around. Those activities can be approval, data collection, validation and communication, either through processes, tasks or integrations with external systems. There may be any number or complexity of conditions for starting an activity, or dependencies on previous life-cycle stages of a case. CMMN gives you the option to express your problem naturally. You can achieve the same with BPMN, but there’s extra work or overheads that make it less effective (also, the BPMN diagram would be an impenetrable mess compared to the CMMN one). A light, scalable and fast native CMMN engine gives you the option to express your problem more naturally, at the same time giving you excellent execution performance.

Because CMMN takes a different perspective to the world than BPMN, instead of trying to mangle its execution on a BPMN or rules engine, we knew doing it properly meant a specialized engine. Working with a large number of sentries (potential triggers for processes, tasks and other activities) in a case model needs an implementation that efficiently scales and performs.

Of course, there’s a huge amount of interplay between processes, cases and decisions (BPMN, CMMN and DMN), each potentially driving or being driven by another. For this reason, the Task, Variable, Job and Identity Link Services in the BPMN engine were refactored to be separate services that could be used by any of the engines independently or shared when operating together. Now that these are true services, it also means that other custom engines and applications can use them as well. More importantly for us, it doesn’t matter if it’s a BPMN User Task or a CMMN Task, it goes into the same Tasklist for the user or team. The services even manage their own schema independently. If you’re into microservices, we’re giving you even more fine-grain service actions that you won’t find in other implementations!

With the open source Flowable engines, you have what you need to power your digital transformation or customer engagement solutions: the engines to power your ability to disrupt your market and do things differently.  Download the new Flowable 6.2 bundle and take a look at the release notes to learn more about using BPMN, CMMN and DMN.

We’re putting the band back together


Mrs. HH: Don’t you “Don’t get riled, sugar” me! You ain’t goin’ back on the road no more, and you ain’t playin’ them ol’ two-bit sleazy dives. You’re livin’ with me now, and you not gonna go slidin’ around witcho ol’ hoodlum friends.

PHH: But babes, this is Joram and Tijs, the Flows Brothers.

Mrs. HH: The Flows Brothers? Shoot! They still owe you money, fool.

Joram: Ma’am, would it make you feel any better if you knew that what we’re asking PHH here to do is a BPM thing?

Finally, the band is back together.  It’s been a while, but at last Joram is out of the cooler.  We’ve been making good progress while he’s been in stasis, and now things will really start to accelerate as Tijs gets back his technical sparring partner.  We’re not expecting it to take long for Joram to get up to speed, so look out for new things in the coming weeks.

I’ve been managing engineering teams for a while now, and have had conversations with other managers about the different types of engineer: the loud personalities; the quiet ones working silently in dark corners; the principled; the hacker; and occasionally the well-rounded human.  Which ones are the best?  Which types produce the most innovative or the most stable product?

Well, as always with people, there isn’t a simple answer.  I’ve seen the quietest individual come up with an exceptional insight and the most annoyingly loud ego produce something where you have to say, yes, this time you were as smart as you thought you were.  Ultimately, it isn’t about the individual, because they don’t scale.  A soloist can be really impressive – total mastery of their instrument – but your breath is only taken away when the full band tightly kicks in. It’s about how people work together that makes the difference, and finding complementary skills and personalities is hard.  Fortunately, people will often find each other, deliberately or accidentally.  This is the case with Joram & Tijs.  Individually, they are among the best engineers I’ve ever worked with, however, together they’re an awesome combination that inspires others.  A good band needs a front man or two, to drive them to new places in an ever changing music landscape.  The band’s back together and we’re going to make people listen.

We were awarded Rising Star at bpmNEXT 2017 last month.  I was privileged to present some of the groundbreaking technology created by this team, which you can watch here. All bpmNEXT talks follow the format of 20 slides automatically moving forward every 15 seconds followed by 15 minutes of live demo. Let’s just say it’s a “stimulating” format the first time you do it!

The Flow Pistols: Anarchy in the BPM

FlowPistols_3Last week I showed some of the new dynamic process capabilities of Flowable V6 at the bpmNEXT conference and I thought it might be nice to give a taste of that demo here.  The demo scenario was that we’re organizing a tour for the Flow Pistols and like any well designed processes, it can’t always cope with what the real world throws at it.  I showed Flowabe 6 running within the edoras one Case Management platform, with a case representing the overall tour and a process to run for each gig that needed arranging in the tour.

The process is quite simple: gather some details about the gig, and if the expected audience is above a certain size, then organize stadium-scale sound and light equipment; otherwise, just arrange transport for the band’s own gear.  The process diagram is:

arrange-gigInstead of just allowing random dynamic actions anywhere in the process, we can tag user tasks as being able to allow the user to insert dynamic tasks or processes at that point.  I’m going to tag two of the tasks as allowing either dynamic tasks or processes.


Once the process is deployed, I create a case for the tour and kick it off with a gig in Paris.  The case view allows me to start any appropriate processes associated with the case.


If I click the Start process action on the right-hand side, I can pick from the available processes for the case and get its start form – in the Arrange a gig process, this is just a dropdown to select the region for the event.

start formOnce the process is started, the first task appears, requesting the gig details.


We can complete the details needed here, including the expected size of the audience.  We’re expecting a relatively small crowd in Paris, only about 4000.


Because it’s going to be a small gig, we’ll be taking the band’s own equipment and the process takes us to the task to arrange transport for the kit, getting details of the vehicle carrying it.  Notice the additional actions to add dynamic tasks or sub processes.


Inject a parallel task in a live instance

Now, imagine I had got to this point in the process, when I heard from the company that usually transports the gear, saying that because of Brexit, the French government was insisting on UK commercial transport taking out an additional insurance.  Luckily, we already have forms we use for non-EU countries, so we can just reuse one of those.  Of course, I could just create an ad hoc task that’s linked to the case (or as a child of a user task), but in this case, I really do need it as an independent task that can be done in parallel to booking the transport.  Also, I do need both tasks to be completed before the process continues.  What I really want is to magically change this instance to a process more like the following:


This is exactly what I can get with dynamic tasks.  If I click the Add dynamic task, I get a form to define the task.  I can give the task a name and select its form.  It could have been configured to more specific, predefined tasks, but I’m keeping it simple.


Now, I have two tasks in my list:


I can now complete the insurance task and booking transport task to allow the process to continue, eventually to completion.

Inject a complete process into a live instance

Well, that was fun, but not exhilarating.  Let’s arrange a gig in the US.  I’ll start the Arrange a gig process again and this time take a different path.  If I arrange a gig for New York and say I’m expecting a crowd of 15,000, then we go down the path needing stadium equipment to be booked.


Just at this point, I see that there has been a presidential tweet early this morning saying that some planned energy tax legislation is being brought forward, effective from today!  Luckily, I had been planning for the tax, so already had someone define the process that modeled it.  What do I do?  Try and create a new process model that includes this, deploy it and them migrate active instances to it? If I had enough time to learn the intricacies of BPMN models and migrations (plus some developers ready to handle the cases where it just doesn’t seem to want to play nice), then I might.  Alternatively, I can just click the Add a sub process action.


I can give a name to use and then select the USA Energy Levy process.  This time, the entire process will be inserted in parallel to the current task and started, so, as you’d expect, an additional user task has been opened.


Before we continue, let’s take a peek inside the engine to see what’s going on.  By starting the Flowable Admin app, I can inspect all kinds of interesting things about the engine, but I’m just going to look at that active process instance.


If I click the Show process diagram action, I can see the familiar Arrange a gig process, but with one difference – the Book light and sound systems task isn’t a user task.


If I click on it, I zoom down a level and can see a parallel gateway with the open task and a sub process.


If I then click on the subprocess, I can see the energy levy process and its open task.


Back in the case view, I can complete the tasks for the energy tax, giving details about the consumption of the equipment.


Sadly, because we’re using low energy gear, we end up on the path that gets hit by the tax.


And it looks like we have to pay an additional tax, because being concerned about global-warning means we’re probably communists.


Of course, demos like that can look amazing, but you never know how hard it was to do behind the scenes, and what corners were cut.  So, here’s the code that was used to insert a subprocess into a running instance:

DynamicEmbeddedSubProcessBuilder subProcessBuilder = new DynamicEmbeddedSubProcessBuilder()



dynamicBpmnService.injectParallelEmbeddedSubProcess(task.getId(), subProcessBuilder);

Inject a process into an injected process in a live instance

Yes, I did just say that.  If you can inject a process into a running process instance, why not inject a process into that injected process as well? Sounds twisted, but think again about dealing with the real world – you never know what you might have to deal with at any time.  Also, think about it in the context of having many process snippets that can be used as needed by the user or by a smart subsystem.  Then think about a chatbot that follows a process snippet when the user asks something, and while following that path, the user suddenly has something else come to mind that makes their conversation take a diversion. The user journey could be created using process injection.  Here’s an injected process to update the Accounts Payable system in the injected process that used the new tax for the first time – see the path in the top of the view.3levelinsert

Where does it go from here?

As we got a hint of when looking under the covers, we can visualize, audit and even reuse these one-off instance variations.  Existing analytics can continue to be used, and there’s an exciting potential to use Machine Learning to recognize the cases when exceptions should be considered for a case in hand.

This was just intended to illustrate something we can do now with Flowable 6.  As we move forward, we will continue to add features that exploit the dynamic manipulation of process state in user-friendly ways.  When looking at other BPM engines, see if they currently can do this.  A big thank you to the guys who put in the hours to make the magic happen for the demo – I was the dancing monkey.


This Cat’s Out of the Bag

And so the next stage of my professional life begins.  When I left Alfresco, most people expected me to start a new company around the Flowable project; most people, including myself and the core team.  Certainly, it was possible, and I had a great response from the VCs I spoke with, to the point where we had decided one to go with.  Then “stuff” happened.

It saddened me that many people thought this “stuff” was not surprising.  Certainly, some of it might have been expected, but I was taken aback.  I’m not going to go into this now.  My approach is always to win by being better.

edoraswareMeantime, another opportunity surfaced: edorasware.  Right from the beginnings of ACTIVITI, we’d had a great relationship with people from edorasware working on the project; they even contributed a complete subproject for process simulation.  They built a Case Management platform based on ACTIVITI and have been selling it very successfully, so were keen to understand what the implications of Flowable were for them: we started talking.  Our ideas about where to take process technology forward meshed and we all got a bit giddy (if you don’t get giddy about your work occasionally, I feel sorry for you).  With our departure from Alfresco, they were now interested in working with us on Flowable, to the point of merging.

This gave us a conundrum: following the VC model with “full control”, and building up a company and infrastructure from scratch, as well as developing enterprise product; or, a bit less control, but straight to market with a BPM and mature Case Management offering.  Their customers also intersected nicely with where we’d seen a lot of interest in process applications.  Also, importantly, the BPM world is a busy place and there are definite pivots happening, so we decided that time-to-market was critical: we didn’t have a couple of years to build ground up from a new open source project.  You can get support and maintenance from an experienced team on the open source version of Flowable today.

Over this year we’ll transform the company from its core outwards (including the brand), organically building on what are already mature products and organizations.  We may still take investment from VCs, but it’ll be from a far more advanced position.  Most of all, it’s going to be great working with people who have real vision and passion.  Expect great things from us.

Instant Gratification with Flowable 6

[An updated version of article for Flowable 6.6+ can be found here]

blogger2“Ok, so there’s a download of Flowable 6 available, meaning I don’t need to checkout and build from source, but you know what, I’ve still only got a few minutes to see if it’s worth investing more time.”

I know your time is valuable, so here’s a really quick run through you can follow with the download, and hopefully it’ll persuade you it is worth investing more into the very cool technology underneath. I’m going to make it techie light, so any interested user can also get a feeling for it too.

Already downloaded the latest Version 6 zip file? Ok, when it’s unzipped, the only thing we’re interested with today is the ‘wars’ folder. If you already know what to do with these, then don’t let me stop you, and jump to the next paragraph. If not, I’d recommend using the latest stable Tomcat for your operating system ( and all you need to download is the zip version of the Core. Unzip that Tomcat somewhere on your machine and browse the unzipped folder. You should find a ‘webapps’ folder – and this is where you need to copy all the “WAR” files files from the Flowable ‘wars’ folder. Once all the .war files are in webapps, navigate to the ‘bin’ folder in Tomcat and start ‘startup.bat’ if you’re on Windows, or ‘’ on Mac or Linux. If doesn’t start, you may need to make it executable. Google is your friend.

Getting started

Hopefully, you have all those lovely Flowable webapps running in Tomcat now, so we can start up the user interface.  We’ll begin with the Task interface, so fire up your fav browser, navigate to http://localhost:8080/flowable-task and you should see the login screen below.

Login with the user admin and password test and you’ll be taken to your tasks homepage.  At the moment it will look a bit of a lonely place, with just one App – the general Task App that gives you access to all tasks across all Flowable process apps.


Click into the Task App to see a list of tasks assigned to you (Tasks page), or processes (Processes page) you’ve started. Not surprisingly, both are currently empty, so let’s add an ad hoc task by clicking the Create Task button.

Fill in some details and create the task. The task will be assigned to you by default, so you’ll now see the new task in your Tasks list. The currently selected task’s details are shown as well, but again, there’s very little to see here at the moment.

If you’re bored, you could just click the Complete button and feel a certain pride in finishing another job. It might be more interesting if you were to do some additional things to the task. If there were other users in the system, you could click on the Assignee to pass the task onto them, but there’s only the one user at the moment. You can set a due date – just click on No due date and select a date from the calendar.

Fine, you say, what else? Well, try adding a file to the task and a comment. You use this when you want to attach some documents, images or videos that may help the person working on the task. Also, comments are a good way of communicating with other people if you involved them in working on the task.

Talking to yourself isn’t healthy, so we need to start working with more people. We need a little scenario to build out our example, so let’s imagine there’s an awesome band called the Flow Pistols, with band members Joram Rotten, Tijs Vicious, Yvo Jones and Paul Cork, who will have gigs around the globe, albums to record in studios and TVs to throw out of hotel windows. Their manager is Malcolm Mysterious. We’ll create a simple process to help them manage themselves better.

Add and manage users

It’s the time for us to jump to another Flowable interface to create new users, groups and privileges. Open a new tab or window in your browser and navigate to http://localhost:8080/flowable-idm (noticing that you didn’t need to login because you’d already logged in to the Tasks interface). There are 3 pages in the IDM (IDentity Management) interface and you land on the User page first, so let’s create some users.


Just keep adding all of the band members as users. Remember to add Malcolm as well.

It will also be useful to manage the band as a group, so switch to the Groups page and create a new group.


With a new group, there are no members showing in the list. If there was, the search box would allow you to filter the list to check membership. To add a user to the group, click + add user, and a popup search provides a way for you to search for a user to add. Currently, the search is case sensitive, so to find Joram to add, enter ‘J’ or any group of letters, like ‘ram’ or ‘Rot’. Add the four band members: Joram, Tijs, Yvo and Paul.

Next we need to give the right access privileges to the different users. Switch to the Privileges page and add Malcolm as a user in all the privilege groups, so he can have full control over new users and administering the system (well, he is a control freak).

For the rest of the band, he only wants them to have access to the Task interface, so add the Flow Pistols group to the workflow application privilege.

Design the process

Now it’s time to define the process. We’ll keep it simple as a first attempt. To design a process you need to have the modeler privilege, which gives us a chance to test the privileges by signing off as admin and signing in as malcolm to the Modeler interface (http://localhost:8080/flowable-modeler). After signing in, you’ll be taken to the Process page and need to click Create process to get started. Fill in some details, including a unique key as an identifier for the model.


You’ll be taken directly into the process design interface, with a palette of BPMN 2.0 elements on the left-hand side. There’s a panel in the bottom part of the page with all the properties for the model. This panel gets updated with the properties of whatever has been selected in the process canvas. Which takes us to the design canvas – with a new process, a Start event element is already there, represented as a small circle.

You can design the process by dragging and dropping elements from the palette on the left, or you can use the “quick menu” of a selected element on the canvas. I find the quick menu the quickest (why would that be?), so that’s the approach I’m going to use. Click on the start event on the canvas and its quick menu will become visible. We’re going to add a User Task next, so click the icon representing a user.


This should add a box linked by an arrow to the start event. Double-click on the box to give the task the name Choose gig location and click outside the box to save the change. Click on the box again to display its quick menu and select the Gateway icon (a diamond containing x).


This adds an exclusive gateway after the task. If you wanted it to be an inclusive or parallel gateway you could click the spanner icon on the quick menu to change the type of gateway, but leave it for now. After the gateway we’re going to add another task for a person, so click the User Task icon.


Name the new task Book stadium sound system and drag the bend in the connecting arrow to above the gateway by moving the mouse over the connector and grabbing the red dot that appears on the bend.


Click on the gateway element and click the User Task icon again. This adds another task connected to the gateway. Name it Book transport for bandgear and lay it out to make the process diagram nice and clear.


Click on the last task and select the Gateway icon. This will add another gateway, and before doing anything else, just quickly click the Stop event icon on its quick menu (circle with a thick border).


Now we need to connect the “stadium” user task to this gateway, which we can do using the Connector icon on its quick menu. Click on it and drag the mouse over to the last gateway and release to complete the connection.


The connector is straight, so here’s a chance to see how we can add (or remove) bends to lay it out as we wish. The “bend” edit icons are in the toolbar.


Click the + bend icon to switch into bend edit mode.


Click on the connector where we want to add the bend and a red dot will appear, which can then be dragged to create a more pleasing layout.


This gives us the overall process we want to use, so now let’s add some forms to the user tasks to collect data that we need as part of the process

Draw some data collection forms

There’s a couple of ways you can define forms. One is to go to the Forms page in the Modeler interface and just create form models, then link them to the process. Alternatively, you can create them within the process model automatically linked (and they’ll also show on the Forms page). You can add forms to User Tasks and Start Events by selecting the element and clicking their Referenced form property. This pops up a large dialog with options to select and open an existing form, or create a new one. Let’s get going with the process for the Flow Pistols, by selecting the Start Event and clicking its Referenced form property, then click the New form button and complete the details to create a form, including a unique form key identifier.


This will now take you into the Form designer, with form components on the left-hand side that can be dragged onto the design canvas. The only data we want to collect when a process is started is in which part of the world the gig will take place. We can do this by using a dropdown field, so drag and drop the Dropdown element from the palette on the left to the design canvas.

It will be given a default name of “Label”, which isn’t too informative, so to change it, hover your mouse over the dropdown field on the canvas and an edit button (pencil) will appear. Click on this to edit the settings for this field. Give the field the label Continent and you’ll also see it give an Id (identifier) of continent, which is the reference we’ll use to refer to this field later. It’s also possible to define your own identifier. You can also mark a field as Required, meaning the form won’t complete unless a value is given.


We want to define the values for the dropdown menu, so click on the Options tab and add Europe, The Americas and Asia.


Close the field edit dialog and then save the form. You’ll be taken back to the process designer.

Next, select the Choose gig location user task and click its Referenced form property. Again, click New form and get taken to the form designer. This time, drag an Expression field onto the canvas, followed by a Text field, then a Date field and finally a Number field. We’re going to use the Expression field to give some relevant information to the person who will complete the form. Edit the Expression field and enter the text “Please choose the city and audience size for this gig in ${continent}…”. As you may have guessed, the value selected in the initial form for the Continent field will be substituted in the text.


Edit the Text field and give it the label City; likewise, label the Date field as Date and Number field as Size (k) (its identifier will be sizek). You should now have a form that looks something like the following.


Finally, add new forms for the two booking user tasks. Add an Expression field and Text field for each, edit the Expression field and give it an expression like
“Please arrange the stadium sound system for the tour in ${continent} on ${date} in ${city} and enter the reference …”, and give the Text field a label like “Stadium booking reference”. Do I need to say change the text and label as appropriate for the Booking transport for the band’s own gear task?


We now have tasks and forms to collect data as we go through the process, but who’s responsible for doing what? Responsibility isn’t a word that’s familiar to rock stars like the Flow Pistols, but efficient processes means saving costs, which means more cash in the pockets of our rockers to spend on their outrageous lifestyle. Let’s define who does what.

Assign tasks to people

Responsibility for a task is defined by setting its assignment. You can do this by selecting a User Task and clicking its Assignments property. A dialog pops up that allows you to choose whether the assignee should be a single person (it can be a named user, or simply the person that started the process); a list of candidate users; or, one or more candidate groups. If a task is assigned to a list of candidates or groups, then someone from the list or group has to claim the task to work on it – it then becomes directly assigned to them for that specific task in that specific instance of the process.

Let’s add some assignments. Select the Choose gig location user task and click its Assignments property. In the dialog that pops up, select Assigned to process initiator leaving the Type as Identity store.


Whoever starts the process will now get the Choose gig location task assigned directly to themselves. However, for booking the stadium gear, Malcolm is the only person with the knowledge and appropriate responsibility to do it. Select the stadium booking task and click its Assignments property. This time, select Assigned to single user and type “M” into the search box that appears. This will show a list of all users in the identity store that contain “M”, which includes Malcolm in this case, so pick his name.


When it comes to booking transport for the band’s own gear, we’re happy to let anyone in the band organize that. Select the booking transport task and click its Assignments property. Select Candidate groups, type “F” in the search box and pick the Flow Pistols group. We’ll also let anyone complete this task if they started the process, so turn on that option. This means that Malcolm can do the task, even though he’s not a member of the Flow Pistols group.


Nearly done on the process. The final thing to describe is when to take which of the different paths that are possible.

Define flow conditions

We have a choice of two paths through the process, so next we can define the conditions for taking one route or the other. Double-click on the connector going into the “stadium” task and give it the name Over 2k to help anyone looking at the diagram.


However, to actually define the condition we need to select the connector and click on the Flow condition property in the panel at the bottom. This opens a dialog where you can enter the expression that will be evaluated for a process to take that path. We want to follow the stadium path when there’s more than 2000 fans expected in the audience, so enter the expression ${sizek > 2}. We want the flow to go to organizing the band’s own gear in all other cases, so if we select that flow connector we can mark it as the Default flow in its properties.


It’s also sensible to review the order in which the flow conditions are evaluated. The initial flow order is the order in which the conditions are defined. If that’s the order you need, you’re fine; if all your conditions are mutually exclusive, the order shouldn’t matter. Just to be sure, you can select the gateway element itself and click on the Flow order property, which allows you to reorder the conditions. It’s always worthwhile checking flow order if you have a connector without an explicit condition.


That’s it: process defined! We rock! However, before we can use it, we need to publish the process and all its components as a Process App. Switch to the Apps page in the Modeler to create our first app.

Create a Process App

Once we have one or more processes designed, we can make them available for people to use. Typically, processes are grouped together either by who is going to use them or how they’re going to be used. You might put all your Human Resources processes in one process app, for example. We’re just going to have one process to begin with, so first click the Create app button on the Apps page, giving it a name, unique key and description.


We’ll then get taken to the App editing view where we can pick an app icon and theme to help distinguish it from other apps. We also need to add our process to the list of models in the app, so click the Edit included models button. You’ll be shown a list of all the process models available and can select one or more to be included: select the process we just defined.

Save the app model and we have our first app defined, but still not quite ready to be used. To make an app available for use, it meeds to be “published’, and everytime changes are made to any part of the process or forms, you will need to publish the app again to make those changes live. If you were sharp-eyed you will have noticed an option to publish on the Save App dialog. You can publish an app at anytime from its details view. Select our app from the Apps page and you’ll be taken to the details view. You’ll see a bunch of actions you can take from the toolbar, including Publish. Click that now.

We’ve finally got to the point where we can use our new process. We mega rock!

Starting your first process

To start processes and view tasks, we need to use the Task interface again. Staying logged in as Malcolm, switch to http://localhost:8080/flowable-task. If you’re on the home page you’ll see the new Gig App (if not, click on the top left Flowable logo to get there), so click the Gig App to work with all tasks and processes associated with it.

If you go into the generic Task App then you can see and work on all tasks and processes for all the apps available to you.  Once in the Gig App task view, there’s a help bubble with an option to start a new process.


If you have tasks still active and no help bubble, you can also start a process by going to the Processes page. Whichever way you go, you’ll then get presented with a list of processes available within that process App. There’s only one for us to pick, and we’ll see its start form ready for us to pick a continent. Select a continent and click the Start process button.

You’ll then be taken to the details view for the just created instance of the process. Here, you can see what tasks have been completed, what tasks are active and a graphical diagram of the process with its current state.

Switch to the Tasks page and you should see a Choose gig location task for you (as you were the process initiator). Enter an city and date, plus an audience size greater than 2k, for example 50, then click the Complete button.

The view will switch to a Book stadium task, because the last task was completed and almost immediately a new task added to the top of your task list. Remember, only Malcolm will get assigned this task, so you need to be logged in as him to see it. Type some value for the booking reference and click the Complete button.

There we go, we’ve finished our first run of our process, and no animals or children were harmed, no public offended.

Taking a different path

Let’s create another instance of the process and take the alternative route using a different user.  Sign out using the menu on the user’s name in the top right corner and then login using paul with the password you gave the user Paul Cork.  Start a new instance of the process from the Gig App, but this time, give an audience size of 2 in the start form.

On the Tasks page, you may be surprised to see nothing. That’s because the task list shows tasks directly assigned to the user, but this can be changed by clicking the filter area at the top of the task list. Select the filter option Assignment and set it to Tasks where I am one of the candidates.

The task list should now show a task to book the transport, but before you can work on it, you need to get it assigned directly to yourself. Otherwise, it’s like its just sitting in a queue of tasks for the band, waiting for someone to take ownership, or work through the other queued tasks.

Click the Claim button and you’ll now be able to see the task form and complete the task.

Dude, we’re nearly done.

Looking at completed processes

You can look at what was entered in tasks that have been completed by going to the Processes page and changing the list filter to include completed processes. Select the completed instance you’re interested and you’ll see its status view. To look at what data was entered in a form, click one of the completed tasks listed and you’ll be shown the form with the data used.


Wrapping up

There we go, Flow Fans, a run through of just a small part of what you can do with Flowable without writing a line of code. Hopefully, it’s given you enough of an introduction for you to go back and explore some of the options I completely ignored and also try your own processes.

And I think you can be sure you haven’t heard the last from the Flow Pistols!