Skip to main content

Flowable Database Schema

The Flowable engines tables follow a common naming pattern. Each pattern for each engine is described in detail below.

The database table names associated with the Flowable open source code base start with ACT_. Database tables specific to Flowable Work or Engage start with the FLW_ prefix.

Common Secondary Identifiers​

The second part of the table name (after the first '_') is a two character identification specifying the specific use case of the table.

  • GE_: GE stands for general data, which is used for various use cases.

  • RU_: RU stands for runtime. These are the runtime tables that contain the runtime data of processes, cases, etc. that are not yet finished. Flowable only stores the runtime data during execution and removes the records after the instances ends. This keeps the runtime tables small and fast.

  • HI_: HI stands for history. These are the tables that contain historical data. When data is removed from the runtime tables, the history tables still contain all the information for these finished instances.

  • RE_: RE stands for repository. Tables with this prefix contain static information around models and definitions.

Common Suffixes​

Flowable engines typically create a deployment which results in one or more definitions. This is done by passing models (e.g., a process model, a case model, etc.) to the engine API. The engine parses the content of the model. One deployment can have multiple models. As such a deployment is a logical sort of container for related definitions.

If the deployment is successful, the following entries are created in the following tables:

  • <prefix>_DEPLOYMENT: One entry to indicate the successful deployment. All definitions that are created as part of the deployment reference this entry.

  • <prefix>_DEPLOYMENT_RESOURCES: Stores the content of the models related to a deployment. When the engine reboots and a specific definition is needed, this table is queried to rebuild the runtime behaviour based on the model.

  • <prefix>_DEF(INITION): One deployment can have multiple definitions. Typically there is definition for each model in the deployment (e.g., a process definition, case definition, form definition, etc.). The table contains all the definitions that are known to the engine and from which new instances of the definition can be started.

Common Database Tables​

The original database tables (like those for BPMN and IDM) use a Flowable schema and scripts for version management. The newer engines and tables use Liquibase for table versioning. There are two Liquibase tables related to database schema management:

  • <prefix>_DATABASECHANGELOG: This table is used by Liquibase to track which changesets have been run.

  • <prefix>_DATABASECHANGELOGLOCK: This table is used by Liquibase to ensure only one instance of Liquibase is running at a time.

Note: Liquibase is a Java based framework for tracking database schema changes.

App Engine Database Tables​

The app engine is responsible for storing and deploying app definitions.

The database tables for the App Engine are prefixed with ACT_APP_.

  • ACT_APP_DEPLOYMENT: When an app model is deployed via the app engine, a record is stored to indicate this deployment. The actual content of the deployment is referenced and stored in the ACT_APP_DEPLOYMENT_RESOURCE table.

  • ACT_APP_DEPLOYMENT_RESOURCE: This table contains the actual resource (stored as bytes) that make up an app deployment. When the engine needs the actual model, the resource is fetched from this table.

  • ACT_APP_APPDEF: The app model results in an application definition. This definition, like process/case/etc. is a representation of an app model that was successfully deployed to the app engine.

CMMN Engine Database Tables​

The database names of the Flowable CMMN Engine all start with ACT_CMMN_. The second part is a two character table name specifying the use case of the table. This use case roughly matches the service APIs.

  • ACT_CMMN_: Tables without an additional prefix contain static information such as case definitions and case deployment and resources.

  • ACT_CMMN_HI_: HI stands for history. These are the tables that contain historic data, such as past case instances, plan items, and so on.

    • ACT_CMMN_HI_CASE_INST: This table contains an entry for each case instance that was started by the CMMN engine.

    • ACT_CMMN_HI_MIL_INST: This table contains an entry for each milestone that was reached in a case instance.

    • ACT_CMMN_HI_PLAN_ITEM_INST: This table contains an entry for each plan item instance that was created as part of the case instance execution.

  • ACT_CMMN_RU_: RU stands for runtime. These are the runtime tables that contain the runtime data of case instances, plan items, and so on. Flowable only stores the runtime data during case instance execution and removes the records when a case instance ends. This keeps the runtime tables small and fast to query.

    • ACT_CMMN_RU_CASE_INST: This table contains an entry for each case instance that was started and is not yet finished.

    • ACT_CMMN_RU_MIL_INST: This table contains an entry for each milestone that was reached as part of a running case instance.

    • ACT_CMMN_RU_PLAN_ITEM_INST: A case instance execution consists of multiple instance of the plan items defined in the case definition. This table contains an entry for each instance that gets created during case instance execution.

    • ACT_CMMN_RU_SENTRY_PART_INST: Plan item instances can have sentries that guard state transitions. Such a sentry can contain multiple parts that need to be satisfied before the state change happens. This table stores any part of such a sentry that is satisfied.

DMN Database Tables​

