A BPMN 2.0 expense model writes its conditions in FEEL and calls a DMN policy decision, but its definitions declare no expression language; what is wrong, and how do you fix it?

seniorshould knowfreq 25%

answer

the default the standard assumes
a URI, not a name
override per expression
linking a decision is not invoking it

basics

~20 s

In BPMN 2.0 an undeclared expressionLanguage defaults to XPath, so FEEL conditions are declared as XPath and cannot be evaluated as intended. Declare the DMN FEEL URI on definitions or each formalExpression, and bind the business-rule task's implementation to the decision.

solid answer

~40 s

BPMN 2.0.2 does not define FEEL; DMN does. The definitions attribute expressionLanguage defaults to XPath (http://www.w3.org/1999/XPath), and typeLanguage to XML Schema, so a condition like claim.amount > 500 written in FEEL is, by declaration, an XPath expression. Fix it by setting expressionLanguage to the FEEL URI that DMN 1.5 defines, https://www.omg.org/spec/DMN/20230324/FEEL/, or by setting the language attribute on each formalExpression; both must be URIs. Note that the Common Executable conformance sub-class fixes XPath as its data access language, so a FEEL-based model relies on tool support beyond that sub-class. For the policy decision, the business-rule task's implementation defaults to ##unspecified; set a URI for the technology that invokes the decision. DMN's usingProcesses and usingTasks associations record and validate the link, but DMN says they do not by themselves make the decision execute.

BPMN 2.0.2 does not define FEEL; DMN does. The `definitions` attribute `expressionLanguage` **defaults to XPath** (`http://www.w3.org/1999/XPath`), and `typeLanguage` to XML Schema, so a condition like `claim.amount > 500` written in FEEL is, by declaration, an XPath expression. Fix it by setting `expressionLanguage` to the FEEL URI that DMN 1.5 defines, `https://www.omg.org/spec/DMN/20230324/FEEL/`, or by setting the `language` attribute on each `formalExpression`; both must be URIs. Note that the **Common Executable** conformance sub-class fixes XPath as its data access language, so a FEEL-based model relies on tool support beyond that sub-class. For the policy decision, the business-rule task's `implementation` defaults to `##unspecified`; set a URI for the technology that invokes the decision. DMN's `usingProcesses` and `usingTasks` associations record and validate the link, but DMN says they do not by themselves make the decision execute.

code

xml · 14 lines

xml

<definitions id="ExpenseDefinitions"
    targetNamespace="http://example.org/expense"
    expressionLanguage="https://www.omg.org/spec/DMN/20230324/FEEL/"
    typeLanguage="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <process id="ExpenseReimbursement" isExecutable="true">
    <sequenceFlow id="OverLimit" sourceRef="ClaimChecked" targetRef="ApproveClaim">
      <conditionExpression xsi:type="tFormalExpression">claim.amount &gt; 500</conditionExpression>
    </sequenceFlow>
    <businessRuleTask id="CheckPolicy" name="Check expense policy"
                      implementation="##WebService"/>
  </process>
</definitions>

go deeper

for a junior

Recall that BPMN expressions have a declared language, XPath by default, and that FEEL comes from DMN.

for a middle

Explain where the language is declared, definitions or each formal expression, and that it is always a URI.

for a senior

Diagnose models whose written and declared languages differ, and bind decision calls through a concrete implementation.

for a principal

Choose one expression and type language for a modelling estate, weighing portability against analyst readability.

The symptom

The developers replaced the analyst's prose conditions with expressions like claim.amount > 500 and pointed a business rule task Check expense policy at a DMN decision table. On import into a second standards-conformant tool, the conditions are rejected or misread, and the decision is never called. The model has two declaration gaps.

Gap 1: the expression language

BPMN 2.0.2 sets the expression language in two places:

Where	Attribute	Default	Scope
`definitions`	`expressionLanguage`	`http://www.w3.org/1999/XPath`	every formal expression in the file
`formalExpression`	`language`	inherits from `definitions`	that one expression
`definitions`	`typeLanguage`	`http://www.w3.org/2001/XMLSchema`	item definitions in the file

Key points from the text:

The language MUST be specified in a URI format.
A plain Expression holds natural-language text and is not executable; a FormalExpression is the executable form in a specified language.
With XPath, BPMN provides extension functions such as getDataObject, getDataInput, getProcessProperty and getActivityProperty for reaching process data.

FEEL is not defined in BPMN at all. It is defined by DMN (the Friendly Enough Expression Language), and DMN 1.5 identifies it with the URI https://www.omg.org/spec/DMN/20230324/FEEL/. A BPMN model can use FEEL because BPMN accepts any expression language named by URI, but only if it says so.

Fixing gap 1

Set expressionLanguage on definitions to the FEEL URI, so every formal expression defaults to FEEL; or
Keep the XPath default and set language on each formalExpression that is written in FEEL.

Option 1 is cleaner when the whole model uses FEEL. Mixing languages is legal, but each expression must then declare its own. Be aware that the standard's Common Executable conformance sub-class requires XML Schema for data types, WSDL for service interfaces and XPath for data access; a FEEL-based model therefore depends on tools that support more than that sub-class.

Gap 2: calling the decision

The standard describes a business rule task as a mechanism for the process to provide input to a business rules engine and get its output; its input/output specification carries the data. Two further facts matter:

The business rule task's implementation defaults to ##unspecified, which leaves the technology open. Set it to ##WebService or a URI identifying the technology that invokes the decision.
On the DMN side, a decision can list usingProcesses and usingTasks, the BPMN processes and tasks that use it. DMN states that this allows the relationship to be defined and validated but does not of itself permit the decision to be executed automatically by the process. DMN's non-normative annex describes encapsulating decisions in a decision service called from a BPMN task, such as a service task or business rule task, and says the business rule task is the most natural way to express this today.

The corrected model

definitions declares expressionLanguage as the FEEL URI (and a typeLanguage that matches how the item definitions are written).
Every condition is a formalExpression in that language.
Check expense policy declares its data inputs and outputs, and its implementation names the technology that invokes the decision service.
The DMN decision lists the process and task in usingProcesses and usingTasks for traceability.

Why the default bites even when a tool seems to cope

Some tools guess the language from the text or apply their own default. The model then works in that tool and fails in the next one, because the file still says XPath. The standard's rule is simple: the declared language is the language. A reviewer who reads only the expressions, not the expressionLanguage and language attributes, misses the defect entirely, which is why it usually surfaces only at the first migration or second tool.

What a senior reviewer checks

Declared versus written language. An undeclared language is XPath by definition, whatever the text looks like.
Portability. Engine-specific shortcuts for FEEL or decision binding are extensions; a second tool may not understand them.
Data typing. FEEL expressions over data typed in XML Schema need the tool to bridge the two type systems; state the typeLanguage deliberately.

## The symptom The developers replaced the analyst's prose conditions with expressions like `claim.amount > 500` and pointed a **business rule task** `Check expense policy` at a DMN decision table. On import into a second standards-conformant tool, the conditions are rejected or misread, and the decision is never called. The model has two declaration gaps. ## Gap 1: the expression language BPMN 2.0.2 sets the expression language in two places: | Where | Attribute | Default | Scope | |---|---|---|---| | `definitions` | `expressionLanguage` | `http://www.w3.org/1999/XPath` | every formal expression in the file | | `formalExpression` | `language` | inherits from `definitions` | that one expression | | `definitions` | `typeLanguage` | `http://www.w3.org/2001/XMLSchema` | item definitions in the file | Key points from the text: - The language **MUST be specified in a URI format**. - A plain `Expression` holds natural-language text and is **not executable**; a `FormalExpression` is the executable form in a specified language. - With XPath, BPMN provides **extension functions** such as `getDataObject`, `getDataInput`, `getProcessProperty` and `getActivityProperty` for reaching process data. FEEL is not defined in BPMN at all. It is defined by **DMN** (the Friendly Enough Expression Language), and DMN 1.5 identifies it with the URI `https://www.omg.org/spec/DMN/20230324/FEEL/`. A BPMN model can use FEEL because BPMN accepts any expression language named by URI, but only if it says so. ## Fixing gap 1 1. Set `expressionLanguage` on `definitions` to the FEEL URI, so every formal expression defaults to FEEL; or 2. Keep the XPath default and set `language` on each `formalExpression` that is written in FEEL. Option 1 is cleaner when the whole model uses FEEL. Mixing languages is legal, but each expression must then declare its own. Be aware that the standard's **Common Executable** conformance sub-class requires XML Schema for data types, WSDL for service interfaces and **XPath for data access**; a FEEL-based model therefore depends on tools that support more than that sub-class. ## Gap 2: calling the decision The standard describes a business rule task as a mechanism for the process to provide input to a business rules engine and get its output; its input/output specification carries the data. Two further facts matter: - The business rule task's `implementation` defaults to **`##unspecified`**, which leaves the technology open. Set it to `##WebService` or a URI identifying the technology that invokes the decision. - On the DMN side, a decision can list **`usingProcesses`** and **`usingTasks`**, the BPMN processes and tasks that use it. DMN states that this allows the relationship to be defined and validated but **does not of itself** permit the decision to be executed automatically by the process. DMN's non-normative annex describes encapsulating decisions in a **decision service** called from a BPMN task, such as a service task or business rule task, and says the business rule task is the most natural way to express this today. ## The corrected model - `definitions` declares `expressionLanguage` as the FEEL URI (and a `typeLanguage` that matches how the item definitions are written). - Every condition is a `formalExpression` in that language. - `Check expense policy` declares its data inputs and outputs, and its `implementation` names the technology that invokes the decision service. - The DMN decision lists the process and task in `usingProcesses` and `usingTasks` for traceability. ## Why the default bites even when a tool seems to cope Some tools guess the language from the text or apply their own default. The model then works in that tool and fails in the next one, because the file still says XPath. The standard's rule is simple: the declared language is the language. A reviewer who reads only the expressions, not the `expressionLanguage` and `language` attributes, misses the defect entirely, which is why it usually surfaces only at the first migration or second tool. ## What a senior reviewer checks - **Declared versus written language.** An undeclared language is XPath by definition, whatever the text looks like. - **Portability.** Engine-specific shortcuts for FEEL or decision binding are extensions; a second tool may not understand them. - **Data typing.** FEEL expressions over data typed in XML Schema need the tool to bridge the two type systems; state the `typeLanguage` deliberately.

In BPMN 2.0, can one model mix XPath and FEEL expressions?
Yes. The definitions-level expressionLanguage is only the default; each formalExpression may override it with its language attribute, given as a URI. Every expression not in the default language must then declare its own.
In BPMN 2.0, what is the typeLanguage default and why does it matter with FEEL?
typeLanguage defaults to XML Schema. If data is typed in XML Schema but expressions are in FEEL, the tool must map between the two type systems; declaring both deliberately avoids silent conversion surprises.
In DMN 1.5, does listing a BPMN task in usingTasks make the process call the decision?
No. DMN says the usingProcesses and usingTasks associations let the relationship be defined and validated but do not of themselves make the decision execute. Invocation needs a task bound to an implementation, such as a decision service.

saying these in an interview costs you the question

Believing BPMN 2.0 defaults to FEEL for conditions
Naming the expression language by a short name instead of a URI
Assuming usingTasks in DMN makes the task invoke the decision
Leaving the business rule task implementation at ##unspecified for execution
Thinking FEEL is defined by the BPMN specification

A BPMN 2.0 expense model writes its conditions in FEEL and calls a DMN policy decision, but its definitions declare no expression language; what is wrong, and how do you fix it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The symptom

Gap 1: the expression language

Fixing gap 1

Gap 2: calling the decision

The corrected model

Why the default bites even when a tool seems to cope

What a senior reviewer checks

▾common follow-ups3 questions

▾red flags5 flags

The symptom

Gap 1: the expression language

Fixing gap 1

Gap 2: calling the decision

The corrected model

Why the default bites even when a tool seems to cope

What a senior reviewer checks

answer

go deeper