anchor.diff:  |admin.password|Password of the default administrator user for the Flowable IDM application. Default is test.
   |admin.firstname|Firstname of the default administrator user for the Flowable IDM application. Default is Test.
   |admin.lastname|Lastname of the default administrator user for the Flowable IDM application. Default is Administrator.
  -|file.upload.max.size|Maxmimum size of file uploads like attachments and model files
  -|contentstorage.fs.rootFolder|Root folder location where content files will be stored like task attachments or form file uploads
  +|file.upload.max.size|Maxmimum size of file uploads, such as attachments and model files
  +|contentstorage.fs.rootFolder|Root folder location where content files will be stored, for example, task attachments or form file uploads
   |contentstorage.fs.createRoot|If the root folder doesn't exist, should the Flowable Task application create it?
  -|idm.app.url|The url to the IDM application, used for the login redirect when the cookie isn't set or is invalid, and for the user info and token info REST GET calls.
  +|idm.app.url|The URL to the IDM application, used for the login redirect when the cookie isn't set or is invalid, and for the user info and token info REST GET calls.
   |idm.admin.user|The username used for executing the REST calls (with basic auth) to the IDM REST services. Default is admin.
   |idm.admin.password|The password used for executing the REST calls (with basic auth) to the IDM REST services. Default is test.
  -|deployment.api.url|The root URI to th REST services of the Flowable Engine, used by the Flowable Modeler application to deploy the application definition BAR file to the Engine. Default url for the Flowable Task application is http://localhost:8080/flowable-task/process-api
  +|deployment.api.url|The root URI to th REST services of the Flowable engine, used by the Flowable Modeler application to deploy the application definition BAR file to the engine. Default url for the Flowable Task application is http://localhost:8080/flowable-task/process-api
   
   |===============
   
  -In addition to these properties that are used by multiple Flowable web applications, the Flowable admin application has a few more properties. The full content of the properties file can be view on link:$$https://github.com/flowable/flowable-engine/blob/master/modules/flowable-ui-admin/src/main/resources/META-INF/flowable-ui-app/flowable-ui-app.properties$$[Github]. The additional properties are mainly used for defining the initial values for the REST endpoints for the different Engines. The Admin application uses the initial values to make a connection to the Flowable Engines, but the values can be overriden in the Admin application configuration view and these values are stored in the __ACT\_ADM\_SERVER\_CONFIG__ table. An example of the BPMN Engine REST properties is shown below:
  +In addition to these properties that are used by multiple Flowable web applications, the Flowable admin application has a few more properties. The full content of the properties file can be viewed on link:$$https://github.com/flowable/flowable-engine/blob/master/modules/flowable-ui-admin/src/main/resources/META-INF/flowable-ui-app/flowable-ui-app.properties$$[Github]. The additional properties are mainly used for defining the initial values for the REST endpoints for the different engines. The Admin application uses the initial values to make a connection to the Flowable engines, but the values can be overriden in the Admin application configuration view and these values are stored in the __ACT\_ADM\_SERVER\_CONFIG__ table. An example of the BPMN Engine REST properties is shown below:
   
   [source,linenums]
   ----
  
positive.code: 
  image::images/flowable_modeler_vacationrequest_screen.png[align="center"]
  
  With the process model completed, we can now create an app definition that combines one or more process models with all used other models (e.g. decision tables and form definitions) into a single artefact. An app definition can be exported to a BAR file (a zip file) that can be deployed on the Flowable Engine. When creating an vacation request app definition, the app editor will be shown similar to the screen below.
  
  image::images/flowable_modeler_appeditor_screen.png[align="center"]
  
  In the app editor an icon and a color can be selected that will be used in the Flowable Task application to show the application in the dashboard. The important step is to add the vacation request process model, and by selecting the process model, automatically include the form definition and DMN decision table.
  
  image::images/flowable_modeler_modelselection_popup.png[align="center"]
  
  A process model can be selected by clicking on the model thumbnail. When the model is, or models are, selected then you can close the popup and save the app definition and close it. When navigating to the details view of the newly created vacation request app definition, the following details screen is presented.
  
  image::images/flowable_modeler_appdetails_screen.png[align="center"]
  
  From this view you can download the app definition in two different formats. The first download button (with the arrow pointing downwards) can be used to download the app definition with the JSON model files for each included model. This makes it easy to share app definitions between different Flowable Modeler applications. The second download button (with the arrow point to upper right) will provide a BAR file of the app definition models that can be deployed on the Flowable Engine. In the BAR file only the deployable artefacts are included, like the BPMN 2.0 XML file and the DMN XML file, and not the JSON model files. All files in a BAR file will be deployed on the Flowable Engine and stored in the database and therefore only the deployable files are included. 
  
  From the app definition details view, you can also _Publish_ the app definition directly to the Flowable Engine. The Flowable Modeler uses the url defined in the flowable-ui-app.properties file with the _deployment.api.url_ property key. By default, the deployment url is configured so the app definition will be deployed on the Flowable Task application when it's running. But this can be changed to use the Flowable REST application for example. Make sure the Flowable Task application is running and click on the _Publish_ button. The app definition is now deployed as a BAR file to the Flowable Task application.
  
  
  [[flowableTaskApp]]
  
  === Flowable Task application
  
  The Flowable Task application is the runtime application of the Flowable project and includes the Flowable BPMN, DMN, Form and Content Engines by default. With the Flowable Task application new process instances can be started, tasks can be completed, task forms can be rendered etc. In the previous section the vacation request app definition was deployed on the Flowable Task application REST API, and through that deployed on the Flowable Engine. If you look in the Flowable database, you can see a new deployment entry has been added to the ACT_RE_DEPLOYMENT table for the BPMN Engine. But also new entries haven been created in the ACT_DMN_DEPLOYMENT and ACT_FO_FORM_DEPLOYMENT tables for the DMN and Form engines. 
  
  On the dashboard on link:$$http://localhost:8080/flowable-task$$[http://localhost:8080/flowable-task], you can see a vacation request app being available in addition to the default Task app, and optionally, other apps that have been deployed to the Flowable Engine already. 
  
  image::images/flowable_task_dashboard_screen.png[align="center"]
  
  