The database names of Flowable DMN all start with ACT_DMN_.

  • ACT_DMN_DECISION_TABLE: This table contains the metadata of the deployed decision tables and corresponds with a definition from the other engines.

  • ACT_DMN_HI_DECISION_EXECUTION: This table contains audit information about DMN decision table executions.

Process Engine Database Tables​

The tables of the process engine start with ACT_. There is additional further prefix (like the other engines: CMMN or DMN) as this was the first engine that was built. Also note that because of this, some tables are reused by other engines.

  • ACT_RU_: Contains the runtime data for process instance and the related data. Once a process instance is finished, all runtime data is deleted from these tables.

    • ACT_RU_EXECUTION: Stores the process instances and pointers (called executions) to the process instance current state.

    • ACT_RU_ACTINST: Each activity in the process instance has a row in this table to indicate the current state of the activity.

    • ACT_RU_<TYPE>_JOB: The Flowable engines use the jobs tables to implement asynchronous logic, timers or history processing. These tables store the data needed for each jobs.

    • ACT_RU_ENTITYLINK: This table stores information about parent-child relations for instances. For example, if a process instance starts a child case instance this relationship is stored in this table. This enables easy querying of relationships.

    • ACT_RU_EVENT_SUBSCR: When a process definition uses events (signal/message/etc. or start/intermediate/boundary), the engine stores a reference to this table it in this table. This simplifies querying for which instances are waiting for a certain type of event.

    • ACT_RU_IDENTITYLINK: This table stores data about user or groups and their role with regards to the (process/case/etc.) instances. This table is also used by the other engines needing identity links.

    • ACT_RU_TASK: This table contains an entry for each unfinished user task of a running instance. This table is then used when querying for tasks lists of users. This table is also used by the CMMN engine.

    • ACT_RU_VARIABLES: This table stores variables related to an instance. This table is also used by the CMMN engine.

  • ACT_HI_: These tables contain historical data for both running and completed instances. The names of these tables follow the names of their runtime counterpart.

Action Engine Database Tables​

The action engine is responsible for storing action definitions and creating and storing action instances. Actions are triggerable items that typically are created as part of process or case instances and shown in a user interface. When triggered, they execute custom logic associated with its action definition.

The database tables for the Action Engine are prefixed with FLW_ACTION_. Besides the typical deployment and definition tables, there are the following tables:

  • FLW_ACTION_INSTANCE: Similar to creating a process/case instance from a process/case definition, an action instance is created for a given definition. The entry for it is stored in this table.

  • FLW_ACTION_DEF_LINK: Action definitions can be linked to other entities, for example to only be visible within a certain context. Such a relationship is stored in this table.

  • FLW_ACTION_LINK: Similarly, an action instance can have links too and these relationships are stored here.

  • FLW_HI_ACTION_INSTANCE: This table contains historical information about completed action instances.

  • FLW_HI_ACTION_LINK: This table contains history information about relationships that are no long active.

Audit Database Tables​

The audit engine allows to create and query an audit stream of business events. Such events are called audit instances and are typically created during the execution of process or case instances.

The database tables for the Audit Engine are prefixed with FLW_AUDIT_ or FLW_AU. Besides the typical deployment and definition tables, there are the following tables:

  • FLW_AUDIT_INSTANCE: Each entry in this table represents one business event.

Content Engine Database Tables​

The content engine is used to store and query content. Content can be documents, images, etc.

The database tables for the Content Engine are prefixed with FLW_CO_. Besides the typical deployment and definition tables, there are the following tables:

  • FLW_CO_CONTENT_ITEM: Each item of content has an entry in this table.

  • FLW_CO_CONTENT_OBJECT: Contains the actual bytes of the content item assuming the filesystem implementation of content is not used.

  • FLW_CO_CONTENT_METADATA: A content item can have associated metadata (e.g. author, creation data, etc.). Such metadata is stored in this table.

  • FLW_CO_CONTENT_RENDITION_ITEM: Some content can be represented in different ways, which is called a rendition. For example a Word document might get a PDF rendition or a thumbnail PNG rendition. This table stores such rendition information for content items.

Data Object Engine Database Tables​

The object engine is used to store and query objects. The tables are used in conjunction with Master Data processing.

The database tables for the Data Object Engine are prefixed with FLW_DO_ or FLW_DATAOBJECT_.

Engage Engine Database Tables​

The Engage Engine enables conversations and messages.

The database tables for the Engage Engine are prefixed with FLW_ENGAGE_. There is currently one table that does not follow the pattern, FLW_CONV, which in the future will use the common prefix.

Besides the typical deployment and definition tables, the tables in Engage have names like CONVERSATION, MESSAGE/CONVERSATION_STATUS, etc. which are self-explanatory.

Form Engine Database Tables​

The form engine stores data around form models and instances of those forms.

The database tables for the Form Engine are prefixed with FLW_FO_. The tables here have the typical deployment, definition and instance names.

Identity Engine Database Tables​

The IDM (identity management engine) stores data about users and groups.

