I have created a form for a user task which includes two buttons in zeebe modeler. Here is the JSON equivalent of the form-{
“components”: [
{
“action”: “submit”,
“label”: “Approve”,
“type”: “button”,
“id”: “Field_0f0mu1w”,
“key”: “field_0y1wz2q”,
“properties”: {
“reprocess”: “yes”
}
},
{
“action”: “submit”,
“label”: “Reject”,
“type”: “button”,
“id”: “Field_1apba7f”,
“key”: “field_11q9gd5”,
“properties”: {
“reprocess”: “no”
}
},
{
“label”: “Text Field”,
“type”: “textfield”,
“id”: “Field_0zjy388”,
“key”: “field_06vuzgg”
}
],
“type”: “default”,
“id”: “Form_19en23x”,
“executionPlatform”: “Camunda Cloud”,
“executionPlatformVersion”: “8.1.0”,
“exporter”: {
“name”: “Camunda Modeler”,
“version”: “5.4.1”
},
“schemaVersion”: 5
} But when this user task is shown in the camunda tasklist ,the buttons are missing whereas the text field is shown as it is. Can anyone help me with this issue?
Hi @Sarath_S1 , we discouraged the use of form buttons in 8.4.alpha1, since they are not feature-complete at the moment.
There is a generic submit button at the bottom of each task in Tasklist. Adding your own buttons would create duplicate buttons, and the user could submit without approval or rejection state.
However, we are planning to bring “real” outcome actions to Tasklist, such that you can simply define the outcomes like “approve” or “reject” on the user task level, without the need to design them in the form.
Meanwhile, you need to use a radio group to capture the outcome in a variable.
Best,
Christian
Addition: The recent Desktop Modeler shows this in the problems panel. I see you are still on version 5.4, so I recommend you to update 
in that case,
If I have a “TEXT AREA” which is “require” if “Clarify” is selected, but “NOT REQUIRED” is “Approved” is selected. How to implemented it in the camunda modeller for forms.
@gauravmeena the required field is not currently dynamic, so such behavior would not be supported at the moment.
One option would be to use the hide conditions and have 2 text areas (one that is mandatory and another one that is not) to solve that - is not exactly ideal but would be a workaround for such behavior.
Please let me know if that helps, I will have a chat with the team about making the required field dynamic.
Thanks.