Checkbox in a Camunda 8 connector template

I have an issue to create a checkbox for my Camunda 8 connector. I am able to model it with the type Boolean and the binding type property like described in the docs, but the process cannot be started since apparently the property is not applicable for ServiceTask type.

This is the error when starting a new instance:

Command ‘CREATE’ rejected with code ‘INVALID_ARGUMENT’: Expected to deploy new resources, but encountered the following errors:
‘My Process.bpmn’: Error: URI=null Line=4: cvc-complex-type.3.2.2: Attribute ‘something’ is not allowed to appear in element ‘bpmn:serviceTask’.[ deploy-error ] 16/5/2023 12:17:51

My json looks like this (and seems to be valid):

{
      "label": "Do something",
      "description": "Should something be done?",
      "group": "details",
      "type": "Boolean",
      "binding": {
        "type": "property",
        "name": "something"
      }
    }

Thanks in advance,
Stefan

I think for what you are trying to do, you need one of the Camunda 8 Bindings, usually zeebe:input or zeebe:taskHeader. Property doesn’t work.

For some reason none of the Camunda 8 bindings supports Boolean. We would have been completely fine with a String “true” or “false” as value. Anyway, we are using type Dropdown with true/false or yes/no. It’s not that nice, but to look at it positively: it is easily extendable, e.g. yes/no/mabe.

At least it is stated, that property is valid for both Camunda 7 and 8. I guess it is the one that should be used if you need Boolean as type. But I checked the examples and none of them has a Boolean in them. Maybe someone here from Camunda can elaborate on this?

@itsmestefanjay Could you elaborate what you try to accomplish (user/UI wise)? What would you expect to happen if the checkbox is checked or unchecked?

With property you bind to a BPMN property, such as name on a task.

Hi @nikku,

Basically I want a checkbox to set a property which is either true or false. Like the beforeAsync, afterAsync for Camunda 7. It should be then mapped to a variable in my connector request of type boolean which is true or false. The only way I was able to model it was to use property (without really knowing what it does) because it supported Boolean and generated a checkbox.

Thanks
Stefan

It should appear as an input variable? If checked then it is true, if not checked then it is false?

In this case you want an input mapping (zeebe:input), because that is what will bind to a variable at run-time. However binding zeebe:input to Boolean / checkbox is currently not supported (Support Boolean conditions in templates · Issue #768 · bpmn-io/bpmn-js-properties-panel · GitHub).

Cf.

{
  "$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema/resources/schema.json",
  "name": "BooleanBindingTemplate",
  "id": "boolean-binding-template",
  "version": 1,
  "description": "Configure boolean value for input binding",
  "category": {
    "id": "connectors",
    "name": "Connectors"
  },
  "appliesTo": [
    "bpmn:Task"
  ],
  "elementType": {
    "value": "bpmn:ServiceTask"
  },
  "properties": [
    {
      "type": "Boolean",
      "value": "= true",
      "binding": {
        "type": "zeebe:input",
        "name": "someVariable"
      }
    }
  ]
}

To validate the direction we’d like to pursue as we pick up this topic:

  • We want to allow you to bind any value if the user checked the box and provide no binding if they did not.
  • That allows us to support a large amount of use cases, including but not limited to binding basic boolean (true or not defined), expressions (set discountedPrice to = 0.9*price if discount is desired), but also static values (SOME_STATIC_STRING).
1 Like

Yes exactly. I think what you wrote up is basically what I need. Thanks for this very thorough reply. For now I can live without it. I will have an eye on the discussion.

Thanks

Hi @nikku, I’m following this thread because we had the same problems. I like your proposed solution, but it would be much more flexible if we could bind a value to checked and/or unchecked, otherwise many properties might have to be rewritten. An example: “editable” (default = true), so I would want to bind “false” to unchecked but nothing (or “true”) to checked. Otherwise I need to call the property “Not editable” and bind “false” to checked while in the backend it is still called editable, it just gets very confusing.

@cma If I understand you this is how it would look like (based on my previous example):

{
   ...
   "properties": [
    {
      "type": "Boolean",
      "value": "= false",
      "binding": {
        "type": "zeebe:input",
        "name": "someVariable"
      }
    }
  ]
}

What this would do is either bind someVariable to false (if checked) or nothing (defaulting to true or whatever default value you desire).

Thanks for the reply. So as I understand it your example would return false if the checkbox is checked. This would be the confusing workaround. What I would like to do is to say when the binding happens (on checked or unchecked). So I have the checkbox initially checked and if it gets unchecked I send a value, e.g. false. It will not work without doing a “not” for all properties that have the default value as true. So as I said before, if a property is called “editable” and default = true, then I have to name the property “Not editable” in the frontend if I want to use a checkbox, unless we can specify when the binding happens.

Taking your example, if you want checked (editable=true) to be the default, then what about using above template with, let’s say a defaultChecked extension?

{
   ...
   "properties": [
    {
      "type": "Boolean",
      "value": "= true",
      "defaultChecked": true,
      "binding": {
        "type": "zeebe:input",
        "name": "editable"
      }
    }
  ]
}

But then I still would get nothing when the checkbox is unchecked. I’m interested in when the checkbox gets unchecked. Then the binding should happen. If I get nothing or true and the default is true (also in backend) it is still true for me, I need to get false when the checkbox is unchecked. Otherwise it causes the mentioned problems.

But then I still would get nothing when the checkbox is unchecked.

That is correct, that would be the contract.

But you could extend it with something like "bindOnChecked":false (default true, false binds on unchecked) and it would solve all problems and be more flexible.

Another example: Insurance. You might want to deduct something from the price if insurance gets unchecked.

@nikku , would it make sense to overload the “Required” operator?

{
   ...
   "properties": [
    {
      "type": "Boolean",
      "value": "= true",
      "required": true,
      "binding": {
        "type": "zeebe:input",
        "name": "editable"
      }
    }
  ]
}

Such that when checked, it sets the variable to “= true” and when unchecked it sets the variable to “=false” which would then allow the workflow designer to assume that the variable will exist (and not need to null check it)