Flowable embedded in SaaS products

Usually not as raw files in production. Direct upload gives a customer the ability to deploy any process definition the engine accepts, including script tasks and expressions that run code on your servers. A safer pattern is to accept customer changes through a constrained editor or form that produces a validated model, then run that model through your own checks before deployment. Decide this with your security team early, because it sets the attack surface for everything that follows. Confirm which definition formats your chosen Flowable version parses and which elements you intend to permit.

Treat every customer-supplied BPMN or DMN file as untrusted input. Validate the XML against a schema allowlist, reject external entity references and disallowed elements, and strip or block script tasks and expression languages you do not need. Confirm in the Flowable security documentation how scripting and XML parsing are configured in your version, and test these controls with deliberately malicious samples in a non-production environment. Your review should also cover how definitions are stored, who can deploy them, and whether a rejected model leaves an audit record.

Expose a fixed set of configurable parameters rather than the model itself. Typical examples are form field labels, approval thresholds, due-date offsets and values in a decision table, with the process structure and hit policies owned by your team. Store these values as tenant-scoped data that the process reads through variables or decision inputs, and validate each value against a defined type and range before saving. This keeps customer changes reviewable and limits what a faulty edit can break. Ask your product team which parameters are safe to change without a regression run.

Authorization is your application's job, not the engine's. Flowable checks identity and task assignment, but the rules that decide whether a tenant administrator can publish a decision table or edit a threshold must live in your service layer. Map tenant roles to permitted configuration actions, enforce those checks on every REST call and background job, and record who changed what and when. Confirm how your identity service supplies user and group data for each tenant, since the Flowable docs describe replacing the identity service with your own implementation.

Tie every process definition, deployment, decision and variable to a tenant identifier, and make the tenant boundary part of every query and API call. Flowable supports tenant IDs on definitions and runtime data, but you must verify that every custom delegate, listener and report also filters by tenant. Test with at least two tenants that have overlapping process keys, and confirm that a deployment for one tenant cannot change the running version for another. Shared engine resources such as the async executor also need review, since a noisy tenant can affect timing for everyone.

Plan for each tenant to run a pinned version of its process definitions while you release changes. Changing a definition for one customer should create a new version only for that tenant, and running instances should keep the version they started with unless you migrate them deliberately. Decide how long old versions are kept, how instances are moved between versions, and how a rollback is handled. The Flowable features documentation covers moving running instances between versions, and you should confirm that behavior against your chosen release before committing to a design.

Cost depends on how much of the modeling experience you expose. A form-based configuration layer with validation and tenant scoping is a bounded build, while a model editor with full BPMN or DMN validation adds ongoing work for parser upgrades and security review. One-time costs include the validation layer, tenant isolation tests and the authorization model. Recurring costs include security testing after each Flowable upgrade and support for customer-visible changes. Ask any partner for a written scope that separates these items and states which upgrades and tests are covered.

Cost follows the written scope, and the largest drivers are how many tenant-facing features you expose, how much customer-facing modeling you allow, and how many integrations the engines must reach. Your team pays for internal design time and ongoing ownership of the engines, while a partner is paid for the work you agree in writing. Ask any quote to separate one-time work (tenant model, identity mapping, the first delegates and tests) from recurring work (upgrades, monitoring, support). Flowable open source is Apache 2.0 licensed, so the software itself carries no license fee, but commercial Flowable products are a separate decision with their own terms.

Duration depends on scope rather than on Flowable alone. A narrow build that runs one standard process per tenant with a fixed set of delegates moves much faster than one that lets customers design their own cases, decisions and versioned processes. Timing is also shaped by identity integration, the number of supported databases and how many environments and test tenants you need. No fixed duration applies across products, so ask for a timeline tied to named deliverables in the written scope, and confirm which items depend on your own teams, such as access to identity systems or approval of the tenant model.

Yes, a capable Java team can build on Flowable directly, since the engines are compact, expose Java and REST APIs, and can run inside Spring applications. The harder parts are design decisions that are costly to reverse: how tenant IDs flow through process and case data, how per-customer process versions are deployed and retired, and how the async executor scales across nodes. Teams that do this alone usually need someone who has already run multi-tenant workflow engines in production to review those choices. A partner can take on part of that work, and the split between your team and ours should be written into the scope.

Expect to supply decisions and access, not only code. The main inputs are your tenant model (shared schema or isolated databases, and how tenant IDs are stored in process variables), a mapping from your identity provider to Flowable's identity services, and a set of test tenants that reflect real customer configurations. You also need to name the people who approve process changes for customers and who own the release pipeline that deploys process definitions. Confirm these inputs with your own architects early, because each one changes the build sequence and the testing effort.

Identity is where many embedded engines fail, so it deserves its own scope item. Flowable's identity management can be replaced by overriding its identity service implementation or by implementing the identity service interface, and an LDAP reference implementation is provided. Your mapping must make sure a user in one tenant can never see tasks, variables or history from another, which the engine does not enforce for you. Add authorization checks in your application layer, test them with at least two test tenants, and review them as part of your security testing.

No. Flowable's open source engines for BPMN, CMMN, DMN and the event registry are licensed under Apache 2.0 and can be embedded as a JAR, in Spring applications or behind the REST application. Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. Choose them only if your customers need those capabilities in a ready-made form. Open source users receive a community forum, while professional services and partners are offered separately, so budget any production support you need from them.

Engines usually strain in the async executor, the history volume and the database rather than in the process models themselves. The async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so a poorly sized pool or an unexpected lock pattern can slow every tenant at once. Plan monitoring from the start using the Spring Boot actuator endpoint for running processes, and confirm the database type and version you will run in production against the supported list in the configuration docs.

Letting customers change processes, decisions or cases increases risk in three places: scripts and expressions that customers can write, versioning of definitions that already have running instances, and authorization for who may deploy a change. Restrict what customers can edit to a defined configuration surface, validate every change before deployment, and keep a record of who approved each version. Confirm with your security team how Flowable's scripting and XML risks are controlled in your configuration before you open any editing feature to customers.