negative.code: 
  image::images/flowable_idm_privilege_screen.png[align="center"]
  
  There's no option to define new privileges yet, but you can add and remove users and groups from the existing four privileges.
  
  
  [[flowableModelerApp]]
  
  === Flowable Modeler application
  
  The Flowable Modeler application can be used to model BPMN processes, DMN decision table, Form definitions and create app definitions. The BPMN modeler uses the same Oryx and Angular foundation as in Flowable 5, but the functionality has now been moved into a separate Modeler application. When using the Flowable Modeler application, make sure the Flowable IDM application is deployed and running as well (for authentication and authorization purposes).
  
  When you login to the Modeler application (link:$$http://localhost:8080/flowable-modeler$$[http://localhost:8080/flowable-modeler]) with your user (or the default admin/test user), you will see the process overview screen. From here you can start creating new BPMN process models by clicking on the Create Process or Import Process button.
  
  image::images/flowable_modeler_createmodel_popup.png[align="center", width="600"]
  
  When creating a process model (but also any other model), it's important to think carefully about the model key value. The model key is a unique identifier for the model across the full model repository. If you choose a model key that already exists in the model repository, an error message is shown and the model is not saved.
  
  After creating the model with the popup, the BPMN modeling canvas is shown. The BPMN editor is very similar to the Flowable 5 BPMN editor that was part of the Explorer application. All BPMN elements supported by the Flowable engine are available to be used in the design of a process model.
  
  image::images/flowable_modeler_design_screen.png[align="center"]
  
  The BPMN editor is divided into 4 parts:
  
  * Palette: the palette of BPMN elements available to design a process model
  * Toolbar: actions to change the model canvas, such as zooming, layout and saving a model
  * Model canvas: the modeling canvas on which to drag and drop BPMN elements and design the proces model
  * Properties panel: the properties for the main proces model if no element is select and otherwise the properties of the selected BPMN element
  
  For a User task element there's a _Referenced form_ property in the properties panel. If you select this property, a popup is opened where you can select a form definition from the repository or create a new form. When creating a new form, a similar create dialog to the process model create dialog is presented. After filling in the name and form model key, the form editor is opened.
  
  image::images/flowable_modeler_formdesign_screen.png[align="center"]
  
  Form fields can be dragged from the form palette on to the form canvas. In this example, a name textfield, two date fields and a remarks multiline textfield are added to the form canvas. When editing a form field, the label, id, required status and placeholder can be filled in.
  
  image::images/flowable_modeler_editfield_popup.png[align="center", width="600"]
  
  The id field is an important value, because a process variable will be created with the form field value using the id property value. When filling in the label property, the id property is automatically filled. If needed, you can also provide the id property value yourself by checking the override id checkbox.
  
  After saving the form model and closing the form editor, you are automatically navigated back to the process model (when the form editor was opened via the BPMN editor). When selecting the User task element again and clicking on the _Referenced form_ property you will see that the newly created form definition is now attached to the User task. When clicking on the _Form_ tab in the header of the Modeler application, all form definitions available in the model repository are shown.
  
  image::images/flowable_modeler_formoverview_screen.png[align="center"]
  
  You can preview every form definition by opening the details view of a form definition. In the details view, the form name, key and description can be edited and the history of form models is available. You can also duplicate the form definition to create a new form definition with the same form fields. 
  
  Now let's open the vacation request process model in the BPMN editor again and add a Script task to the process model, that will calculate the number of days between the vacation start and end dates. Click on the _Script form_ property and fill in a value of _groovy_ to instruct the Flowable engine to use the Groovy scripting engine. Now click on the _Script_ property and fill in the script that calculates the number of days.
  
  image::images/flowable_modeler_script_popup.png[align="center", width="600"]
  
  Now we have a _amountOfVacationDays_ process variable we can add a Decision task to the process model. A decision task can be used to execute a DMN decision table in the Flowable DMN engine. Through the _Decision table reference_ property, a new decision table model can be created and the DMN editor is opened.
  
  image::images/flowable_modeler_dmneditor_screen.png[align="center"]
  
  The DMN editor provides a table editor with input columns, where input conditions can be defined with the process variables available in the process context, and output columns, where output variable values can be defined. In this very simple example there's one input column using the _amountOfVacationDays_ variable that checks if it's less than 10 or higher or equal to 10. When the amount of days is less than 10, an output variable _managerApprovalNeeded_ is returned with value false, and otherwise a value of true is returned. You can define multiple input columns and have multiple input conditions per rule. It's also possible to leave an input column empty, which means that it's evaluated to true for that part of the rule. You can define one or multiple output variables.
  
  Another important part of the DMN decision table definition is the hit policy. Currently, Flowable supports the First and Any hit policy. With the First hit policy, when the first rule is found that evaluates to true the DMN execution will stop and its output variables are returned. For the Any hit policy, all rules will be executed and the output variables for the last rule that evaluates to true are returned.
  
  When the DMN editor is saved and closed, the Modeler application navigates back to the BPMN editor and the newly created DMN decision table is now attached to the Decision task. The decision task will be generated in the BPMN XML like;
  
  