Camunda 7 - Unknown property used in expression

Camunda 7 Topics
,
1

org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: ${newDelegate}. Cause: Cannot resolve identifier ‘newDelegate’
at org.camunda.bpm.engine.impl.el.JuelExpression.getValue(JuelExpression.java:63)
at org.camunda.bpm.engine.impl.el.JuelExpression.getValue(JuelExpression.java:51)
at org.camunda.bpm.engine.impl.bpmn.behavior.ServiceTaskDelegateExpressionActivityBehavior$3.call(ServiceTaskDelegateExpressionActivityBehavior.java:107) - camunda 7.21 and spring boot 3.4.7 is used

2

Hi @Ujjwala_Jape ,

Diagnosis: Cannot resolve identifier 'newDelegate'

The stack trace tells us precisely what is happening:

  • ServiceTaskDelegateExpressionActivityBehavior means your Service Task is configured with a delegate expression, i.e. in the BPMN: camunda:delegateExpression="${newDelegate}".
  • JuelExpression.getValue() is the JUEL engine trying to evaluate ${newDelegate}.
  • Cannot resolve identifier 'newDelegate' means the EL resolver chain looked for something named newDelegate (first a process variable, then a Spring bean) and found nothing.

So the engine could not find a Spring bean (or process variable) named newDelegate.

Possible sources (reflection)

I considered these 7 candidate root causes:

  1. Bean name mismatch — the delegate class exists but its Spring bean name is not exactly newDelegate (e.g. class is NewDelegate but annotated @Component("newDelegateService"), or the class name doesn’t camel‑case to newDelegate).
  2. Missing stereotype annotation — the delegate class has no @Component/@Service/@Named, so no bean is registered at all.
  3. Outside component scan — the delegate is in a package not covered by @SpringBootApplication component scanning, so the bean never gets created.
  4. Spring–Camunda EL integration not active — the process engine is built from a plain ProcessEngineConfiguration/StandaloneProcessEngineConfiguration (or a custom bootstrap) that does not register the Spring ApplicationContextElResolver. Without it, JUEL can only see process variables, never beans.
  5. Typo / casing in the BPMN — the model references ${newDelegate} but the bean is actually ${NewDelegate} or similar.
  6. Engine bootstrapped before beans / wrong ApplicationContext — the engine uses a different context than the one holding the bean.
  7. Version incompatibility — Camunda 7.21 officially targets Spring Boot 3.2 (7.22 → 3.3, and Spring Boot 3.4 support only arrived in 7.23‑alpha3). Running the camunda-bpm-spring-boot-starter for 7.21 on Spring Boot 3.4.7 is an unsupported combination that can cause the auto‑configuration (CamundaBpmAutoConfiguration) to not fully apply — which in turn means the SpringProcessEngineConfiguration and its bean EL resolver are never wired in.

Two most likely causes

  • #1/#2/#3 — the bean named newDelegate simply isn’t available to the engine (wrong name, missing annotation, or not scanned). This is by far the most common trigger for this exact message.
  • #7 → #4 — the Spring/Camunda auto‑configuration didn’t apply because of the 7.21 + Spring Boot 3.4.7 version mismatch, leaving the engine without Spring bean resolution. Your explicit mention of the versions makes this a strong secondary suspect.

Validation steps (to confirm which one it is)

Since the workspace here has no source files, please run these checks in your project to validate:

  1. Confirm the bean name & registration. In the delegate class, verify:
    @Component("newDelegate") // or a class literally named NewDelegate implementing JavaDelegate
public class NewDelegate implements JavaDelegate { ... }
    Then add a startup log to prove the bean exists and the engine is Spring‑backed:
    @Autowired ApplicationContext ctx;
@EventListener(ApplicationReadyEvent.class)
public void check() {
  System.out.println("newDelegate present? " + ctx.containsBean("newDelegate"));
}
  2. Confirm Spring EL integration is active. Log the engine configuration class at startup:
    @Autowired ProcessEngine engine;
// ...
System.out.println("Engine config class = " +
    engine.getProcessEngineConfiguration().getClass().getName());
    If it is not a SpringProcessEngineConfiguration (e.g. it prints a Standalone... or generic config), the Spring bean resolver is missing → cause #4/#7.
  3. Confirm versions. Check that you are using org.camunda.bpm.springboot:camunda-bpm-spring-boot-starter:7.21.0 and note that it is not certified for Spring Boot 3.4.7.
3

Hi Aravindh, Thanks for reaching out. I will try validation steps. Thanks