Plugins that bundle whole models
Package entire processes, cases and agents as reusable plugins for cross-team reuse.
What it is
Flowable plugins can now bundle BPMN and CMMN models in addition to services. That means an entire reusable workflow or case model can be packaged as a plugin and shared, rather than copied, across teams. A plugin task can reference processes and cases, so a single packaged capability can pull in whatever combination of models a team needs to reuse.
This turns plugins into a genuine distribution unit for proven, reusable building blocks: a team authors a process or a case once, packages it, and other teams consume it as a single dependency.
What’s included:
- Plugins that bundle BPMN and CMMN models as well as services.
- Plugin tasks that reference processes and cases, not just services.
- A Date option type for input parameters when creating a plugin.
- Plugin tasks then show up either in the BPMN or CMMN editor as own building blocks in the palette.
- Plugins can now be linked by latest or by explicit version per workspace, so different workspaces can use different version of a plugin.
- Plugins can now be installed directly from the Design UI, without having to export and upload it again.
Why it matters
As model libraries grow, copying logic between teams creates drift and maintenance pain. Bundling whole models into plugins gives organisations a clean way to standardise on shared, governed building blocks. Reuse happens by reference, so an improvement to a packaged process or agent reaches every team that depends on it by version. Version pinning allows organizations to decide when they want to upgrade to a newer version of a plugin.
How it works
When creating a plugin, you choose the models it bundles, including processes, cases and other models, and define its input parameters. You install it and link it to a workspace, exposing the reusable process to the process or case palette. Consuming teams drag and drop the encapsulated business logic that references the packaged process, case or agent into their workflow.
Example
A central team owns a standard “approval” process. They package both as a plugin with a few typed input parameters. Other teams add that plugin task that references the packaged case and agent, reusing the standard approval flow without rebuilding it, and they receive improvements automatically as the central team updates the plugin, or they decide when they want to upgrade by pinning the plugin version.