The database tables for the Identity Engine are prefixed with FLW_ID_.

  • FLW_ID_USER_DEFINITIONS: Each Flowable user has a user definition. This definition defines the role(s) of the user, which features are enabled for the user, how the user gets created, etc.

  • FLW_ID_USER: This table contains an entry for each user defined in the system.

  • FLW_ID_GROUP: This table contains an entry for each group defined in the system.

  • FLW_ID_MEMBERSHIP: This table maps the relationship between users and groups. That is, which users are part of which groups.

  • FLW_ID_TOKEN: When a user successfully logs in, a token gets stored as part of the session-data. Each server in a cluster can query this database table to coordinate user sessions on each server.

  • FLW_IDENTITY_INFO_: This table stores unstructured data about users that is not stored in the FLW_ID_USER table.

  • FLW_ID_USER_ACCOUNT_DEFINITIONS: This table stores information about third party user accounts for other systems.

  • FLW_ID_USER_ACCOUNT: This table store a specific instance of a user account definition. It contains the specific user account detail for a specified account in the third party system.

  • FLW_ID_PRIV: Not currently used.

  • FLW_ID_PRIV_MAPPING: Not currently used.

Policy Engine Database Tables​

The policy engine is responsible for enforcing user access rights to objects. The database tables are prefixed with FLW_POLICY_.

Service Engine Database Tables​

The service engine is used to store, query and execute service definitions. A service definition describes what operations a service has, what parameters are expected and how the service is invoked. With these definitions process or case modelers can use the services without having to know the implementation details (e.g., a REST service, an expression, etc.). The database tables are prefixed with FLW_SE_.

Template Engine Database Tables​

The template engine is responsible for generating content out of a template (e.g., a Freemarker template, a Word template, etc.)

The database tables for the Template Engine are prefixed with FLW_TEMPL_. Besides the typical deployment and definition tables, there is the following table:

  • FLW_TEMPL_VAR_DEFINITION: Template definitions can have variations; for example, a Word template in different languages. Each template variation has some associated logic defining when the specific variation is used. The definition of that logic is stored in this table.

Flowable Control Database Tables​

The table associated with Flowable Control have the prefix FLW_CTRL_.

  • FLW_CTRL_CLUSTER_CONFIG: This table contains configuration template data that is for server configurations.

  • FLW_CTRL_SERVER_CONFIG: This table contains the configuration data for accessing Flowable REST API endpoints.

  • FLW_CTRL_TOKEN: When a user successfully logs in, a token gets stored as part of the session-data if the IDM engine is not in use.

  • FLW_CTRL_USER: This table store a specific instance of a user definition if the IDM engine is not in use.

Flowable Design Database Tables​

The tables associated with Flowable Design start with ACT_DE_.

  • ACT_DE_MODEL: This table contains the metadata and the JSON representation of the most recent design model created.

  • ACT_DE_MODEL_HISTORY: Each version of a design model is stored in this table.

  • ACT_DE_MODEL_RELATION: This table contains the child models of a process or case model.

  • ACT_DE_TOKEN: When a user successfully logs in, a token gets stored as part of the session-data if the IDM engine is not in use.

  • ACT_DE_USER: This table store a specific instance of a user definition if the IDM engine is not in use.

Flowable License Database Tables​

The license tables store a copy of the Flowable License file. The tables have the prefix FLW_LIC_.

Database Scripts​

By default the Flowable Work and Engage database tables are created when booting the application for the first time. This means that the database user needs to have rights to create tables, primary keys, foreign keys, indexes etc. When the application database user does not have those rights, it is possible to create the database tables with these database scripts. The ZIP file contains database SQL files for each supported database. In the upgrade folder of the ZIP are the upgrade scripts when updating to a newer version of Flowable Work or Engage. When manually creating or updating the database, ensure that you execute the flowable.engine*.sql scripts before the flowable.work*.sql (for Flowable Work) or flowable.engage*.sql (for Flowable Engage) scripts.

It is recommended to leave the database schema update property value to true, because that ensures that the database schema management framework (Liquibase) performs a verification to check if the tables are created by the SQL script files as expected. It also ensures that the hash value that Liquibase uses has a correct value.

flowable.database-schema-update=true

It’s also possible to disable the Liquibase and database schema management logic in Flowable completely by setting the value to none. In this case, Flowable will not do any checking if the tables are created as expected.

flowable.database-schema-update=ignore

Make sure that the value is not set to false, because in this case Liquibase will still do a version check if the tables are created as expected, but it will not be able to deal with hash value issues between environments, and this results in exceptions at startup.

info

The property above is for Flowable Work / Engage / Orchestrate. Flowable Design and Flowable Control have different properties. Their properties are: flowable.modeler.app.database-schema-update and flowable.control.app.database-schema-update respectively. The values and meaning of the values are the same as the ones for Work / Engage / Orchestrate.