When the free Flowable engines are enough and when the enterprise platform is needed
If your Java team wants BPMN, CMMN and DMN running inside its own services, the free Flowable engines are usually the right starting point. The open-source engines are licensed under Apache-2.0, support the BPMN, CMMN and DMN standards, and cover process execution, case management and decision rules. They can be embedded in a Java application or run as a service, and they expose Java and REST APIs. Your developers write the process models, wire them into existing code, and own the deployment, database and upgrade path. Before committing, confirm which Flowable release line fits your stack, since Flowable 8.0.0 (released February 27, 2026) is built on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support.
The enterprise platform becomes necessary when business users must model, monitor and govern processes and AI agents without writing custom code. Flowable describes its commercial products as built on the same engines and adding drag-and-drop low-code modeling, a Control dashboard for runtime engines, enterprise content management, and governance of AI agents with policy control and an audit trail. If your process owners need to change flows themselves, or your compliance team needs centralized visibility across many engines, the platform addresses that gap, while the open-source engines leave it to your own tooling.
Be aware that the platform is sold by subscription and Flowable does not publish a price list. Ask for a written quote that separates the subscription, the support tier, any hosted Enterprise Cloud option on Microsoft Azure, and the professional services needed for your rollout. Ask which of these recur annually and which are one-time. Also confirm whether the Enterprise Cloud SSO through OAuth and SAML meets your identity requirements, and whether the Flowable open-source Identity Management interface can be replaced with your own directory service.
Which capabilities sit in the open source engines and which in the enterprise platform
This table separates what the Apache-2.0 Flowable engines provide from what Flowable's commercial platform adds, as listed on Flowable's open source page. Read the enterprise-only column as the vendor's own positioning, and confirm any item the vendor does not explicitly place in one tier before you plan around it. The main takeaway is that the engines cover process, case and decision execution for developers, while low-code design, monitoring, content management and agent governance are described as enterprise capabilities.
| Capability | Open source engines | Enterprise platform |
|---|---|---|
| BPMN, CMMN and DMN execution | true | true |
| Java and REST APIs | true | Not stated separately; confirm with Flowable |
| Spring Boot starters and actuator endpoint | true | Not stated separately; confirm with Flowable |
| Drag-and-drop modeling with visual expression builders | Flowable Design available free in the cloud for modeling | Listed as enterprise platform capability |
| Control dashboard for runtime engines and reports | false | Listed as enterprise platform capability |
| Enterprise content management for documents | false | Listed as enterprise platform capability |
| SSO through OAuth and SAML | Confirm with Flowable; identity service is replaceable in code | Listed for Enterprise Cloud; confirm for self-managed platform |
| Agentic Case Platform policy control and audit trail | false | Listed as enterprise runtime capability |
How licensing, support and updates differ between the two editions
The open-source engines and the commercial Flowable platform share one engine core, but they differ in who supports you, what you pay for, and who carries upgrade work. The cards below separate those terms so you can ask the right questions before committing to either path.
Engines under Apache 2.0
The core BPMN, CMMN and DMN engines are Apache-2.0 licensed, so you can embed them in your own Java services without a license fee for the engine itself. Community support runs through a forum, not a contractual service level. If your team expects a named escalation path, you will need either an internal owner or a separate professional services agreement. Confirm the Apache-2.0 terms against the repository's license file for the exact version you plan to use.
Commercial subscription from development to production
Flowable's commercial offering is a subscription that covers support from development through production, and the platform products are sold on top of the same engines. You pay a recurring fee for that coverage, and the fee scales with the products and deployment model you choose. Ask Flowable what the subscription includes, who answers tickets, and whether it covers production incidents after hours.
Spring Boot 4 requirement for version 8
Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4, and it drops Spring Boot 3 support with no backward compatibility. Any team on Spring Boot 3 must plan an application upgrade before adopting version 8, whether it runs the open-source engines or the commercial platform. Budget the testing of your own services against Jackson 3 and the removed JUnit 3 and 4 support.
Who applies patches and upgrades
On the open-source path, your team or your implementation partner decides when to move to a new engine release and tests the change in your application. On the enterprise cloud, Flowable handles upgrades, patches and maintenance as part of the service. Confirm in writing how often each path receives updates, how security fixes are delivered, and how much notice you get before a change that affects your deployment.
Support scope and service levels in writing
Support scope, response targets and upgrade terms should appear in the subscription or support agreement, not only on a marketing page. Ask which Flowable versions are covered, whether custom code and your own integrations are in scope, and what happens to coverage when a version reaches end of life. Fixed-scope work from an implementation partner should also name what is delivered and when, so the two agreements do not overlap.
Plan for the cost of switching later
Moving from the open-source engines to the commercial platform, or the reverse, changes your licensing and support position but usually keeps your process models on the same standards. Before you sign, ask how exit terms work, whether subscription pricing changes at renewal, and what Flowable's documented migration path requires for your version. Note that Flowable 7.0.0 removed the UI applications and several engines, so older deployments may already need rework.
What the open source engines give your Java developers
The Flowable open source engines give your Java developers the BPMN, CMMN and DMN engines as libraries they control, and the choice of deployment shape comes first. The engines can be embedded as a JAR in a Java SE application, in a servlet container such as Tomcat or Jetty, inside a Spring application, or on a Java EE server. Alternatively, teams can run the Flowable REST application and let other systems call the engines over HTTP. Embedding keeps the process runtime inside a service your team already deploys and monitors, while the REST application suits several consumers sharing one engine. Decide which model fits before anything else, because the Spring Boot starters and the REST application shape the rest of the build. The Flowable getting started guide and the Flowable Spring Boot documentation describe the starters for each engine and for REST.
Database choice is a contract with your DBA team. The configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and note that MySQL versions below 5.6.4 lack millisecond precision. Confirm the exact version matrix for your target database and driver before you commit, since the docs are the authority on that point. Clustering is handled by the async executor, which runs timers and asynchronous jobs from a thread pool. Nodes coordinate through lock owners and lock expiration times stored in the database, so when a node fails its expired locks are recovered and other nodes pick up the jobs. Your platform team must size the database, monitor lock contention and own backups and schema upgrades, which Flowable does not perform for a self-hosted engine.
Identity is the part most teams underestimate. Flowable's docs state that identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Your team must map users, groups and roles from your directory into that service and test task assignment against real org structures. Monitoring is also yours to assemble: the Spring Boot starter exposes an actuator endpoint at /actuator/flowable for running processes, but dashboards, alerting and audit reporting are built by your team. Process modeling is likewise a build decision, since the open source engines do not include the drag-and-drop designer, visual expression builders or content management that the commercial platform lists. Estimate these components with your own developers before comparing against a subscription quote.
When the enterprise platform changes the work for each team
Process owners who model and change workflows without writing Java depend on modeling tools more than on the engine. The open-source Flowable engines execute BPMN, CMMN and DMN models and expose Java and REST APIs, but the drag-and-drop low-code modeling, visual expression builders and visual debugging described for Flowable's commercial products are aimed at people who are not developers. Flowable's open source page also invites users to model in the cloud with Flowable Design at no charge, so a team can test modeling before deciding anything about licensing.
- Model ownership: The paid platform matters when analysts, not developers, must publish and revise process models on a regular cycle.
- Visual debugging: Stepping through a running instance in a visual tool saves developer time when business users need to see where a case stopped.
- Expression building: Visual expression builders reduce hand-written expressions in gateways and forms, which lowers the review load on engineers.
- Engines alone suffice: If developers own every change and models change a few times a year, the engines and the free modeling tool may cover the need.
- Confirm scope: Ask Flowable which modeling and debugging features are in each commercial product and whether they run against your existing engine version.
Before committing, check how many people will model processes, how often models change and whether your engineers want those changes in version control.
Operations teams need to know whether engines are healthy, which instances are stuck and whether jobs are being processed across nodes. The open-source engines give you the raw signals: the Spring Boot starters provide an actuator endpoint at /actuator/flowable for monitoring running processes, and the async executor coordinates timers and jobs across nodes through lock owners and expiration times stored in the database. The Control dashboard in the enterprise platform is the packaged layer on top, used to monitor runtime engines and download reports without building that view yourself.
- Central monitoring: The Control dashboard matters when several engine deployments must be watched from one place by staff who do not read actuator output.
- Report exports: Downloadable reports help when operations must share runtime figures with management or auditors on a schedule.
- Actuator and metrics: Teams with an existing monitoring stack can often scrape the actuator endpoint and build their own alerts, which keeps the engines sufficient.
- Async job recovery: Expired locks are recovered and picked up by other nodes in the open-source executor, so clustering alone does not require a paid tool.
- Confirm the gap: Ask what the Control dashboard shows that your current monitoring cannot, and test it on a non-production cluster first.
Document how stuck jobs are found today, because that baseline shows whether the dashboard closes a real gap.
Case work in insurance claims, licensing or public benefits often depends on documents, scanned forms and attachments that move with the process. The open-source engines handle CMMN case management and process state, but they do not provide document storage. Flowable's open source page lists enterprise content management for documents and unstructured data as a capability of the commercial platform. The question is whether documents already live in a system of record that the process can reference, or whether the process must own them.
- Document ownership: Enterprise content management matters when the case must hold its own documents with versions and access rules inside the workflow platform.
- Existing repositories: If a document management system already stores files and your services can link to them, the engines plus integration code may be enough.
- Unstructured data: Case folders with mixed content types are a stronger reason for the paid option than a single structured form.
- Compliance evidence: Retention and access requirements for case documents should be defined before choosing, since they shape where files live.
- Confirm the integration: Ask Flowable how its content management connects to your current repository, and what it costs to keep both running.
Map which documents a case needs, who reads them and how long they must be kept before comparing the two options.
Governance teams need to show who approved a decision, which policy applied and what an automated or AI agent did at each step. The Flowable Agentic Case Platform, described on Flowable's open source page as the enterprise runtime built on the open-source engines, governs AI agents, people and processes on the same BPMN, CMMN and DMN standards, with policy control and an audit trail on every action. The engines record process history and support identity replacement through a custom identity service, but agent policy control and action-level audit are part of the commercial runtime.
- Agent policy control: The paid runtime matters when AI agents take actions inside regulated processes and each action needs a policy check.
- Action-level audit trail: Teams that must prove what each agent did, not only what the process state was, need the commercial audit layer.
- Human and agent steps: Mixed processes where people and agents share tasks benefit from one governance model across both.
- Engines alone suffice: If no AI agents act in your processes, the engines' history and your own logging may meet current review needs.
- Confirm before relying on it: Ask Flowable for the audit fields it records, how long they are retained and whether they can be exported to your SIEM.
Write down which decisions require evidence today, then test whether the open-source history alone can answer an auditor's questions.
How Flowable Enterprise Cloud is delivered and what it hands to Flowable
Flowable Enterprise Cloud runs on Microsoft Azure with Kubernetes, and the first decision is which tenancy model fits your data. Flowable describes shared multi-tenant and dedicated environments, with EU and US regions as standard. Shared tenancy is the cheaper starting point for many teams, but you should ask Flowable how tenants are isolated at the database, network and key-management layers, and whether a dedicated environment changes the region or the upgrade schedule. Confirm in writing which region will hold your process data, history, documents and logs, and whether backups and support access cross regions. Also confirm the exit terms: how you export process definitions, runtime data and history if you leave, and in what format.
Identity is the second decision. Flowable lists SSO through OAuth and SAML, so check which identity provider you will federate with, which claims or attributes Flowable maps to users and groups, and who administers those mappings. Flowable's open source documentation also describes replacing the identity service with a custom implementation or an LDAP reference. That option is for self-hosted engines, so do not assume it applies to the cloud service. Ask Flowable which integration points, such as REST APIs, webhooks or event feeds, your systems can use, and whether any of them carry extra charges or limits.
Flowable's Enterprise Cloud page lists ISO 27001 and SOC 2 and says Flowable handles upgrades, patches and maintenance. Treat both as vendor claims until you have checked them. Request the current ISO 27001 certificate and its scope statement, and the most recent SOC 2 report, including the period it covers and any exceptions. Read the scope to see whether your deployment model and regions are included. Ask for Flowable's patch and upgrade calendar, the notice period before maintenance, and how you can test a new version before production moves. Those answers define how much of your change control and vulnerability management Flowable takes over, and how much stays with your team.
What you pay for in each edition and what drives the total
This table sets out who is paid for what on the open source engine path and the Flowable subscription path, and which parts are one-time or recurring. Flowable publishes no price list, so use the quote inputs in the final rows to compare like for like.
| Cost component | Open source engines | Flowable enterprise platform |
|---|---|---|
| Software licence | No licence fee. Flowable engines are Apache-2.0 licensed, so the license cost is zero. | Subscription fee for the commercial platform, which Flowable describes as a subscription covering support from development through production. |
| Developer and integration time | Your Java or Spring teams embed the engines, build services, and write their own forms, monitoring and identity glue. This is usually the largest recurring cost. | Lower build effort for low-code modeling, visual debugging and the Control dashboard, but integration into your services still needs your developers. |
| Database and hosting | You pay for the database (H2, MySQL, Oracle, PostgreSQL, DB2 or SQL Server are documented), servers or containers, backups and high availability. | Deployment model decides this. Flowable Enterprise Cloud runs on Microsoft Azure with shared or dedicated environments, so confirm who pays for hosting in the quote. |
| Identity integration | You implement your own identity service by overriding the IdmIdentityService or using the documented LDAP reference implementation. | Confirm which SSO options are included. Flowable Enterprise Cloud lists SSO through OAuth and SAML. |
| Monitoring and operations | You wire monitoring yourself, for example through the Spring Boot actuator endpoint at /actuator/flowable, and build your own reports. | Control dashboard and monitoring are part of the enterprise capability set. Confirm which runtime engines and reports the subscription covers. |
| Upgrades and maintenance | Your team plans and tests upgrades, including the move to Flowable 8.0.0 on Spring Framework 7 and Spring Boot 4, which drops Spring Boot 3 support. | On Enterprise Cloud, Flowable handles upgrades, patches and maintenance. For self-managed subscriptions, confirm the upgrade and patch terms in writing. |
| Implementation and professional services | Optional. Professional services and partners are offered separately, and DeployOpen can scope fixed-price work in writing. | Implementation is often bundled with the subscription path. Ask Flowable what is included and what remains a separate statement of work. |
| Quote inputs to request | Scope of embedded services, number of environments, database choice, identity approach and the support level you need. | Scope, edition, environment (shared or dedicated, Azure region), EU or US region, identity options and support level. Flowable publishes no price list. |
Moving from the free engines to the enterprise platform, or back
This sequence shows how a team can prototype on the Apache-2.0 Flowable engines, test the commercial platform on the same standards, and choose a delivery model before moving process models and governance. It also flags what a return to the engines alone would require reviewing.
Prototype one process on the open source engines
A Java or platform engineering team embeds the Flowable engines in a test service, or runs the REST application, and deploys one representative BPMN process with a DMN decision table and, where needed, a CMMN case. Use the Spring Boot starters or the getting started guide to confirm the engine starts against your target database. The step is done when the team can start, complete and query an instance through the Java or REST API and has recorded which database and Spring Boot version it tested against.
Define the process and case model in version control
Architects and process owners store the BPMN, CMMN and DMN files in the same repository as the services that call them, with ownership of each model assigned. Treat models as code so changes go through review. The output is a versioned model set with a short list of which services start, signal or decide on each process, so the later migration has a fixed reference.
Evaluate Flowable Design and the Agentic Case Platform trial
Business analysts and the platform owner use Flowable Design, which Flowable describes as free to model in the cloud, to draw the same models visually and check they round-trip to the standards. The 30-day free trial of the Agentic Case Platform then lets the team test low-code design, the Control dashboard and policy and audit features on that model set. Ask Flowable to confirm trial terms and which features the trial includes. The step closes when a written list of gaps between the open source model and the platform features is agreed.
Decide on self-hosted or cloud delivery
The platform owner, security lead and procurement compare the subscription options. Flowable Enterprise Cloud runs on Microsoft Azure with Kubernetes in shared or dedicated environments, with EU and US regions as standard, and Flowable handles upgrades and patches. Self-hosting the commercial platform keeps data in your own infrastructure but leaves operations with your team. Confirm the data residency, certifications and support terms in writing. The decision is recorded with the reasons and the quote matched to the agreed scope.
Map identity, storage and async jobs to the target
Engineers check how the chosen delivery model handles user identity, since the engines allow identity management to be replaced through the IdmIdentityService interface, and confirm SSO through OAuth and SAML where the cloud option is used. They also confirm the database and the async executor's lock settings for a multi-node deployment. The output is a target architecture diagram and a test that shows jobs recovered from an expired lock on a second node.
Migrate models and governance in a controlled cutover
The team moves the model set and any custom code into the enterprise platform, or keeps it in the engines, and reruns the prototype tests against the new environment. Governance settings such as policy control and audit trails are configured and checked against the audit requirements of the team. Record every change in the model inventory. The step is done when the same test instances complete in both environments and the audit log captures each action.
Review custom features before any move back to the engines
If the team later returns to the engines alone, it must review every feature that depends on the enterprise layer, including low-code forms, visual debugging, monitoring dashboards, content management and agent governance, and decide whether to rebuild or drop each one. Ask the vendor which enterprise components the open source engines do not include. The output is a written inventory of dependencies, rebuild effort and owners, approved before any licence change.
Questions buyers ask before choosing Flowable's free or paid edition
What does a Flowable subscription cost?
Flowable does not publish a price list, so the subscription cost cannot be stated from public information. Flowable sells its commercial offering as a subscription that includes support services from development through production, according to its support page. The figure depends on which products you license (such as the Agentic Case Platform or the Enterprise Cloud option), the deployment model, the number of environments and the support level. Ask Flowable for a written quote that lists each product, environment and support tier separately, and confirm whether the price recurs annually and what is included in upgrades. The open-source engines themselves carry no license fee under Apache-2.0, but your own build, hosting and staffing costs still apply.
Can a small team run the open-source Flowable engines on its own?
Yes, a small team can embed the Apache-2.0 engines in a Java application, provided it has people who can own the Java build, the database and the release process. The engines support BPMN, CMMN and DMN, run embedded in a Java application or as a service, and expose Java and REST APIs. The open-source path gives you a community forum, but professional services and partners are offered separately. Before committing, confirm that your team can handle the features you need without the enterprise low-code design, monitoring dashboard and content management that come with the commercial platform.
How long does an embedded Flowable implementation take?
The timeline depends on the number of processes, the integrations with existing systems, the identity source and the database you choose. No duration is published for Flowable projects, so treat any figure you see as something to verify against your own scope. Schedule time for the parts that usually take the longest: modeling each BPMN, CMMN or DMN artifact, wiring Java services and REST calls, connecting identity, configuring the database and load testing the async executor. Ask for a written plan with milestones, and make sure it names which engine version you target. Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4, so version choice affects the work.
What skills do Java and operations staff need for Flowable?
Your Java developers need to be comfortable with the Flowable APIs and, if you use Spring, with Spring Boot starters and actuator endpoints. Operations staff need to run the chosen database (H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server, per the configuration docs), manage upgrades and watch the async executor, which coordinates nodes through lock owners and lock expiration times stored in the database. Identity integration requires writing or adapting an identity service, with an LDAP reference implementation provided. Check your team's experience with BPMN modeling and with Spring Boot 4 if you plan to target Flowable 8.0.0.
Does the Flowable free trial cover production use?
No, the free trial should be treated as an evaluation, not a production license. Flowable offers a 30-day free trial of the Agentic Case Platform, and it invites users to model in the cloud with Flowable Design for free, according to its open-source and Enterprise Cloud pages. Confirm in writing what the trial includes, which environments it covers, what happens to your data at the end and what license applies after the trial. Ask whether a production subscription is required before go-live and how it is billed.
Does Flowable Enterprise Cloud remove upgrade work?
Flowable Enterprise Cloud runs on Microsoft Azure with Kubernetes, and Flowable handles upgrades, patches and maintenance, according to its Enterprise Cloud page. That reduces the platform work you carry, but it does not remove the work on your side. You still need to test your processes, forms and integrations against each release, and you need to decide which environment fits your data residency needs. The page lists shared multi-tenant and dedicated environments with EU and US regions as standard, plus SSO through OAuth and SAML. Ask which upgrades are applied automatically, how you are notified, and how your custom Java extensions are handled.
When should we hire outside help for Flowable scoping or integration?
Hire outside help when the scope is large, when you need to integrate with several systems at once, or when your team lacks BPMN, Spring Boot or database operations experience. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any implementation partner to define the processes in scope, the identity model, the database choice, the upgrade approach and who owns the code after handover.
How DeployOpen scopes Flowable work on either edition
Whichever Flowable path you take, the work splits into the same parts: planning, building, hardening, running and documenting the platform inside your own infrastructure. DeployOpen agrees that scope in writing before work starts, then offers retainers for what comes after go-live.
Fixed-scope written agreements
Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For Flowable, that means naming which engines are in play (BPMN, CMMN, DMN or the event registry), whether they are embedded in your Java services or run through the REST application, and which Flowable products, if any, are included. Ask for the written scope to list each of these explicitly, since the open-source engines and the enterprise platform imply very different deliverables.
Planning and embedding the engines
Planning covers where the engines run, whether embedded as a JAR in Spring or servlet applications or called over HTTP, and how the async executor coordinates nodes through lock owners and lock expiration stored in the database. Implementation then wires the engine into your build and deployment pipeline. Confirm in the scope which database types you need, since Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server.
Identity integration and custom services
Flowable's docs describe replacing identity management by overriding the IDM identity service or implementing its interface, with an LDAP reference implementation. DeployOpen can scope that integration against your directory and role model. Ask whether the scope covers the identity service only, or also the user task assignment rules and the security configuration of the REST application, since those carry most of the access risk.
Hardening and upgrade planning
Major Flowable versions can change the platform underneath your code. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and changed the default JSON library to Jackson 3. Scope upgrade testing, dependency review and hardening as separate line items, so a framework jump does not land on your team without a plan.
Backup, recovery and documentation
Because process state, history and timers live in the database, backup and recovery design centers on that database and on restore testing, not only on application files. Documentation should cover the deployment topology, database configuration, lock and timer behavior, and runbooks. Ask that the written scope name the backup targets, the restore test frequency and the documents you will own at handover.
Retainers and boundaries
Ongoing support, upgrades and continuous testing are available as retainers, which is the usual route after a fixed-scope build. DeployOpen is not a Flowable partner or reseller, and it does not publish prices, so a quote follows from the written scope. If you are weighing Flowable's subscription or Enterprise Cloud, DeployOpen can scope the self-hosted work alongside that decision, but Flowable delivers its own commercial products and support.
How DeployOpen supports either Flowable edition
DeployOpen scopes both paths the same way: a written, fixed-scope statement of work that names the components, environments and deliverables before any work starts. On the free-engine path, the scope covers the Apache-2.0 BPMN, CMMN and DMN engines embedded in your own Java or Spring Boot services, the database choice from the supported list (H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server), the identity service you will implement, the async executor settings for clustered nodes, and the upgrade path onto the Spring Boot 4 line used by Flowable 8.0.0. On the enterprise path, the scope adds the Flowable Agentic Case Platform or other commercial products, the Enterprise Cloud or self-hosted deployment model, SSO configuration and the operating model for administrators. Ask for the scope in writing to name which Flowable subscription, product and hosting option each deliverable depends on.
DeployOpen can deliver planning, integration with your identity provider and data stores, security testing of the resulting application and APIs, preparation of compliance evidence such as configuration baselines, access reviews and change records, and documentation for operators and developers. Security testing covers the process engine REST endpoints if you expose them, and the actuator endpoint at /actuator/flowable if you enable it. Confirm with Flowable, in writing, which controls and certifications apply to the vendor-hosted service, since those reports belong to Flowable, not to DeployOpen.
DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies produce those, and DeployOpen prepares the systems and evidence they will examine. Treat any claim that a Flowable build or Flowable Enterprise Cloud is already certified as a question to verify against the vendor's own documentation. To move forward, send your environment details, the Flowable edition you are evaluating and the outcomes you need, and request a quote tied to a written scope. DeployOpen does not publish a price list, so the quote follows from that scope.
