Auto deployment overview
Flowable provides auto deployment options from models and configuration files available on the classpath. This page gives an overview of all the folder paths and configuration options that can be used to auto deploy models and configuration files.
App auto deployment
The easiest way to use the auto deployment feature is to deploy apps from the classpath to the Flowable Platform. In this way all models included in the app will be deployed and connected with the same parent deployment. The following folders are supported out-of-the-box:
apps/com/flowable/app/default/**/com/flowable/app/custom/**/com/flowable/app/example/**/
Only app files with a suffix of .bar and .zip will be considered in these folders.
The apps folder can be changed to use another folder by setting a flowable.app.resource-location value in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/apps/.
If it's needed to disable the app deployment of the apps/ folder or a custom configured folder this can be done by setting flowable.app.deploy-resources=false.
Additionally it's possible to disable the deployment of example apps from the com/flowable/app/example/**/ folder by setting flowable.example.deploy-apps=false.
Model auto deployment
In this section an overview is provided of the auto deployment options per model type.
Case model auto deployment
It's possible to deploy case models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following case folders are supported out-of-the-box:
cases/com/flowable/cmmn/default/**/com/flowable/cmmn/custom/**/
Only case models with a suffix of .cmmn and .cmmn.xml will be considered in these folders.
The cases folder can be changed to use another folder by setting a flowable.cmmn.resource-location value in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/cases/.
If it's needed to disable the case model deployment of the cases/ folder or a custom configured folder this can be done by setting flowable.cmmn.deploy-resources=false.
Process model auto deployment
It's possible to deploy process models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following process folders are supported out-of-the-box:
processes/com/flowable/bpmn/default/**/com/flowable/bpmn/custom/**/
Only process models with a suffix of .bpmn and .bpmn20.xml will be considered in these folders.
The cases folder can be changed to use another folder by setting a flowable.process-definition-location-prefix value in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/processes/.
If it's needed to disable the process model deployment of the processes/ folder or a custom configured folder this can be done by setting flowable.check-process-definitions=false.
Decision model auto deployment
It's possible to deploy decision models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following decision folders are supported out-of-the-box:
dmn/com/flowable/dmn/default/**/com/flowable/dmn/custom/**/
Only decision models with a suffix of .dmn and .dmn.xml will be considered in these folders.
The dmn folder can be changed to use another folder by setting a flowable.dmn.resource-location value in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/dmn/.
If it's needed to disable the decision model deployment of the dmn/ folder or a custom configured folder this can be done by setting flowable.dmn.deploy-resources=false.
Event registry model auto deployment
It's possible to deploy event registry models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following event registry folders are supported out-of-the-box:
eventregistry/com/flowable/eventregistry/default/**/com/flowable/eventregistry/custom/**/
Only event registry models with a suffix of .channel and .event will be considered in these folders.
The eventregistry folder can be changed to use another folder by setting a flowable.eventregistry.resource-location value in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/eventregistry/.
If it's needed to disable the event registry model deployment of the eventregistry/ folder or a custom configured folder this can be done by setting flowable.eventregistry.deploy-resources=false.
Form model auto deployment
It's possible to deploy form models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following form folders are supported out-of-the-box:
forms/com/flowable/forms/default/**/com/flowable/forms/custom/**/
Only form models with a suffix of .form and .page will be considered in these folders.
The forms folder can be changed to use another folder by setting a flowable.form.resource-location value in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/forms/.
If it's needed to disable the form model deployment of the forms/ folder or a custom configured folder this can be done by setting flowable.form.deploy-resources=false.
Action model auto deployment
It's possible to deploy action models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following form folders are supported out-of-the-box:
com/flowable/action/default/**/com/flowable/action/custom/**/
Only actions models with a suffix of .action will be considered in these folders.
Content model auto deployment
It's possible to deploy content models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following content folders are supported out-of-the-box:
com/flowable/document/default/**/com/flowable/document/custom/**/
Only content models with a suffix of .document will be considered in these folders.
Data object model auto deployment
It's possible to deploy data object models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following content folders are supported out-of-the-box:
com/flowable/databject/default/**/com/flowable/databject/custom/**/
Only data object models with a suffix of .data will be considered in these folders.
Policy model auto deployment
It's possible to deploy policy models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following policy folders are supported out-of-the-box:
com/flowable/policy/default/**/com/flowable/policy/custom/**/
Only data object models with a suffix of .policy will be considered in these folders.
Query model auto deployment
It's possible to deploy query models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following query folders are supported out-of-the-box:
com/flowable/platform/query/default/**/com/flowable/platform/query/custom/**/
Only query models with a suffix of .query will be considered in these folders.
If it's needed to disable the query model deployment this can be done by setting flowable.platform.deploy-resources=false. Note this disables sequence, variable extractor and dashboard component model auto deployments as well.
Service registry model auto deployment
It's possible to deploy service registry models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following service registry folders are supported out-of-the-box:
com/flowable/service/custom/**/
Only service registry models with a suffix of .service will be considered in these folders.
If it's needed to disable the service registry model deployment this can be done by setting flowable.service-registry.deploy-resources=false.
Sequence model auto deployment
It's possible to deploy sequence models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following sequence folders are supported out-of-the-box:
com/flowable/platform/sequence/default/**/com/flowable/platform/sequence/custom/**/
Only sequence models with a suffix of .sequence will be considered in these folders.
If it's needed to disable the sequence model deployment this can be done by setting flowable.platform.deploy-resources=false. Note this disables query, variable extractor and dashboard component model auto deployments as well.
Template model auto deployment
It's possible to deploy template models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following template folders are supported out-of-the-box:
com/flowable/template/default/**/com/flowable/template/custom/**/
Only template models with a suffix of .tpl and .tplvariation will be considered in these folders.
User model auto deployment
It's possible to deploy user models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following user folders are supported out-of-the-box:
com/flowable/users/default/**/com/flowable/users/custom/**/com/flowable/users/minimal/**/
Only user models with a suffix of .user.json will be considered in these folders.
If it's needed to disable the user default model deployment this can be done by setting flowable.platform.idm.deploy-default-resources=false.
If it's needed to disable the user custom model deployment this can be done by setting flowable.platform.idm.deploy-custom-resources=false.
It's also possible to only consider the minimal setup user models by setting flowable.platform.idm.minimal-setup=true.
User account model auto deployment
It's possible to deploy user account models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following user account folders are supported out-of-the-box:
com/flowable/user-accounts/default/**/com/flowable/user-accounts/custom/**/
Only user models with a suffix of .user.account.json will be considered in these folders.
If it's needed to disable the user account default model deployment this can be done by setting flowable.platform.idm.deploy-default-resources=false.
If it's needed to disable the user account custom model deployment this can be done by setting flowable.platform.idm.deploy-custom-resources=false.
Additional configuration file auto deployment
In this section an overview is provided of the auto deployment options for the additional configuration files, in addition to the other model types already described above.
Indexing mapping auto deployment
It's possible to deploy indexing mapping files directly from the classpath to the Flowable Platform. The following indexing mapping folders are supported out-of-the-box:
com/flowable/indexing/mapping/default/**/com/flowable/indexing/mapping/custom/**/com/flowable/indexing/mapping-extension/custom/**/
Only indexing mapping files with a suffix of .json will be considered in these folders.
Variable extractor mapping auto deployment
It's possible to deploy variable extractor mapping files directly from the classpath to the Flowable Platform. The following variable extractor mapping folders are supported out-of-the-box:
com/flowable/platform/variableextractor/default/**/com/flowable/platform/variableextractor/custom/**/
Only variable extractor mapping files with a suffix of .extractor will be considered in these folders.
If it's needed to disable the variable extractor model deployment this can be done by setting flowable.platform.deploy-resources=false. Note this disables query, sequence and dashboard component model auto deployments as well.
Theme auto deployment
It's possible to deploy theme files directly from the classpath to the Flowable Platform. The following theme folders are supported out-of-the-box:
themes/com/flowable/themes/custom/**/
Only theme files with a suffix of .json will be considered in these folders.
The themes and custom folder can be changed to use another folder by setting a flowable.platform.default-theme.resource-locations value for the default theme in the application properties.
The themes and custom folder can be changed to use another folder by setting a flowable.platform.theme.resource-locations value for a custom theme in the application properties.
Note that it's advised to use a path configuration which is specific like classpath*:/themes/ and note that the value can be a list of values.
Dashboard component auto deployment
It's possible to deploy dashboard component files directly from the classpath to the Flowable Platform. The following dashboard component folders are supported out-of-the-box:
com/flowable/platform/dashboardComponent/default/**/com/flowable/platform/dashboardComponent/custom/**/
Only dashboard component files with a suffix of .dashboardComponent will be considered in these folders.
If it's needed to disable the dashboard component model deployment this can be done by setting flowable.platform.deploy-resources=false. Note this disables query, sequence and variable extractor model auto deployments as well.
Work filter mapping auto deployment
It's possible to deploy work app filter files directly from the classpath to the Flowable Platform. The following work app filter folders are supported out-of-the-box:
com/flowable/filters/work/default/**/com/flowable/filters/work/custom/**/
Only work app filter files with a suffix of .json will be considered in these folders.
Task filter mapping auto deployment
It's possible to deploy task app filter files directly from the classpath to the Flowable Platform. The following task app filter folders are supported out-of-the-box:
com/flowable/filters/task/default/**/com/flowable/filters/task/custom/**/
Only task app filter files with a suffix of .json will be considered in these folders.
Conversation model auto deployment
It's possible to deploy conversation models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following conversation folders are supported out-of-the-box:
com/flowable/conversation/default/**/com/flowable/conversation/custom/**/
Only conversation models with a suffix of .json will be considered in these folders.
Conversation filter model auto deployment
It's possible to deploy conversation filter models directly from the classpath to the Flowable Platform. We recommend to first consider using app auto deployment. The following conversation filter folders are supported out-of-the-box:
com/flowable/filters/conversation/**/
Only conversation filter models with a suffix of .json will be considered in these folders.
Flowable Engage model auto deployment
In this section an overview is provided of the auto deployment options for the Flowable Engage model types.
Conversation model auto deployment
It's possible to deploy conversation models directly from the classpath to the Flowable Platform. The following conversation folders are supported out-of-the-box:
com/flowable/conversation/default/**/com/flowable/conversation/custom/**/
Only conversation models with a suffix of .json will be considered in these folders.
Conversation filter model auto deployment
It's possible to deploy conversation filter models directly from the classpath to the Flowable Platform. The following conversation filter folders are supported out-of-the-box:
com/flowable/filters/conversation/**/
Only conversation filter models with a suffix of .json will be considered in these folders.
Flowable Work default auto deployment
The default Flowable Work application contains several models and configuration files that are deployed out-of-the-box, to configure the Flowable Work application with a set of default models. Also when the flowable-platform-default-models dependency is set for custom projects these default models will be added to your application. In this section an overview is provided of these default models.
Default action models
Actions provide a flexible way to allow for adding new capabilities to a set of work items like cases, processes and tasks. There is a good amount of default action models that are deployed through the flowable-platform-default-models dependency. In case your project requires to have a different set of action models it's best to create a custom version of these module and use that in your application. You can find below an overview of the standard action models with a short description.
| Action name | File name | Description |
|---|---|---|
| Cancel process instance | bpmn-cancel-process.action | Provides the cancel action to delete a runtime process instance, only for admins. |
| Complete user task | bpmn-complete-usertask.action | Allows to complete a user task for a process instance. |
| Start progress task | bpmn-task-start-progress.action | Starts the progress of a user task for a process instance. |
| Test action | bpmn-test-action.action | Non global action that can used to test action buttons. |
| Cancel case instance | cmmn-cancel-case.action | Provides the cancel action to terminate a runtime case instance, only for admins. |
| Complete human task | cmmn-complete-humantask.action | Allows to complete a human task for a case instance. |
| Manual activation | cmmn-manual-activated-planitem.action | Action that is used to trigger a manual activation plan item in a case. |
| Reactivate case | cmmn-reactivate-case.action | Allows to reactivate a completed case instance when a reactivation listener is included in the case. |
| Start progress task | cmmn-task-start-progress.action | Starts the progress of a human task for a case instance. |
| Trigger user event listener | cmmn-user-event-listener.action | Action that is used to trigger a user event listener in a case. |
| Deactivate internal user | deactivate-internal-user.action | Provide the option to deactivate an internal user, only for admins. |
| Deactivate user | deactivate-user.action | Provide the option to deactivate an external user, only for client operators and admins. |
| Reactivate internal user | reactivate-internal-user.action | Provide the option to reactivate an internal user, only for admins. |
| Reactivate user | reactivate-user.action | Provide the option to reactivate an external user, only for client operators and admins. |
It's important for regular usage of Flowable that these default actions are available. When wanting to customize default action models then a good analysis of all requirements is recommended.
Default process models
There is one default process model deployed, which provides a default approval process for performing a template message change.
So this is only applicable when the option for changing template messages is activated, which is not the default.
The filename for this process model is TM-P01_Template_Change_Approval_Process.bpmn20.xml.
Default decision models
There is one default decision model deployed, which provides a default permission check for user management, like who is allowed to create a user, deactivate a user, reactivate a user etc.
The filename for this decision model is R01 - Default User Permissions.dmnl.
Default content models
By default, 3 content models are provided to define a content type for content items in Flowable, like for an attachment field on a form with content type enabled. The following content models are included:
| Content name | File name | Description |
|---|---|---|
| Contract | contract.document | Provides a contract content item type. |
| General | general.document | Provides a general content item type. |
| Policy | policy.document | Provides a policy content item type. |
Default form models
As part of the default form models there are several forms included to provide forms to manage users in Flowable, provide forms for the content models and to support changing template messages. When it's needed to customize a form to create a user or edit a user, the default form model should overwritten with a custom form model, using the same form key.
Default policy models
One of the most important default models that are included in the out-of-the-box models are the 2 security policy models.
There is a regular and a strict security policy that can be used. It's important to have the regular security policy model with a model key basic-security-policy available within Flowable because
it's used for all permission checks for cases, processes, tasks and documents. If you want to customize the regular security policy model then a custom security policy model with model key
basic-security-policy can be used and made available to Flowable. In addition, it's also possible to change the default security policy model used by Flowable by setting the model key with the
flowable.policy.default-security-policy property.
In addition to the regular security policy also a strict security policy is provided. The main difference between the strict security policy and the regular one is that the permissions for the current user are not checked in the parent work item, like a parent case instance or process instance for the strict version. This means that the current user needs to have the correct identity links on the current work item, like a task, to allow an action like task edit or task delete to be allowed.
Default template models
There are several template models provide as part of the default models. There is a template provided for demo and testing purpose to make it easier to test the document generation feature of Flowable.
The document template that is available for this has a model key of demo-word-template-01. In addition, there are several template message files to define default application messages like a confirmation
message and an authorization message. These message values can be adapted when needed by override the template files with a custom version using the same model key.
Default theme models
In addition to the default theme, which is built-in to the Flowable application, there is also a contrast theme made available, so that users can select this theme when needed. The contrast theme can be used when there is a requirement for WCAG compliance, as there contrast between different colors is part of the requirements.