Query Model Concepts
While interacting with any Flowable feature, data is often created or changed. For example, when filling in a form of a task in a CMMN case, when starting a new process instance, when uploading a new document, etc. this is stored in the relational database that is configured as the data store for Flowable.
In parallel, behind the scenes, this data is systematically organized and formatted in a way that's optimal for search and analysis — a process called indexing. While the term indexed is commonly used in technical circles, especially in reference to Elasticsearch, you can think of it as a method of efficiently organizing data so it's easier to find and use for creating detailed reports and interactive dashboards.
A query model is used to execute a search against this indexed data. Conceptually, it's a wrapper around a query in Elasticsearch's format. A query model behaves similar to any Flowable model: it is part of an app and when published to a runtime system it becomes a Query definition. That definition can be referenced by a unique key to execute the query and return the results of the search.
A query has input parameters that define which kind of data is accepted when executing the query. For example, in a custom query placeholders can be used that are replaced at runtime with the values for the input parameters.
A query always is executed against a specific Source Index:
work: Contains the 'work instances'. A work instance is a root process or case instance.
case-instances: Contains all case instances (runtime and historical).
process-instances: Contains all process instances (runtime and historical).
tasks: All tasks (process, case, or standalone) get indexed here.
users: Users and user information gets indexed here. When using a third party user provider such as LDAP, there won't be data indexed.
content-items: Data around content items (such as uploaded documents in the context of process and case instances).
plan-items: Stores information about plan item instances of a case instance and this is useful for heat maps or analyzing case instance optimizations.
activities: Stores information about activities executed as part of process instance executions and this is useful for heat maps or analyzing process instance optimizations.
Some indices might be disabled on your system, tis is a system administrator setting. ::note
An important concept for queries is whether or not a query is safe. When a query is set as safe, it ensures that the user executing the search will only access data they are permitted to see. This typically includes data within the user's tenant, or data related to tasks where the user is directly involved, such as being an assignee or participant, or tasks involving the user’s group.
On the other hand, there are scenarios, particularly in dashboard creation, where a broader data aggregation is necessary. For instance, compiling a company-wide report or analyzing data across different departments often requires access to data beyond an individual user’s scope. In these cases, a query needs to be configured as unsafe. Making a query unsafe allows for a more expansive data retrieval, transcending the individual user limitations. This needs to be a conscious and though-through decision, as it might open up data to the user which it previously didn't have access to and should only be given to specific users or groups.
Administrator users will automatically see all data. :::
Queries made with the query builder are currently not yet exposed through the Flowable REST API, like custom queries are.