Why DMN decision automation changes who can change a rule
Eligibility, pricing and routing rules often sit inside application code, so every change waits for a developer, a test cycle and a release. Compliance teams see the outcome but cannot read or change the logic that produced it. DMN decision tables run by a self-hosted engine such as Flowable or Operaton separate rule ownership from application code: the business or risk owner maintains the decision table, and the application calls the decision by key. The engine's license decides whether that arrangement can be used in production at all, so license review belongs in the first design decision, not after the pilot.
Flowable's engines are licensed under Apache-2.0 and include DMN decision rules alongside BPMN and CMMN, with Java and REST APIs. Operaton is an Apache-2.0 BPMN and DMN engine forked from Camunda 7 CE, and its 2.1 release notes state API compatibility with Camunda 7 CE 7.24 and DMN 1.3 compliance. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so a Camunda 8 pilot cannot be promoted as-is. Confirm the license text for the exact version and edition you plan to run, and confirm whether the support model you need comes from the vendor, a community, or independent service providers.
Practically, the decision for the team is who signs off a table change and how that change is tested before it reaches production. Ask the implementation partner to show how a decision table moves from a draft to an approved version, which test cases run against it, and how each case records the rule version that decided it. Confirm that the engine's license covers production use for your deployment model, and confirm the support path before the first table goes live. These checks determine whether compliance can change a rule safely without a release.
Which regulatory and audit requirements shape the decision layer
This table maps common audit and regulatory requirements to what they mean for DMN table design, versioning and retention. Read each row as a question to put to your compliance lead and engine team before the first table is published. The main takeaway is that the decision record, not the table alone, is what an assessor will ask to see.
| Requirement | What it means for the decision layer | Evidence to retain | Where it usually fails |
|---|---|---|---|
| Record which rule version decided each case | Every decision call must store the deployed DMN definition version and key, alongside the inputs and output. | Decision instance log with definition ID, version, inputs and outputs per case | Only the latest table is kept, so older decisions cannot be reproduced |
| Retain logs for the required period | Retention of decision logs must match the business or legal retention rule, not the engine default. Confirm the period with counsel. | Retention schedule, archive jobs and restore tests | Logs stay in a development database and are purged during routine maintenance |
| Human oversight of automated decisions | Tables must mark which outcomes are final and which route to a reviewer, with the reviewer's override recorded. | Routing rules, override records and reviewer identity per decision | Overrides are made outside the engine and never linked to the original decision |
| Change control and testing before production | Each table change needs an owner, a documented test set and an approval step before deployment. | Change tickets, test results against a fixed case set, approval records | Business users edit tables directly in production with no test evidence |
| Traceability of rule logic to policy | Each rule row should trace to a policy clause or product document so an assessor can follow the logic. | Requirement-to-rule mapping and version history of the source policy | Rule meaning lives in the head of one analyst and is not written down |
| Documentation of model and decision logic | Where a table is combined with a statistical or AI model, the boundary between the two must be documented. | Architecture notes showing which outcomes come from tables and which from models | Models score inputs that the table then overrides, with no record of which one decided |
| EU AI Act logging for high-risk systems | Article 12(1) requires automatic event logging over the system lifetime, and Article 19(1) requires keeping logs for at least six months unless other law provides otherwise. These apply only where the system is high-risk. Confirm applicability with counsel. | Automatically generated logs, retention settings and the legal classification memo | Teams assume the rules engine is out of scope without a documented classification |
| DMN 1.3 standard support | Operaton 2.1 states compliance with DMN 1.3, which helps keep tables portable across engines that implement the standard. Confirm the exact DMN features each engine supports before relying on them. | Engine version pinned in the change record and a portability test on any alternative engine | Vendor extensions in tables are used without noting they break portability |
Who maintains the decision tables and who approves changes
Business rule owners are the people who know what the eligibility, pricing or routing rule should say. They draft changes to DMN decision tables, usually in a modeling tool that exports standard DMN 1.3 XML, and they explain the intent of each rule in the change request. Their access should stop at the decision table itself. They should not be able to change the surrounding process model, the deployment pipeline or the production engine configuration.
- Edit scope: Authors change only the decision tables assigned to their business area, with the hit policy and input and output columns fixed by the design.
- Source control: Changes arrive as branches or pull requests against the DMN file, never as edits made directly on the running server.
- Test cases: Each author supplies example inputs and expected outcomes that the test harness runs before review.
- Change notes: Every edit carries a plain-language reason, a referenced policy or product decision, and an effective date.
- Limits: Owners cannot merge their own changes or deploy them.
Confirm with your engine partner whether your chosen modeling tool writes DMN 1.3 and how it stores decision IDs, because unstable IDs break version history and audit lookups.
Risk, compliance and model governance reviewers approve what goes into production. Their job is to confirm that a rule change matches the approved policy, that the test evidence is adequate and that the change is traceable to a named approver. They do not need to write DMN, but they need to read the table and the diff in plain form. Their approval should be recorded in the same system that holds the change, so the approval and the artifact cannot drift apart.
- Review rights: Reviewers can approve or reject a merge request but cannot author the change they are reviewing.
- Four-eyes rule: Require at least one approver who is not the author, and confirm with your control owner whether high-impact pricing or eligibility rules need a second approver.
- Evidence view: Reviewers see the diff, the test results and the linked policy reference in one place.
- Read access to runtime: Reviewers can query which version is deployed and which version decided a sample case, without rights to redeploy.
- Exception path: Emergency changes follow a documented route with retrospective review within a period your governance sets.
Ask your auditors which approval records they expect to sample, since their sampling method determines how the approval log must be structured.
Engineers own the decision engine, the deployment pipeline and the test harness. They install and patch the engine, configure its database and clustering, and decide how decision definitions are packaged and promoted from test to production. Flowable and Operaton both execute DMN models through Java and REST APIs, so engineers typically run the engine as a service that receives deployments from the pipeline rather than letting business users touch it directly. Engineers should not decide what a rule says, and they should not be the only people who approve a rule.
- Engine administration: Restricted to the platform team, with production credentials held outside source control.
- Pipeline ownership: Engineers build and maintain the promotion path that runs tests, packages the DMN and deploys it.
- Test harness: Engineers provide the framework that runs owner-supplied cases and blocks merges on failure.
- Version pinning: Engineers record the engine version alongside each decision version, since an upgrade can change evaluation behavior.
- Audit logging: Engineers make sure each evaluation stores the deployed decision definition identifier and version.
Check with your engine vendor or partner which decision version identifiers the engine stores with each evaluation, and whether the engine's history retention meets your record-keeping period.
The three roles only protect the organization if their permissions do not overlap in the places that matter. The key boundary is between authoring and deploying, because a single person who can write a rule and push it to production removes the review step. The second boundary is between the people who can change a rule and the people who can alter the record of which rule decided a case. Source control and the engine's deployment store should both keep a history that the authors cannot edit.
- Authoring versus merging: Branch protection prevents an author from approving their own pull request.
- Merging versus deploying: Only the pipeline identity deploys to production, and that identity cannot approve changes.
- Records: Audit logs and decision history are write-once from the perspective of the business roles.
- Access review: Re-certify role membership on a schedule your governance sets, and remove access when people change roles.
- Break-glass: Keep a documented emergency account with alerting, used only under an approved incident.
Review the permission matrix with your security team and your auditors before go-live, and confirm which controls they will test against the source control platform you choose.
Which open-source decision engines fit this use
Three open-source engines cover most DMN decision work, and each fits a different mix of team skills, Java stack and governance appetite. The choice shapes who can edit tables, how rules are deployed, and how much of the surrounding process tooling you must build yourself.
Flowable for BPMN and DMN together
Flowable is an Apache-2.0 engine family with BPMN, CMMN and DMN engines, exposed through Java APIs and REST. It fits when the same platform already runs or will run your processes, so decision tables are called from process steps without a second runtime. Check that your team can build the table editing experience, since the open-source engine ships without a business-user rule editor. Flowable 8.0.0 was released on February 27, 2026, and moves to Spring Boot 4, so confirm your Spring stack before upgrading.
Operaton for Camunda 7 lineage
Operaton is an Apache-2.0 BPMN engine forked from Camunda 7 CE, with DMN 1.3 listed in its release notes. It suits teams migrating off Camunda 7 who want a community-governed engine with a compatible REST API and schema. Governance is still forming, with no single company in control, so write down who will patch the engine and how you will track its six-month support window. Confirm DMN features your tables depend on against the DMN 1.3 level stated for version 2.1.
Apache KIE and Drools rule engine
Apache KIE is the home of Drools, jBPM and Kogito under Apache-2.0, and 10.2.0 added DMN 1.6 support. It fits Java teams that want a rule engine with a deep rules language alongside DMN. The project is still in incubation at the Apache Software Foundation, which does not guarantee completeness or stability, so pin versions and test upgrades. Several components, including Kogito, have moved repositories, so confirm the current artifact locations with your engineers before standardizing.
Camunda 8 license limits
Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. Teams that assume the source is open for production use can face a licensing gap at go-live. Ask any vendor or partner to confirm in writing which license covers the exact components and DMN capability you plan to run in production, and whether a commercial agreement is required.
Matching engine to team skills
Choose by who will maintain the decision logic. Business analysts who edit tables in spreadsheets-style editors need a front end you build or buy, whichever engine you pick. Java developers comfortable with Spring or Quarkus can keep rules in version control and deploy through CI. Record the skills you have today, the Java version you run (Operaton 2.1 requires Java 17), and the database you standardize on before comparing engines on features.
Governance and support model
Decide who owns the engine after go-live. Flowable offers a community forum for open-source users, with professional services and partners offered separately. Operaton has no commercial editions and lists professional support from several independent providers. Apache KIE relies on the ASF incubation process. Ask each candidate for its upgrade cadence, security patch process, and named support options, and budget internal engineering time for upgrades in every case.
How a DMN rollout moves from pilot to production
The sequence turns rules buried in code and documents into versioned decision tables that a reviewer can approve, a test suite can regress, and an auditor can trace case by case. Each phase closes with a named artifact that the next phase depends on.
Inventory the rules and their owners
The team finds every eligibility, pricing and routing rule in application code, configuration files, spreadsheets and policy documents, then records the business owner, the source document and the systems that call each rule. A rule with no named owner or no source document is flagged before any modeling starts. The output is a rule inventory that the business owners sign off on, which defines the scope of the pilot. The step is done when every rule in the pilot scope maps to one owner and one source.
Model decisions and design the tables
Analysts and engineers agree on the decision requirements, the inputs each decision reads and the outputs it returns, then draw them as DMN decision requirements and build decision tables for the chosen engine. Hit policy, input data types and default outcomes are set explicitly so that overlapping rules cannot silently conflict. The output is a set of draft tables with a named owner for each table and a short note on the policy clause each row implements. The step closes when the business owner confirms that the tables match the source documents.
Write the test suite with expected outputs
The team builds test cases from real historical or synthetic applications, including boundary values and known edge cases, and records the expected output for each one. Business owners review the expected outcomes, because a test written by the same person who built the table only checks that the table matches itself. The output is a versioned test suite and a baseline run that shows which cases pass and which need a decision. The step is complete when every rule in scope has at least one positive and one negative case.
Run regression tests on every change
Each proposed change to a table runs the full test suite in a non-production environment, and the results are stored with the change request. A failing case must be resolved by either fixing the table or formally updating the expected output with a recorded reason. The output is a regression report tied to a specific table version. The step closes when the suite passes on the exact version proposed for release, and the report is attached to the change ticket.
Approve and deploy versioned tables
The approved table version goes through the organization's change approval process, with separation between the person who authored the change and the person who approves it. The deployment records the version identifier, the approver, the test report and the target environment, and the engine deploys that version as a new definition without replacing earlier ones. The output is an approved, deployed decision version with a traceable change record. The step is done when the production engine reports the new version as active and the change record links to the approval.
Record which version decided each case
The calling process stores the decision identifier and the version of the decision table alongside each outcome, so every eligibility or pricing result can be traced to the rule set that produced it. Teams confirm that their engine's history tables or audit logs capture these fields and that the data is retained for the period their policy requires. The output is an audit query that returns, for any case identifier, the inputs, the outcome and the table version. The step is complete when a reviewer can run that query for a sample of cases and get a result without engineering help.
Monitor outcomes and keep a rollback path
Operations and the business owner track decision volumes, outcome distributions and exception queues after release, and compare them with the pre-release baseline. If an outcome shifts beyond the tolerance the owners set in advance, the team reactivates the previous approved version through the same change process. The output is a monitoring dashboard, a documented rollback procedure and a rehearsal record showing that rollback works. The step is done when the rollback has been tested in a non-production environment and the owners have agreed the alert thresholds in writing.
How integration and deployment work in a regulated estate
How does a DMN decision service connect to a core system over REST?
A core system typically calls the decision engine over REST, sends the case data as a request, and receives the decision output along with the identifier of the rule version that produced it. Flowable and Operaton both expose REST APIs for their engines, and Operaton's REST API is documented as compatible with Camunda 7 CE 7.24, which matters if your team already works with that style of API. Flowable also offers a REST application that can run as a separate service. The integration contract is the part to design first: request and response schemas, error handling, timeouts, authentication between services, and whether every response includes the decision version. Confirm each of these in a proof of concept against the exact engine version you plan to run, because the REST surface can change between major releases.
How is an open-source decision engine deployed on Kubernetes?
Operaton is distributed as official Docker images and Helm charts for Kubernetes, alongside Spring Boot, Quarkus and Jakarta EE integration, so the engine can run as a set of pods in your own cluster. Pin the image to a specific release tag and keep the chart version under the same change control as the application. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, which shapes the base images your security team approves. Operaton ships half-yearly feature releases with monthly patch releases, and each version is supported for six months until the next one ships, so plan a regular upgrade cadence. Confirm the chart's values for database connection secrets, ingress, resource limits, health probes and horizontal scaling against your platform standards before adoption. The Operaton repository lists the current distribution options.
Where do the database and logs of a self-hosted rules engine live?
The decision engine keeps its state in a relational database that you provide and operate, so the database location, backup schedule and access controls are your decisions. Operaton lists H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2 as supported databases. For version 2.1, the minimum versions are PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, with Oracle 21, SQL Server 2022 and DB2 support unchanged. Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Logs are a separate question. Confirm where the engine and its containers write logs, how those logs are forwarded to a central platform, and whether they can contain case data that your privacy rules restrict. Also confirm which tables hold decision history, how long they are kept, and how they are purged.
How is identity connected to a self-hosted decision engine?
Identity is connected by replacing the engine's identity management layer with your own identity source. Flowable's documentation describes two routes: override the default identity service implementation, or implement the IdmIdentityService interface. It provides an LDAP identity service as a reference implementation. Map your directory groups to the roles that can deploy decision tables, approve changes and read decision history, and keep that mapping in version control so reviewers can inspect it. For Operaton, confirm the identity extension point in its documentation before committing to a design. Test single sign-on for any modeling tool and for the REST API separately, since they often authenticate in different ways. Record which service accounts the core systems use to call the engine, and who can rotate their credentials.
How do clustered decision engine nodes share one database?
Clustered nodes share one database, which becomes the coordination point for background work. In Flowable, the async executor runs timers and asynchronous jobs from a thread pool, and nodes coordinate through lock owners and lock expiration times stored in the database. When a lock expires, it is recovered and another node can pick up the job. This design means database sizing, connection pool limits and failover behavior affect the whole cluster. Confirm with the vendor or in your own tests how Operaton handles the same coordination, how many nodes you plan to run, which calls are synchronous decisions and which work runs asynchronously, and how the database is made highly available. Run a failover test before production, including a node restart during a batch of decisions. The Flowable advanced documentation describes the executor design in detail.
What drives the cost and timeline of a DMN integration?
Cost depends on who does the work and what runs after go-live. No supplied fact gives a price or duration for a DMN integration, so ask for a written estimate built from your scope. One-time costs include designing the decision services, modeling the tables from the business rules, integrating each core system, building the test suite, setting up the database and cluster, and connecting identity. Recurring costs include hosting, database operations, monitoring, upgrades and the ongoing maintenance of rules by business owners. The main drivers are the number of decision services, the number of core systems that call them, how often the rules change, and how mature your Kubernetes and identity platforms already are. Ask any provider, including DeployOpen, for a written scope that lists decision services, integrations, environments, test coverage, handover and support terms, with one-time and recurring costs shown separately. DeployOpen does not publish a price list, so each quote follows from the written scope.
Can our own team run the decision engine after go-live?
Yes, if the team can operate a Java service on Kubernetes and run the chosen relational database. Flowable's open source engines are licensed under Apache 2.0, and the open source offering includes a community forum, while professional services and partners are offered separately. Operaton's repository describes professional support and consulting from multiple independent service providers. Plan for upgrades, because they require significant engineering work. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Operaton's support window for each version lasts six months until the next version ships. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts. Ask which runbooks, regression tests and handover documents are included.
Evidence auditors and regulators ask for on automated decisions
This table lists the evidence an assessor is likely to request for a decision table that approves, prices or routes cases, which component produces each item, and what to confirm with the auditor before go-live. Read it as a checklist: the engine can record which version decided a case, but the surrounding approval, test and access records usually come from other systems.
| Evidence item | Produced by | What to confirm with the auditor |
|---|---|---|
| Deployed table version for each decision | Engine deployment and history tables in Flowable or Operaton, linked to each process or decision instance | Whether the auditor needs the version ID stored on the business record, not only in engine history, and how long history is kept |
| Decision input and output for each case | Engine history or the calling application's decision log, captured at evaluation time | Which inputs must be retained (for example, personal data fields) and whether masking is acceptable in the log |
| Change approval record for each rule edit | Source control pull or merge request history, plus the approver field in the change ticket | Who must approve a table change, whether four-eyes review is required, and how emergency changes are recorded |
| Test results before promotion | CI test runs against a set of reference cases, with results stored with the build | Which test cases the auditor expects, such as boundary values and previously disputed cases, and how regression results are retained |
| Access logs for table editing | Identity provider and source control audit logs, and the modeling tool's access records if one is used | Whether the auditor expects editing rights to be separated from deployment rights and how periodic access reviews are evidenced |
| Retention of decision logs | Application logs, gateway logs or a central log store that holds decision records outside the engine | The retention period set by applicable law or policy, and whether logs must be immutable or tamper-evident |
| Link between a decision and its rule version | Application code that writes the decision version ID to the case record, tested as part of the release | Whether a sample of past decisions can be traced to the exact table version in use on that date |
| Explanation of automated outcomes | Decision table documentation kept in source control, plus decision output fields recorded per case | Whether the auditor accepts table documentation as the explanation or expects a per-case rationale |
Build, partner or SaaS for decision automation
The three options differ mainly in who owns the rule tables after go-live. Building in-house on an Apache-2.0 engine such as Flowable, whose BPMN, CMMN and DMN engines are licensed under Apache 2.0, means your own staff own the decision models, the decision service, the REST integrations and the test harness. The license cost is zero, but the recurring cost is people: developers who understand the DMN dialect, analysts who can review tables, and someone accountable for upgrades. A partner-led implementation with a fixed scope moves the build effort into a written deliverable, usually covering the initial tables, integrations, test suites and a handover, with support or upgrades bought separately as a retainer. A commercial decision platform licensed per user or per app replaces much of the build with a vendor's editor and governance features, but the recurring license fee scales with the people or applications that touch the rules, and you should confirm what the vendor's terms say about exporting models if you later move away.
Cost is driven by a small set of variables you can measure before asking anyone for a quote. The main ones are the number of decision tables and their hit policies, the number of upstream and downstream systems that call the decision service, the depth of regression testing you require for each rule change, and the volume of existing rules that must be migrated from code, spreadsheets or a legacy rules engine. Each of these multiplies effort in every option, so ask each bidder to price them separately. Ask for a one-time figure covering modeling, integration, test automation and migration, and a recurring figure covering engine hosting, upgrades, rule maintenance and support. Confirm who pays for the database, the monitoring stack and the audit log store, because these are often left out of a partner quote and then appear later as infrastructure costs.
Before choosing, decide who will approve a rule change and who will be on call when a decision service misbehaves. A useful test is to run a single real eligibility rule through each option: have the business owner change a threshold, run the regression suite, deploy to a non-production environment and produce the record showing which version decided a sample case. Note how many people and how many days that took, and where the vendor or partner had to act. The result tells you more about recurring ownership than any price comparison. Ask partners to show the test evidence for a change they have delivered, not only the architecture diagram, and confirm in writing who holds source code, model files and deployment scripts at the end of the engagement.
How much effort does a DMN decision project take?
What drives the cost of a DMN decision automation project?
The cost follows the written scope, and the main drivers are how many decisions move out of code, how many systems call them, and how much test coverage the rules need before go-live. The open-source DMN engine itself carries no license fee in the Apache-2.0 options, so the spend goes to people: rule analysis, decision modeling, integration work, test suites, deployment and handover. Ask any partner to split the quote into one-time build work and recurring items such as upgrades, rule maintenance and support. Each of these components should be listed separately so you can see who is paid for what.
How long does it take to move business rules into DMN tables?
Duration depends on the number of decisions, how well the current rules are documented, and how many applications must call the decision service. A narrow project with a few decision tables and one calling system is much shorter than a rollout that covers eligibility, pricing and routing across several products. Most of the time goes to extracting rules from code and getting rule owners to agree on the wording, not to writing the XML. Ask for a phased plan with a named first decision, and confirm the timeline against your own change approval calendar.
What do we need to provide before a DMN project starts?
You need named rule owners who can make decisions on policy wording, a set of anonymized sample cases with the outcome each one received, and a clear approval authority that signs off each rule version. Sample cases drive the first test suite, so incomplete or unlabeled cases slow every later step. Also provide access to the systems that call the decisions and to a non-production environment. Without these inputs, rule questions get escalated late and the project stalls.
Who should own the decision tables after go-live?
Business rule owners should own the content of each table, while IT owns the engine, the deployment pipeline and the access controls. A change should move from the rule owner to a reviewer who is not the author, then through automated tests and a documented approval before production. Decide this split before build starts, because it determines who can edit a table and who can approve the change. Confirm the approval roles with your compliance team, since they will ask which person authorized each version.
Can our internal team maintain DMN decisions without a partner?
Yes, many teams can maintain decision tables with internal skills once the first set is in place, provided they have Java or DevOps capacity to run the engine and a testing habit for rule changes. The harder part is the first build, where rule extraction, test design and integration usually need experienced engineers. Many organizations choose a partner for the initial build and handover, then keep rule maintenance in house. Confirm the skills gap, the on-call coverage and the upgrade plan before you decide.
How does the number of rules affect test effort?
Test effort grows with the number of rules, the number of input combinations and the number of versions that must stay in service at the same time. Each table needs cases for the normal path, boundary values and conflicting inputs, and each change needs a regression run against the existing suite. A table with a few inputs is quick to cover, while a pricing table with many dimensions needs a far larger matrix. Ask how the partner plans to generate and maintain test cases and whether they will hand over the suite with the decisions.
What integrations add the most effort to a DMN project?
Integrations that pass input data into the decision service and return results to core systems usually take the most effort, especially when source data is inconsistent or owned by another team. Each calling application needs an agreed input contract, error handling for missing data and logging of the decision result. Systems with batch processing, legacy interfaces or tight response-time limits add further work. List every calling system and its data owner early, because access and contract discussions often set the schedule more than the rules do.
Do quotes for DMN projects follow a written scope?
Yes. DeployOpen scopes most engagements as fixed-scope work, with the decisions, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list. Your quote follows from that written scope, so the more precisely you define the decisions, systems and evidence you need, the more precisely the quote can reflect them. Ask for the assumptions behind each line item, what is excluded, and what triggers a change request.
How DeployOpen scopes and supports DMN decision automation
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the decision engines that run business rules. For DMN decision automation, we start from a written scope that names the decisions, owners and systems involved, then build, test and hand over the decision tables with the evidence your assessors will ask for.
How we scope
- Inventory the eligibility, pricing and routing decisions to move out of code, with their current owners and source systems.
- Agree in writing which DMN tables, decision requirements and calling processes are in scope, and which stay in application code.
- Define who approves rule changes, how versions are numbered and what audit record each decision must produce before work starts.
How we build
- Model decision tables in DMN and deploy them to the chosen engine, such as Flowable or Operaton, on your own infrastructure.
- Build automated regression tests with known input cases and expected outcomes, run on every change before promotion.
- Connect decisions to calling BPMN processes or applications through the engine's Java and REST APIs, with identity and logging configured.
How we hand over
- Deliver the decision table catalog, change procedure, test suite and runbook so your rule owners can maintain tables without us.
- Document how each decision records the deployed rule version and inputs, and how those records are retained and retrieved.
- Train the named maintainers on editing, reviewing and promoting tables, and agree the handover acceptance criteria in the scope.
How we support
- Support is available as a retainer covering engine upgrades, patches, regression test maintenance and new decision tables.
- Confirm the engine's release and support cadence with the vendor or project before agreeing a retainer, and plan upgrades around it.
- Re-run the decision test suite after every engine or dependency upgrade, and record the results as change evidence.
