In our department, we are planning to expand the use of Flowable across several teams. Each team would manage its own set of processes, but there are also some common process models that need to be reused by multiple teams.
We’re currently evaluating two architectural options:
Using multiple tenants within the same Flowable instance, or
Running separate Flowable instances for each team.
Before we finalize the approach, I’d like to understand the recommended way to handle shared/common process models in these scenarios.
Specifically, I have these questions:
1. Multi-tenant scenario
If each team runs under a different tenant, is it possible for a process in Tenant A to call a process model deployed under Tenant B?
For example, can a Call Activity or any other BPMN mechanism start a process definition that belongs to another tenant?
2. Multi-instance scenario
If teams use completely separate Flowable instances, what is the proper way to trigger a process in one instance from another? Is REST API the only supported approach?
3. Best practice for shared models
If some processes are common to multiple teams, what is the recommended way to model and deploy them?
Deploy once without a tenant so all tenants can use them?
Duplicate the models under each tenant?
Or is there another preferred approach?
Any guidance, best practices, or architectural recommendations would be very helpful.
All of our engines actually have DefaultTenantProvider, which provides the default tenant for a particular definition key, scope type and tenant. The default implementation (when multi tenancy is enabled) is to use the tenant named default as a common / shared tenant.
What we actually do when you start a process instance by key, or you have a Call Activity like in your example is to first look for a definition deployed in the specific tenant (e.g. Tenant A), if we cannot find a definition, then we would look for a definition in the default tenant, or rather the tenant returned by the DefaultTenantProvider. We then use that definition to start a process instance, this process instance will still belong to Tenant A.
In this scenario, you would only be able to communicate using REST and / or some kind of messaging / event streaming communication.
This really depends on how you are doing the modeling. In our Enterprise Design application we also have this support for using a shared workspace (each team can have it’s own modeling workspace) and then when you deploy an app it will be deployed in that specific tenant. This way you can have different versions of the shared models, but each team will upgrade to their respective version on their own.
It really depends on your business use case and how your teams are working with each other. Feel free to send me a DM if you’d like more info.
We do have a section on Multi-tenancy in our documentation. It does use some enterprise properties, but I think it should be clear enough.
I had already looked into the fallback mechanism for process definitions and the default-tenant behavior. Unfortunately, that doesn’t fully solve our case, because we would only have one default tenant. Once more than two teams start using Flowable, all common models would need to be deployed under that default tenant, and then every team would have to keep those models in sync. That becomes hard to maintain in the long run.
Using REST calls would technically work, but the concern there is that—even though all teams are using the same product —the integration between teams starts to feel like calling an external third-party system rather than a remote call on a process definition.
I am a bit confused. You asked initially for an approach for how to handle shared / common process models. Now you are saying that this does not solve your case.
Are you saying that you want to share models between multiple tenants? If that is the case, is really multi tenancy the approach you are looking for, or is more around permissions and which applications can be invoked by which team. This way the data is in the same tenant and teams could have access to that data.
Concepts like this, especially when rolling out as a platform to multiple teams should take the modeling part into consideration. Perhaps you want to be able to use processes models (apps) from other teams during modeling. Then when you deploy an app, it creates a snapshot at that time and when you use same deployment, the process from that deployment would be used, if another team deploys a new version to that model, then it will inly be used without their app and the other app would use the version that was included in its deployment.
Hi @filiphr
Thanks again for the detailed explanation.
Yes, sharing models across teams is ultimately what we’re trying to achieve. My doubt is mainly around the best practice for doing this in a clean and maintainable way.
In the multi-tenant setup, my concern is the following (please correct me if I misunderstood anything):
If we have tenants A, B, and C (with C being the default/shared tenant), and Team A wants to use a model created by Team B, then my understanding is that the only practical approach would be to deploy the common models into the default tenant (C). That way both A and B can call it. But this also means all teams would have to manage and update shared models centrally in C, which might get tricky over time.
The second part about the deployment and snapshotting during modeling was a bit unclear to me, so I thought of DM you to avoid confusing the thread further but DM is not allowed to your profile i guess.
Yes indeed, in this case the model will need to be in C in order for A to be able to use it. In theory you could implement something with a custom DefaultTenantProvider where for a particular model for Tenant A you can use a model from Tenant B, etc.
From what you are explaining, I guess an option for you would be if you have Tenants A, B, C and D each one independent, the team in A can use models from B and C if they want to?
If that is the case then what you are explaining, to me it sounds more like every team is building their own App and they share the workspace (this is Flowable Design feature), in this case you can reuse models from different Apps if you want to.