Decision tables in DMN make business logic easy to read, since all possible inputs, and their resulting outputs, can be seen at a glance. Spotting missing cases or logical conflicts is also greatly simplified (just by looking at them, or thanks to validation tooling).

Lookup tables may also have multiple inputs and outputs, like decision tables. However, they are often very large. They are sometimes considered business logic, although they are not: the outputs are determined based on a match of the inputs. Furthermore, these types of tables are usually not maintained by the same people as business logic, and have a different life cycle (lookup data may change more frequently than business logic).

It may therefore seem natural to encode lookup tables as DMN decision tables, but this would be problematic for the reasons expressed above:

• Maintainability: Since lookup tables are usually very large, managing such large tables in a tool’s user interface can become cumbersome (in terms of navigation, editing, and looking at differences between versions).
• Performance: Large tables can use significant amounts of memory and slow down the general evaluation of the decision model.
• Separation of concerns: As discussed earlier, lookup data has a life cycle which is different from that of business logic. Putting the lookup data into decision tables would require redeploying the decision model every time a change is made in the data.

Lookup tables should therefore not be implemented as decision tables in a DMN model. Instead, the processing of lookup tables should be delegated to a specific “engine” performing the lookup in an efficient fashion.

DMN tools may facilitate the use of such a dedicated lookup engine by bundling it in and providing an associated editing UI. The result of the lookup would be provided to the DMN decision model through the equivalent of a function call.

When there is no built-in lookup engine, the execution of the lookup can be performed by an external service (making a database query, or executing some Java or C# code for example). The call to the lookup engine would also in this case be equivalent to a function call.

Finally, when the DMN tool provides no facility whatsoever to the equivalent of an external function call, the dedicated lookup engine would have to be run in a first step, and its result be supplied to the DMN decision model by means of an input.

Separating the DMN model business logic from lookup data also makes it possible to update the data as often as required, without changing the business logic and therefore without the need to redeploy.

In summary, lookup tables should be externalized and treated as data, while DMN decision tables should remain focused on business logic.

Not sure whether your tool of choice provides the right tooling for dealing with lookup tables or other requirements? You can find out which features your DMN tool should provide depending on your needs using OUR INTERACTIVE USAGE SCENARIOS.