Hi, we have started using flowable DMN (great editor, by the way - even pasting from Excel works 
).
However we have a deployment-related problem, which requires some forum discussion.
Unless we misunderstood, the current behavior enforces that a BPMN process and a decision table should always be deployed together. Reason: The Flowable Decisiontask at runtime finds the decisiontable by key within the same deployment (having a particular parentDeploymentId). If it doesn’t exist, an error is thrown.
This behavior is seems good for forcing a clear ‘isolation’ between deployments.
However, functionally speaking, we think that the a big advantage of DMN Decisiontables is the ability to adapt business rules without redeploying the BPMN process. It allows hiding the complexities of BPMN and just let a business user modify some rules (yes, agreed, they should know not to rename process variables, etc… but apart from that, it’s easy). Hence, we have built our code to allow separate deployment of newer versions of the decisiontable, without having to redeploy the process. But then we ran into this deployment issue.
Our requested behavior is that a DMN task would always use the most recent deployed decision table (or, at least, that we can make it work that way through some parameter)
We have made a PR (https://github.com/flowable/flowable-engine/pull/651) that fixes this: do a ‘global’ lookup of the most recent decisiontable by key, if it is not found in the current deployment. But I can imagine that others might disagree with this behavior.
So let’s discuss the intended behavior. Are you OK with the PR? Or should the Decisiontable lookup ‘strategy’ be an option of the BPMN decisiontask ? How are others using this?
Pieter