In the Flowable Platform user permissions are only applied on the REST API level. This means that when working with the Java API, there are no restrictions when performing queries.
The permissions apply on all REST APIs whether they exist in the Flowable Platform or are part of the Flowable Open Source (OSS) REST APIs.
The following sections explain how the different permissions work.
When a user request is executed via a REST API, then each query is augmented to only query for all instances, definitions, etc. that the particular user has access to. Having access means that the user is the owner, starter, assignee, or participant of an instance, either directly as an individual or indirectly as a member of the group.
This means that when a user queries for an instance, only the instances where that user is involved in are returned.
When checking for single instances permission the entire hierarchy of the instance is checked. If a user has access to a parent instance, then the user also has access to the child instance, and the children of the child instances, etc. all the way down to the lowest leaf.
For example, if a user has started a case, within this case, another user has started a process, and this process has a task. The starter of the case has access to all tasks within the case, the process itself, and all tasks within the process.
When a user is involved within a task, then the user also becomes a participant of the parent of the task (process or case).
For example, if the task was a case task, then the user gains access to the case and its children. However, it does not gain access to the parent of the case.
Candidate users or groups can be used to model which users or groups have access to a particular instance.
When candidate users are used, then those specific users have access to specific instances. They also gain access to the parent of that object.
When candidate groups are used, then all members of that group have access to a particular process, case, task, etc. However, they do not have access to the parent of that object.
When modeling a case or a process, the
candidateStarterUsers and or
candidateStarterGroups can be defined to model which users or groups are
allowed to start a process or case for that particular definition.
When a user queries for definitions, it only gets the definitions that the
user can start (via the
Create new dialog).
When a case or a process definition has no users defined that can start it,
then normal users are not able to start the process or case.
Note: If a definition needs to be started as a top-level case or process,
then it has to have the
defined. Otherwise, it does not appear in the "Create new" dialog.
The Flowable platform can work in a multi-tenant or single tenant mode. See Multi-tenancy for more information on how to configure and use multi-tenancy.
A single tenant mode is when the users are not part of any tenant. That is
tenantId of the users is
null or the empty string.
All requests from such users use any tenant information in queries or
fetching instances, definitions, etc.
Multi-tenant mode is when the user has a value in the
All requests from such users use the tenant identifier as part of the
queries or fetching instances, definitions, etc.
If a user has the
default tenant, then the tenant identifier is not
applied (such users are special users and can access across tenants).
This means that a user in tenant
acme can only query for instances,
definitions, etc. in the
acme tenant, i.e., it cannot see instances,
definitions in any other tenant.
An administrator user is a user that is a member of a group with key
flowableAdministrator or a particular set of users defined via the
A super administrator is a user that is part of the
default tenant (when in
multi-tenancy mode) or has no tenant. These users are allowed to execute
actions and queries across all tenants and all instances.