Share data between multiple tenants

Flowable Engine
1

Dear Flowable Experts,

we are using the TENANT_ID column to separate data of different tenants. However, we have a requirement to share data between specific tenants.

As far as we can see, it is currently only possible in data queries to either specify a single tenant or none at all (ignore tenant column, read all data).

Is there a foreseen feasible approach to extend the queries so that one can specify a set of tenants instead of a single one?

Thank you!

Best,
Vasil

2

Hi Vasil,
the purpose of tenants is to separate the data. I don’t think that queries using multiple tenants are going to be added, since then the separation is “broken”. For most of the queries you can specify that you want to see all tenants (as an admin view). You can also use a default tenant (see AbstractEngineConfiguration#setDefaultTenantValue and AbstractEngineConfiguration#setDefaultTenantProvider) to share definitions between tenants. In case two tenants need to be merged you can do this as well (BPMN only so far: RepositoryService#changeDeploymentTenantId).

This said, what are you trying to achieve? What is your use-case?

Valentin

3

Hi Valentin,

thank you for your reply!
In our use case, we need to support sharing of some workflow definitions/instances/tasks between groups of tenants. So, default tenant wouldn’t fit here either, as, in this case, the definition is shared among all of them. And this is not quite what we want.
Is there any decent alternative in your opinion?

Thanks!

Best,
Vasil

4

Hi Vasil,
for the definitions you can specify with the tenant provider (see DefaultTenantProvider) and specify between which tenants you are sharing models. This allows you to restrict between which tenants you are sharing your models. You can do this for example by using a tenant naming pattern. For the instances/tasks there is as far as I know no alternative right now. Why do you need those shared?

Valentin

5

Hi Valentin,

thank you very much for the information. You are right, looks like we need to reconsider the use case.

Best regards,
Vasil