Why embedding BPM in a SaaS product is a different job
An Apache-2.0 engine can be embedded in your product as a library, but the license is the easy part. Flowable and Operaton both ship under Apache-2.0 and can run inside a Java application, which means the engine is not the constraint. What the vendor owns is everything around it: tenant isolation so one customer's process definitions, running instances, task lists and history never surface in another tenant, safe editing so customers can change models without breaking live cases, and redistribution terms that must be checked for every component in the stack. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so it cannot be treated as a free embedded option for a product that serves paying customers. Modified licenses such as Dify's, which requires a commercial license to operate a multi-tenant service from the source code, show why the license of each dependency needs a line-by-line review by someone who understands hosting.
Tenant isolation in an embedded engine is a design decision, not a default setting. Decide early whether tenants share one database schema with a tenant identifier on every row, or whether each tenant gets its own schema or database, and test how the async executor, timers and deployment of BPMN and DMN models behave across tenants. Customer-editable models need guardrails: restrict which BPMN elements, service tasks and expressions a customer may use, validate models before deployment, and keep versioning so a running instance continues on the definition it started with. Confirm with the engine vendor or community which identity hooks you must replace, because the Flowable docs describe replacing identity management through its IdmIdentityService interface, which is where tenant-scoped user and group resolution would live.
Which requirements a SaaS vendor must meet before embedding a BPM engine
This table lists the requirements a software vendor should settle before embedding a BPM engine in its product, with the source behind each one and what it means for the build. Read each row as a design decision to make early, since licensing, tenant boundaries and customer contract terms are hard to change after customers are live. The main takeaway is that the engine choice follows from the licence terms for redistribution and hosting, and the rest of the build depends on it.
| Requirement | Source | What it means for the build |
|---|---|---|
| License terms for redistribution and hosting | Flowable and Operaton are Apache-2.0; Camunda 8 source is under the Camunda License 1.0 | Confirm in writing that the chosen engine licence permits embedding and distributing it inside your product. Camunda 8 source use is limited to non-production environments without a commercial licence, so it cannot be the base for a production SaaS build without a separate agreement. |
| Tenant isolation of process definitions | Flowable and Operaton engine documentation on database and deployment configuration | Decide whether tenants share one engine and database with tenant-scoped data, or receive separate schemas or deployments. Test that one tenant cannot list, start or read another tenant's definitions, instances or tasks. |
| Tenant isolation of tasks and variables | Process variables and task data stored in the engine database | Process variables often contain personal or business data. Map which variables are stored, who can read them through the API, and whether they are encrypted or masked in logs and history. |
| Customer model editing with validation and versioning | Engine deployment model for BPMN and DMN definitions | Customers editing models need a validation step before deployment, a version history, and a rollback path. Plan a restricted modeling surface, since an unchecked BPMN change can stall running work. |
| Running instance migration across versions | Engine upgrade behavior, including Flowable 8.0.0 changes to Spring Boot 4 and Operaton's half-yearly release cadence | Plan how instances started on one model version continue after an engine or model upgrade. Ask the engine vendor or community how migration is supported and test it on production-like data before each release. |
| Async jobs and clustering behavior | Flowable advanced documentation on the async executor and lock expiration in the database | Timers and asynchronous jobs are coordinated across nodes through database locks. Test node failure, lock recovery and scaling under each tenant's load, and monitor the job executor from the start. |
| Customer contract and processor terms | GDPR Article 28(3) on documented instructions and Article 32 security measures | Your customer agreement must bind you to process personal data only on documented instructions and to apply the security measures required by Article 32. Confirm sub-processors and hosting locations with counsel. |
| Switching and data portability obligations | EU Data Act, Regulation (EU) 2023/2854, Articles 23, 25 and 50, and Article 29 | Customers may need to move to another provider or to on-premises infrastructure with a short notice period. Build export of definitions, instances and history in a documented format, and confirm the switching charge rules that apply from 12 January 2027. |
Flowable or Operaton: which engine fits which product roadmap
Vendors that need case handling alongside process flows, and decision tables for configurable rules, usually start with Flowable. Flowable open source provides Java engines for BPMN process execution, CMMN case management and DMN decision rules, with Java and REST APIs, licensed under Apache 2.0. The engine can be embedded as a JAR in Java SE applications, servlet containers, Spring applications or Java EE servers, or called over HTTP through the Flowable REST application.
- Engine coverage: BPMN, CMMN and DMN run on the same codebase, so a case-driven workflow and its rule tables can share one persistence and audit model.
- Spring Boot 4 requirement: Flowable 8.0.0, published on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3.
- Actuator monitoring: The Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes.
- Identity hooks: Identity management can be replaced by implementing the IdmIdentityService interface, which lets a product map its own tenant and user model onto the engine.
- Commercial add-ons: Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines, so a later move to a commercial editor does not require a different runtime.
Confirm before committing that the target Spring Boot and Java baseline matches your existing stack, since Flowable 8.0.0 is not compatible with Spring Boot 3 applications.
Vendors that already run Camunda 7 processes in their product need an engine that keeps the existing API, database schema and deployed models. Operaton is an Apache-2.0 BPMN 2.0 engine born from the Camunda 7 codebase. Its repository states a fully compatible REST API, database schema and deployable BPMN and DMN models, and it offers an OpenRewrite recipe for migrating from Camunda 7.
- Compatibility baseline: Operaton 2.1 is feature complete and API-compatible with Camunda 7 CE 7.24, and it keeps database schema version 7.24.
- Platform requirements: The 2.1 release requires Java 17 and is tested on Java 17, 21 and 25, with minimum database versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4.
- Stack versions: Operaton 2.1 is based on Spring Boot 4.0.6 and Spring Framework 7.0.7, with Tomcat and WildFly distributions and a Quarkus extension.
- Release cadence: Operaton ships half-yearly feature releases in April and October with monthly patch releases, and each version is supported for 6 months until the next one ships, with no traditional LTS line. Plan upgrades accordingly.
- Governance: The FAQ states that no single company controls the project and that governance is still forming, which changes how you assess long-term support.
Confirm with the engine maintainers and your own test suite whether every Camunda 7 extension your product uses is covered by the compatibility statement.
Some vendors want the runtime in their product now and a visual modeling or governance layer for customers later. The choice here depends on whether the editor will be sold or built, and on how the engine's commercial path is structured. Flowable's commercial products are built on the same engines as its open source distribution, which means models and runtime code written for the open source engine carry forward. Operaton has no open-core model and no commercial editions, and professional support is offered by several independent service providers.
- Same runtime path: Flowable's commercial editor and governance products add low-code modeling, visual debugging, security controls and monitoring on the same engines.
- Open source support model: Open source users get a community forum, with professional services and partners offered separately, so a support contract is a separate line item.
- No vendor editor: Operaton's repository describes no commercial editions, so a customer-facing editor would be built or sourced from a third party.
- Customer model editing: Letting customers edit models safely requires versioning, validation and permission checks in your own product, whichever engine you choose.
- Redistribution terms: Confirm the licence terms that apply to any commercial component you plan to bundle before you commit to a roadmap.
Ask each vendor in writing which parts of the editor are covered by their licence and which are your own code.
Platforms that fit a SaaS embedding and why
Embedding workflow inside a product means choosing an engine you can ship, upgrade and redistribute under its license terms. The cards below cover the engines and adjacent tools that come up most often, and the license or support question that decides each one.
Flowable open source engine
Flowable provides BPMN process execution, CMMN case management and DMN decision rules as compact Java engines with Java and REST APIs. It can be embedded as a JAR in a Spring or servlet application, and the Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes. The Apache 2.0 engine suits a vendor that wants to own the modeling UI and tenant layer. Check the Spring Boot generation before you commit, because Flowable 8.0.0 dropped support for Spring Boot 3, and confirm which commercial modules you would need for low-code modeling.
Operaton for Camunda 7 compatibility
Operaton is an Apache-2.0 BPMN 2.0 engine forked from the Camunda 7 Community Edition codebase. It keeps a compatible REST API, database schema and deployable BPMN and DMN models, which suits products that already run Camunda 7 workflows. It ships as official Docker images and Helm charts. The caveat is governance: the project has no single company in control and is still forming its governance, and it uses a release cycle with no traditional LTS line. Plan your own patch cadence and confirm support contracts with independent providers.
Camunda 8 requires a commercial license
Camunda 8 source code is published under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. A SaaS vendor that embeds Camunda 8 in a product delivered to customers should treat production use as a commercial licensing question before design starts. Ask the vendor how redistribution and hosting are covered, and budget for that license in the total cost of the product. Do not assume that a free download means production rights.
Node-RED for adjacent automation
Node-RED is a flow-based tool for wiring devices, APIs and services, and it is licensed under Apache-2.0. It fits integration and connector work around the product, such as ingesting events or calling third-party systems, rather than as the core approval engine. Its visual flows are not a substitute for a versioned BPMN model with an audit history of decisions. Confirm that flow definitions can be exported, reviewed and tested as part of your release process before customers depend on them.
n8n under the Sustainable Use License
n8n is a fair-code automation platform under the Sustainable Use License, and files marked .ee require an n8n Enterprise License. The license is not an open source license in the OSI sense, so redistribution inside a commercial product needs a separate legal review. It works best for internal automation between systems, where the product team runs it for its own operations. Confirm which license terms apply to the version you pin, and keep enterprise-marked modules out of any build you ship unless you hold the enterprise license.
Tenant isolation patterns and where they break
Each tenant isolation pattern trades cost, upgrade effort and blast radius against operational complexity. The same questions recur for every pattern: how a model change reaches each tenant, which nodes run timers and jobs, and where tenant identity is resolved.
One engine with tenant-tagged definitions
All tenants share one engine and one database schema, and each process definition, deployment and instance carries a tenant identifier. Migration is simplest because one upgrade covers every tenant, but a faulty definition or a noisy tenant affects everyone. Check that every query, API call and job filters by tenant, and that the async executor's lock owners and lock expiration times in the shared database recover jobs when a node fails. Confirm how Flowable's identity service replacement maps your tenant users and groups to engine identities, since a gap there leaks tasks across tenants.
One schema per tenant
Each tenant gets its own database schema, so instance data, history and migrations are separated at the database level. Upgrades must be run against every schema, and the time to finish a fleet-wide release grows with tenant count. Async jobs run per schema, so confirm which executor nodes poll which schemas and how locks are held when a node is shared across tenants. Connection pool sizing and the number of schemas per database server become operational limits. Ask how the identity service is replaced so that tenant context is set for every engine call, not only for the web layer.
One deployment per tenant
Each tenant runs its own engine, database and application instance, which gives the strongest separation and makes per-tenant customization and data residency easier to explain. The cost is operational: every release, patch and backup is repeated per deployment, and the vendor must automate that fleet. Async executors are isolated per deployment, so lock behavior is simpler, but scheduled timers still need monitoring across the fleet. Identity replacement is usually one LDAP or SSO adapter per deployment. Ask for a tested procedure to roll a Flowable or Operaton patch across all tenants in a defined window.
Shared engine with application-level row controls
A single engine stores everything, and the SaaS application enforces tenant boundaries by adding tenant checks to its own services, queries and API gateway. This is the lightest model to run, but the engine itself does not enforce isolation, so every direct call to the Java or REST API is a potential cross-tenant path. Customer-editable BPMN models also need validation before deployment, because a model can call services or read variables outside its tenant. Test with negative cases: a user from one tenant trying to claim, query or migrate another tenant's task or instance. Isolation at this layer is only as good as those tests.
Identity service replacement per tenant
Flowable allows the identity management layer to be replaced by overriding its identity service implementation or implementing its interface, with an LDAP reference implementation. In a multi-tenant product this is where candidate groups, assignees and tenant membership are resolved, so a defect here becomes an authorization failure. Decide whether tenant users are mirrored into the engine or resolved live from the product's identity store, and document how group changes propagate to open tasks. Verify that task queries and claims respect tenant context under concurrent requests, and that engine-level admin APIs are not exposed to customers.
How to let customers edit models without breaking live instances
Customer edits to a BPMN or DMN model are a change-control problem, not a modeling problem. An embedded engine will deploy whatever definition it is given and keep running the instances already in flight, so the safety of customer-driven change depends on a layer the vendor builds around the engine. In open source, the engine does not supply that layer on its own. The vendor needs to decide which BPMN and DMN elements customers may use (for example, a restricted set of task types, no script tasks, no direct database calls from service tasks, and only decision tables with approved input and output columns), and enforce that restriction in the editor and again on the server before deployment.
Validation should run before any definition reaches the engine. Typical checks include schema validation, required variables and forms present, expected service task bindings resolving to registered handlers, and decision tables that are complete and free of overlapping rules. Each saved change should become a new versioned definition, and running instances should stay bound to the version they started on. Migration of in-flight cases to a newer version is a separate decision with its own rules: which instances may move, which must finish on the old version, and how mapped variables are checked. The Flowable and Operaton documentation describe deployment, versioning and instance behavior, but you should confirm exactly how your chosen engine version handles version migration in your tenant model before promising customers any migration path.
Audit is the last control. Record who changed which model, what the diff was, who approved it, and which version each instance ran. Confirm with the engine vendor or community which editor features (visual debugging, low-code modeling, governance and monitoring) are in the open-source distribution and which are commercial add-ons, because that choice determines how much of this control you build yourself. Ask any implementation partner to demonstrate the validation pipeline, a failed deployment, and an instance that keeps its original version after a customer publishes a change.
Rollout phases for embedding a BPM engine in a SaaS product
This sequence moves an embedded BPM engine from a licensing decision to a general release, with a named output at each phase so the product, legal and operations teams can confirm progress before the next phase begins.
Confirm licence and redistribution terms
Counsel reviews the engine licence, the dependencies it pulls in and any commercial terms that apply to redistribution inside your product. For Apache-2.0 engines such as Flowable and Operaton, the review confirms that attribution and notice obligations are understood and that no enterprise-only modules are being bundled. The output is a signed-off licence register listing each component, its licence and the conditions that apply to shipping it to customers. Do not treat this as complete until counsel has confirmed the position in writing.
Decide the reference architecture and tenancy model
The product architect, with DeployOpen where engaged, chooses how tenants map onto the engine: a shared engine with tenant identifiers on process definitions and instances, a dedicated engine per tenant, or a mix based on customer tier. The decision covers database layout, schema ownership, backup and restore per tenant, and where customer data physically resides. The output is an architecture decision record that names the isolation boundary, the database engine and the deployment target, and lists the questions that remain open for the pilot.
Embed the engine and connect identity and APIs
Developers embed the engine as a library in the product's service layer, using the Java or Spring integration documented for the chosen engine, and connect it to the product's identity provider, authorization model and API gateway. Identity management is replaced through the engine's documented extension point so that task assignment resolves to real tenant users and groups. The output is a running engine in a development environment where a process can be deployed, started, assigned to a user and completed through the product's own API, with tenant context enforced on every call.
Build the customer model editor with validation
The team delivers a constrained editor in which customers change approval paths, forms and decision tables without access to raw engine internals. Validation rules check that every model deploys, that required service tasks have registered implementations, that each user task has an assignee rule and that changes cannot break running instances. Each published change creates a new process definition version. The output is a test suite that exercises the editor's validation rules and a documented rule set that product management can review before customers receive the editor.
Test load and asynchronous jobs across nodes
Engineers run the engine on multiple application nodes against the production database engine and test timers, asynchronous jobs and concurrent task completion. The test confirms that the async executor on each node coordinates through lock owners and lock expiration in the database, so that a node failure leaves no stuck jobs and expired locks are recovered by a surviving node. Results cover throughput per tenant, database connection pool behavior and recovery after a forced node restart. The output is a load and failover report with agreed thresholds and the configuration that passed.
Complete security testing and customer data terms
Security testers assess the embedded engine, the model editor and the tenant boundary, including attempts to read or change another tenant's process data through the API, model injection through the editor and privilege escalation through task assignment. In parallel, legal updates the customer data processing terms to cover the engine's role as a processor component, documented instructions for processing and the security measures applied to process variables. The output is a remediated test report and approved contract language that matches the architecture as built.
Run a pilot with a small set of tenants
Selected customers use the editor and embedded workflows in production under a written pilot scope. The product team monitors instance throughput, task latency, support tickets about model changes and any cross-tenant anomaly, and reviews each with the customer. Pilot exit criteria are agreed before the pilot starts and include a successful model version migration for running instances. The output is a pilot report listing defects fixed, configuration changes made and the criteria that were met or not met.
Release generally and set the upgrade cadence
After the pilot exit criteria are met, the product moves to general availability with an operations runbook for backup, restore, monitoring and engine upgrades. The team sets an upgrade cadence that tracks the engine's published release schedule and support window, and tests each upgrade in a staging tenant before it reaches customers. The output is a published runbook, a monitoring dashboard covering the engine's health endpoints, and an upgrade calendar that the support team and customers can see.
Evidence customers and auditors ask a SaaS vendor for
This table maps the evidence that customers, auditors and regulators typically request from a SaaS vendor that embeds workflow to the component that produces it. Read each row as a question to answer before a sales call or audit fieldwork begins, and confirm with your assessor which evidence their scope requires. The main takeaway is that the workflow engine itself produces only part of the evidence; the surrounding platform, change process and tenant design produce the rest.
| Evidence | Who asks | Component that produces it |
|---|---|---|
| SOC 2 system description and control evidence against the AICPA 2017 criteria, including security common criteria CC1 to CC9 | Enterprise customers' vendor risk teams, SOC 2 auditor | Documented system boundary covering the embedded engine, tenant data stores, APIs and hosting; control narratives mapped to CC1 to CC9 |
| Type 1 versus Type 2 scope: design as of a date, or operating effectiveness over a period | Procurement and security reviewers choosing between report types | Type 1 needs control design evidence at one date; Type 2 needs logs and samples showing controls ran across the observation period. Confirm the period with your auditor |
| Tenant isolation tests | Enterprise customers, penetration testers, auditors reviewing confidentiality | Test results showing one tenant cannot read or edit another tenant's models, instances, tasks or variables, covering API, database and admin paths |
| Change records for model deployments | Change advisory boards, SOC 2 auditors, customer compliance teams | Versioned BPMN and DMN deployments with approver, test evidence, timestamp and rollback record for each release to production |
| Audit history of process instances | Customers' operations and compliance teams, dispute handlers, auditors | Engine history tables and an application audit trail recording task completion, decisions, variable changes and the model version used for each instance |
| EU AI Act Article 12 and Article 19 log retention, only where AI features are added to the workflow | EU customers classifying the feature, legal and compliance teams | Automatic event logs for the AI component, retained for at least six months under Article 19(1) unless other law requires longer. Confirm whether your feature is in scope at all |
What do SaaS vendors ask before embedding an open-source BPM engine?
What does it cost to embed an open-source BPM engine in a SaaS product?
The engine itself is free to download under Apache-2.0, so the cost sits in the work around it. You pay for process modeling, integration with your product's data model and identity layer, the task and approval user interface your customers will use, tenant isolation, testing, and the infrastructure to run the engine for every tenant. Most of that is one-time work, while hosting, patching, engine upgrades and support recur. The main cost drivers are how many process types you embed, how many systems they call, how much customer-editable configuration you expose, and whether you migrate running processes from an earlier engine. Ask any partner for a quote built from a written scope that lists these items separately.
How long does a fixed-scope BPM embedding take?
The timeline depends on the inputs more than on the engine. Before a partner can estimate it, they need your list of process types, the number of customer-facing screens, the integrations your product already exposes, your tenancy model, and your release process for changes to the engine. Each of those inputs changes the amount of design and testing work. Ask for a written plan that sets out phases, deliverables and the points where you review and sign off, rather than a single date. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the timeline is fixed only after those inputs are confirmed.
Can our in-house engineering team embed Flowable or Operaton alone?
A capable Java team can embed either engine without outside help, because both run as libraries in Spring, servlet or Java SE applications and both expose Java and REST APIs. The harder parts are rarely the engine call. They are multi-tenant isolation, safe customer editing of BPMN models, clustering of the asynchronous job executor, database operations, and keeping pace with engine upgrades. Assess whether your team has owned these areas in a production product before. If not, a partner can cover a defined part of the work, such as the tenancy design or the upgrade process, and leave the rest with your team.
How do the EU Data Act switching rules affect our customers?
The EU Data Act has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises infrastructure. Under the Act, the switching notice period can be no longer than two months, and a transitional period of 30 days applies. From 12 January 2027, providers may not impose any switching charges. For a SaaS vendor, this means your customers must be able to export their process data, instances, models and history in a usable form. Design the export path into your product from the start, and confirm with your legal counsel whether the Act applies to your service.
Should we choose Operaton or Flowable for an embedded engine?
Both are Apache-2.0 BPMN engines, so the choice comes down to governance, roadmap and migration path. Operaton is a fork of Camunda 7 Community Edition, built after that edition reached end of life in October 2025. It keeps a compatible REST API and database schema with Camunda 7 CE 7.24 and has no open-core model, but its governance is still forming and it ships half-yearly feature releases with monthly patches and no LTS line. Flowable offers a longer engine history, a commercial company behind its products, and version 8.0.0 published on February 27, 2026, with a move to Spring Framework 7 and Spring Boot 4. Test both against your processes, your database and your upgrade policy before you decide.
Does the open-source license allow us to resell an embedded BPM feature?
Apache-2.0 permits commercial use, modification and redistribution, including inside a paid product, provided you keep the license and notices. Read the license of every component you ship, not only the engine. Camunda 8 source code is under the Camunda License 1.0, which allows use only in non-production environments without a commercial license, so it does not fit an embedded product model without a separate agreement. Your legal team should confirm attribution requirements, any NOTICE files, and the terms of the libraries and connectors you add. This page does not give legal advice, so treat the license review as a written deliverable from your counsel.
What does ongoing support cover after an embedded BPM engine goes live?
Ongoing support covers the work that keeps the embedded engine safe and current after launch. Typical items include applying monthly patch releases, planning feature upgrades, testing model changes made by customers, reviewing job executor and database performance, and responding to incidents. Operaton and Flowable both publish release cadences you need to track, so budget for upgrade testing as a recurring activity. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of each retainer is set out in writing. Ask for the response expectations, the upgrade windows and the testing evidence before you sign.
How do we keep one customer's process models away from another's?
Tenant isolation is a design decision you make before the first model is deployed. The main options are separate database schemas or instances per tenant, separate deployments per tenant group, or a shared engine with tenant identifiers on every deployment, definition, instance and task. Each option trades isolation strength against operating cost and upgrade effort. Check how your chosen engine handles tenant-scoped deployments, queries and the job executor, and test cross-tenant access explicitly. Ask any partner to show the isolation test cases in the written scope.
Questions to ask an implementation partner before embedding
Start with the question that separates partners who have embedded an engine in a multi-tenant product from those who have only deployed one for a single organization: how have you embedded a BPMN engine as a library inside a multi-tenant application before, and which component did you find hardest to isolate? Ask them to name the tenant key they use on process definitions, instances, variables, jobs and identity lookups, and whether the engine runs one shared database schema or separate schemas per tenant. Ask how they test tenant isolation: whether they run negative tests that attempt to read or complete another tenant's tasks through the Java API and the REST layer, and whether those tests run in the release pipeline for every change, not only at launch.
Next, ask how they handle a customer who edits a model while instances are already running. The answer should cover versioning of process definitions, the migration rules for in-flight instances, and who approves a migration before it runs in production. Ask how the async executor is clustered: lock owners and lock expiration times live in the database, so the partner should explain the lock expiry setting, how stuck jobs are recovered after a node fails, and how timers are kept from firing twice. On licensing, ask them to state in writing how they treat the Camunda 8 source license for production use and how they assess Operaton, which has no single controlling company and whose governance is still forming, against your redistribution and continuity needs.
Finally, ask who owns engine upgrades, since Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and Operaton ships feature releases twice a year with each version supported for six months. Ask who tests your application against each upgrade and who pays for that work. Before work starts, require a written scope that lists the engine and version, the tenancy model, the isolation test plan, the migration procedure for customer model edits, the clustering design, the license analysis, the upgrade responsibility matrix and the acceptance criteria for each deliverable.
How DeployOpen scopes and supports an embedded engine
The sequence turns an embedded workflow idea into a written scope, a reviewed architecture, a hardened build in your own environment, tested embedded surfaces and handover documentation, with an optional retainer after go-live.
Agree the written fixed scope
Before any build starts, DeployOpen and the vendor agree in writing which engine, which product surfaces, which tenants and which customer-facing features are in scope, along with the deliverables and the timeline. Scope covers whether the engine runs as a Java library inside your application or as a separate service, and which customer-editable areas, such as model editing and forms, are included. The step closes when both parties sign the scope document and the open questions list is empty or assigned to an owner.
Review the architecture and licensing
DeployOpen reviews how the engine will be embedded, including the choice between Apache-2.0 Flowable and Operaton, the database types your product supports, identity integration, tenant boundaries and how customer-edited models are stored and deployed. The review also confirms with your legal team that the chosen license permits the redistribution model you plan, and that any commercial or enterprise components are excluded from the design. The step closes with a written architecture decision record that your engineering and legal leads approve.
Build and harden in your environment
DeployOpen builds the embedded integration in your own development and hosting environment, using your repositories, pipelines and cloud accounts. Work covers tenant isolation in the process engine and data layer, restricted model editing for customers, deployment of versioned models, logging of process events and hardening of the runtime configuration. The step closes when the build passes your test pipeline and the hardening checklist agreed in the scope is signed off by your security owner.
Test the embedded surface
DeployOpen runs security testing against the parts of the product that expose the engine, including the REST or Java APIs, the model editor, form inputs, task assignment logic and tenant-scoped data access. Testing checks whether one tenant can read or alter another tenant's instances, tasks or models, and whether customer-edited models can execute unintended logic. Findings are logged with severity, reproduction steps and a fix owner. The step closes when agreed findings are fixed or formally accepted and a retest confirms the fixes.
Document and hand over
DeployOpen delivers operating documentation for your teams, covering deployment, configuration keys, upgrade steps, backup and restore for the engine database, tenant onboarding and model editing guidance for customers. Your engineers are trained on running the engine, reviewing logs and handling incidents. The control evidence your compliance team needs, such as configuration baselines and test reports, is packaged alongside the documentation. The step closes when your team runs a handover walkthrough and accepts the deliverables in writing.
Agree an optional retainer
After handover, you can choose a retainer for upgrades, patch application, continuous security testing and support on the embedded engine. Retainer scope, response expectations and the upgrade cadence are agreed in a separate written document, and the cost is quoted from that scope. Upgrades to the engine are planned and tested before release to customers, which matters because engine major versions can change framework and database requirements. The step closes when the retainer scope is signed or your team confirms it will maintain the engine in-house.
