Decision Model and Notation (DMN) reference

The following list describes each data type:

The Decision Engine now supports B-FEEL (Business Friendly Enough Expression Language) as an expression language. B-FEEL shares the same grammar as FEEL but alters the semantics to be friendlier. For more information about the key differences in Expression Language, see the B-FEEL vs FEEL.

The DMN 1.6 enhancement simplifies how InputData values are assigned across models with nested or transitive imports. When an InputData element is reused across multiple models through different import paths, the engine now assigns its value only once. All models referencing the same InputData share the same value consistently, regardless of how deeply nested or imported the reference is.

Previously, each import path required a separate, fully qualified assignment. For example, consider the following import structure:

Model B.Model A.Person name = "value"

Model C.Model A.Person name = "value"

With DMN 1.6, this process is streamlined. You can now assign the value once using the namespace:

Person name = "value"

The engine automatically propagates this value across all import paths. This change promotes cleaner model definitions and reduces redundancy in complex import hierarchies. Instead of specifying values separately for each import path, modelers only need to define the value once, and the system ensures consistent assignment across all references.

Users can continue assigning values using fully qualified paths if needed. This ensures that existing models remain functional without modification and gives users the flexibility to choose the assignment style that best fits their use case.

The consistency and usability of boxed filter and boxed iterator expressions are improved in DMN 1.6. These updates ensure that expressions not explicitly returning collections are still processed correctly through implicit coercion into singleton lists.

In boxed filters, the expression in the top part must evaluate to a collection. If the expression returns a single value—such as a number or string—the engine implicitly converts it into a list containing that value. Similarly, in boxed iterators, the expression in the in row must also evaluate to a collection, and singleton values are automatically wrapped into lists.

The DMN 1.6 clarifies the behavior of the Collect hit policy in decision tables. When this policy is used, the engine either returns all matched rule outputs in arbitrary order or applies a simple aggregation function to them, depending on the presence of an operator.

If no operator is specified, the engine returns a list containing the output entries of all matched rules. If an operator is present, the engine applies the corresponding function to the list and returns a single aggregated value.

The supported operators and their behaviors are:

This update also allows implicit conversion of single values into singleton lists, ensuring consistent behavior even when only one rule matches.

In DMN 1.6 the use of IANA Time Zone identifiers in time-only literals is deprecated to improve consistency and reduce ambiguity in time representations. The format "HH:mm:ss@Zone" (for example, 14:30:00@Asia/Kolkata) is no longer recommended for use in time literals.

This change does not affect date and time literals that use IANA zones. The recommended approach is to use the FEEL function date and time(date, time, timezone) instead of relying on implicit parsing of time strings with zones. When deprecated time literals are used, the engine logs a warning.

This feature encourages migration to FEEL-compliant expressions and ensures more predictable and standards-aligned behavior in decision models.

The NumberFunction class now supports a single parameter invoke() method that dynamically handles both String and Number formats. This improves the FEEL compliance and robustness, aligning with the OMG DMN RTF specification.

The engine returns the input unchanged if it is already a Number. If the input is a String, it attempts to parse it into a numeric value. For example, the engine converts "1.1" to a BigDecimal. If the string is invalid, such as "test" or "1 2 3", it returns null and triggers an error.

This enhancement simplifies decision logic by allowing flexible input handling while maintaining strict validation for non-numeric strings.

The DMN 1.6 introduces single-parameter versions of all rounding functions in FEEL. These variants simplify usage by assuming a default scale of 0, which aligns with intuitive expectations for whole-number rounding and streamlines decision logic for modelers.

The following functions are now supported with a single numeric argument:

The DMN 1.6 conversion rule automatically converts decimal numbers to integers in contexts where integer values are required. This rule ensures consistent behavior across decision models by aligning input types with expected output formats. The conversion truncates the decimal portion without rounding, preserving only the integer part of the number.

The engine converts the input to an integer if it is an instance of Number. If the input is not a Number, it returns the value unchanged. It discards the decimal part without applying rounding. This conversion applies automatically in all scenarios where an integer is expected, including integer-valued expressions, type-constrained variables, and FEEL function parameters that require integers.

For example, the engine converts 42.50, 42.009, and 42.99999 to 42 by discarding the decimal portion. For integer and long inputs (42 and 423L) it returns unchanged (42 and 423), as they are already integers. It does not apply conversion to "123" because the input is a string, and it ignores null values without producing a result.

The engine truncates numeric inputs to integers when required and safely bypasses non-numeric and null inputs, ensuring robust and predictable behavior in decision models.

The DMN 1.6 permits two distinct styles for referencing decisions within a single DMN file, allowing modelers to structure decision logic modularly and reuse decision definitions across different contexts or files. The engine supports both external and local referencing styles. When referencing a decision within the same DMN file, modelers can use a local reference without a namespace URI, employing a fragment identifier (prefixed with #) to point to the decision by its ID. Alternatively, when referencing a decision defined in a separate DMN file, modelers can use an external reference with a namespace URI, including the full URI of the external file along with the decision’s ID fragment. The engine supports both referencing styles, ensuring flexibility and consistency in model authoring and referencing.

DMN 1.6 includes a new conversion function- date and time(date, time, timezone). This function constructs a full date-time value by combining the provided date and time and applying the specified timezone.

The DMN 1.6 introduces the following two distinct modes for managing errors during decision model evaluation:

The error handling mode is configured during the initiation of the decision model evaluation, with lenient being the default mode. The default error handling mode is lenient.

In lenient error mode, the engine collects errors and continues execution, accumulating errors detected in child DRG Elements for the parent element.

In contrast, strict error mode halts model evaluation upon detecting the first error, reports the error, and returns null. This configured error handling mode also applies to the handling of errors during the evaluation of literal expressions, such as FEEL expressions, where built-in functions encountering input outside their defined domain report diagnostic information and return null.

In DMN 1.6, a new value property is defined in the following variable types:

The DMN 1.6 descendant operator to enhance the expressiveness of FEEL when working with nested contexts. This operator allows for the repetitive access of all values associated with a given property name, regardless of how deeply nested they are within a context structure. For example, given the following context:

Using the descendant operator to access b:

Returns the following expression:

The descendant operator collects all instances of the key b found at any level of nesting and returns them as a list.