Tenant data isolation in multi-tenant Flowable

A query that omits the tenant condition returns rows from every tenant that shares the engine. The engine stores tenant IDs on its entities, but it does not decide which tenant a caller may see unless your code asks it to. Gaps usually sit in custom SQL, reporting jobs, read-only REST wrappers and service code that calls the query API without passing a tenant. The control is a tenant condition on every query your application issues, with the value taken from the authenticated session and never from a request parameter the caller can edit. Inventory every query path, including batch jobs and admin tools, and test each one with two tenants holding data side by side. Confirm with your own code review which paths touch engine tables directly.

Only if the engine keeps them apart by tenant, and your application confirms that for every lookup. Process definition keys are identifiers chosen by the model author, and two tenants can ship a model with the same key. If a start call or a lookup by key omits the tenant, the engine may return the wrong definition or a caller may start another tenant's process. Set the tenant ID on every deployment, then require the tenant in every start, lookup and instance query. Treat a tenant prefix in the key as a naming convention only, and rely on the tenant ID as the control. Ask your team to document which key and tenant pairs exist in production.

When tenants share candidate groups such as a generic managers or admins group, a user from one tenant can see and claim tasks routed to that group in another tenant. Group IDs are plain strings, so nothing ties a group to one tenant unless your design does. Map each tenant's identity provider groups into tenant-specific group IDs, then assign tasks only to those IDs. Check that task queries filter by both tenant and candidate group, and that complete and claim calls verify the caller's tenant before they act. Confirm with your identity team whether group membership can be granted across tenants, because that single setting can undo every other control.

Yes, if the event is matched only on a name or correlation key without a tenant condition. Signals are broadcast by name to every subscribed definition, and message correlation matches on business keys or correlation values that different tenants may reuse. Scope every signal and message to a tenant by including the tenant ID in the event name, the correlation key or both. Have the API that raises events set the tenant from the caller's session, and reject events that arrive without one. Keep a list of all event names in use, since a generic name such as orderUpdated is a common source of cross-tenant delivery. Test with matching keys in two tenants and confirm that only the intended instance resumes.

Historic tables and audit logs hold the same tenant data as runtime tables, and they often outlive the running instance. A reporting screen or support tool that reads history without a tenant condition can expose completed cases, variables and comments from other tenants. Historic variables may hold personal data, so the exposure extends beyond process status. Apply the tenant filter to every history query, audit export and log view, and restrict who can run them. Check whether support staff use shared dashboards that query across tenants, and whether retention jobs delete by tenant. Confirm which history levels you enable, because more detail means more data to protect.

Your application must enforce it. Flowable provides tenant IDs on its entities and lets you filter queries by them, but the engine does not decide which tenant each of your users may reach. Your API layer must derive the tenant from the verified identity, pass it to every engine call and reject requests where the tenant does not match the resource. Treat the engine's tenant fields as the storage model and your authorization layer as the policy. Ask your team to write tests that attempt cross-tenant reads and writes through every endpoint, including the REST API and any custom services. Review this design with your security team before the first tenant onboards.

Effort depends mainly on how many paths in your application touch process data. The engine stores tenant identifiers on runtime, history and task data, but your application must set, check and filter them on every route into the engine. Those routes include REST calls, scheduled jobs, signals, messages and reporting queries. A team with a small set of entry points and a clear identity model can limit the work to a few modules. A platform with many services, custom delegates and shared reporting jobs has more surfaces to review, test and document, so the work grows with each one. Ask for a list of every entry point before agreeing any estimate.

Cost is mostly people time, and the written scope shows who is paid for each part. These factors raise it:

• The number of REST endpoints, signal handlers and custom delegates that read or write tenant data
• How many identity sources feed tenant membership, such as the Flowable identity tables, LDAP or an external identity provider
• The volume and sensitivity of data per tenant, which sets how thorough the negative tests must be
• The state of existing process models, especially those without tenant-aware variables

The design and build are mostly one-time costs. Recurring effort appears when new tenants, models or integrations must be checked against the isolation rules. Ask for a quote that separates design, build, testing and handover, and that states what each later change will cost.

Yes, a team with Java, Spring and Flowable experience can build it, and the Flowable documentation covers the engine side of multi-tenant data. The harder part is usually the application: finding every path into the engine, deciding where tenant identity comes from, and proving that no path crosses a boundary. Internal teams often underestimate the negative testing and the review of jobs and queries that bypass the normal code path. Check the tenant features and their behavior in the documentation for your exact Flowable version before you design around them. A fixed-scope review of your design or test plan is one way to get an outside check without handing over the whole build.

No duration can be given here because it depends on your tenant count, entry points and test data. Verification has three layers. The first is automated tests that create at least two tenants and confirm that every read and write stays inside its tenant. The second is negative tests that try cross-tenant access through each REST endpoint, signal and message. The third is a review of queries, scheduled jobs and reporting code that bypasses the normal path. Each layer needs test data prepared in advance. Ask for the verification plan and its exit criteria in the written scope before you agree a timeline. Security testing of your APIs can run alongside this work as a separately scoped service.

The work needs three inputs before design begins. The first is your identity model: how users, groups and roles map to tenants, and whether identities live in Flowable's identity tables, LDAP or an external identity provider. The second is the tenant list, with the data class and business owner for each tenant. The third is test data: a non-production environment with at least two tenants and process models that resemble production. You should also provide the process models, custom delegates, integration list and any reporting queries, because those are where cross-tenant leaks usually hide. Confirm each input in writing so that the scope reflects what your environment really contains.

Not necessarily. A shared design keeps one engine and one database, with tenant identifiers on entities and enforcement in the application. Separate databases or schemas per tenant give stronger separation for some data, but they multiply the operational work. Deployments, upgrades, the async executor, backups and monitoring must be handled for each database. The right choice depends on your tenant count, the data classes involved and what your regulators and customers expect. Confirm the requirement with your data protection lead before you choose, because changing the model after go-live is expensive.

Tenant isolation most often fails at the edges of the engine rather than in the core process logic. The common failure points are:

• REST calls that take a tenant identifier from client input without checking it against the caller's rights
• Signals and messages broadcast without a tenant scope, so one tenant's event starts another tenant's process
• Timers and asynchronous jobs that run without the tenant context of the process that created them
• Custom delegates and expressions that read variables belonging to another tenant
• Reporting or administrative queries that run direct SQL and skip the tenant filter

Each point should have a test that tries to cross the boundary and fails.

No. Tenant isolation is one control among several. Auditors test whether access is restricted, whether changes are logged, and whether you can show evidence that the controls work over time. Tenant tests, access reviews, audit history and change records all support that evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask your auditor early which tenant separation evidence they will sample, so the test plan and logs produce it.