Form not available via Camunda Run deployment

Hi All,

I am evaluating Camunda Run v7.16 as a possible deployment option in our BPM system (in development).

I have a business process that references its start-form with this form-key: "embedded:deployment:StartForm.html"

This works perfectly fine when I deploy the BPMN and the form from the Camunda Modeller. I can start a new process from Tasklist and the start form is displayed.

Then, I try to use the auto-deploy feature of Camunda Run (copy BPMN and form files into the configuration/resources folder all get deployed when Camunda Run starts).

I modified the start-form reference to this key: "embedded:deployment:/StartForm.html"

(as Camunda Run instructions note the form keys in the docs:

The Camunda Run logs show that it has deployed both the process and the form. However, when I try to start a process, it cannot load the start form (Error message: Form failure: The form with the resource name ‘/StartForm.html’ cannot be found in deployment with id XXXX.).

How do I deploy forms with Camunda Run so that they can be referenced from the process?

Hi @asoltesz,

please have a look at this thread: Make pdf file visible in tasklist

Hope this helps, Ingo


Thank you for your help.

I have read the linked topic through and tried the tips in it. Nothing worked (not surprising, see below).

After that, I managed to make it work doing this:

  • stopped Camunda Run
  • dropped the H2 database (deleted the files in the camunda-h2-default folder)
  • set the form key to “embedded:deployment:/StartForm.html” (as the docs say)
  • start Camunda Run

After this, the deployment could be found in Cockpit and it contained all of the forms and the BPMN process. When I start a new process instance, the start-form is found and displayed properly.

So far so good, the big problem is what happens next:

I change something in the process definition BPMN file (something not form-related, like changing the display name of a task).

Restart Camunda Run.

After this, I cannot start a new process instance anymore, it cannot find/display the start-form.

Checking the deployment in Cockpit, I can see that there is a second deployment for SpringAutoDeployment but it only contains the BPMN file.

Camunda Run didn’t deploy the forms for the second run, only the BPMN file (probably because only that was changed between the two deployments).

This seems to be a bug in Camunda.

Either Camunda Run should always deploy all of the files, or the form-lookup mechanism should be able to follow the deployment chain somehow and recognize that there was a form deployed earlier in a previous deployment.

For others bumping into this:

I found two problems with the Camunda Run deployments when it comes to embedded forms:

Incremental deployment
Camunda Run sets the “deploy changed only” flag for the engine (setDeployChangedOnly(true); in

This seems unnecessary and causes the form redeployment bug when form references are rendered inoperable when a process-only change is deployed as part of a second-deployment.

NOTE: when all of the files are unchanged there will be NO new deployment anyways, since the “deployment duplicate filtering” feature is still active in the default deployment config (which is a better mechanism than “deployed changed only”, see the REST API /deployment for details).

The starting “/” in the form resource path in the form-keys (like "embedded:deployment:/StartForm.html).

Again, this seems to be unnecessary and breaks compatibility with the Modeller deployment (especially when all resources are in a single folder).

Seems like more of a bug to me in than something the Camunda team actually wanted. One more character could be chopped off when the deployment resource name is constructed from the absolute filesystem path of the resource (and that would make it unnecessary to put the “/” in the form keys). That way Modeller deployment and Spring Boot deployment result in the same deployment resource names (except: resources in subfolders)

I simply ported the engine initialization classes from Camunda Run (sources here: and fixed the above two problems for our own Spring Boot process app.

If you need to use Camunda Run (not your own SpringBoot app), you can fork the repo and fix these for yourself.