The wait node in “On Form Submitted” mode is the only way to use forms within workflows (in contrary to the form trigger node which can only be used at the beginning). To fully use this strength, I would suggest following improvements:
Dynamic form fields:
Form requirements can change depending on the preceeding workflow execution. Thus, it would make sense to add the option to “Define Form Fields Using JSON” like in the “Next Form Page” node. Example use case: I would like to add a dropdown field whose values (and the number of values) is determined by the preceeding workflow (in my case a list of customers from our CRM) - thus, dynamic values would be handy.
Customization options
The form trigger node has various customization options like “Button label” or “Custom Form Styling”. The same options would make perfect sense in the wait node.
Multi-step forms
Last but not least, forms would be truly powered up if the wait node in form mode could be used in combination with the “Next Form Page” node to create multi-step forms within workflows.
The dynamic customer dropdown is a useful example. For a concrete acceptance test, generate two waiting executions with different customer lists and verify each form shows only its own options; submit a value that was removed or never offered and ensure it is rejected server-side. Stable IDs as option values would also avoid ambiguity when two customers share a name. For multi-step forms, it would help to specify what happens when someone refreshes, goes back, abandons a session, or submits twice. Finally, an expiry and access-control story matters if the form exposes customer data.
Thanks for your elaboration of the testing requirements. I want to clarify that the above mentioned ideas are 3 independent feature requests.
The first one (dynamic form fields) is the most important as this would unleash the full power of using forms WITHIN a workflow (again, I guess the option “Define Form Fields Using JSON” is not available in the form trigger node as all field settings must be static here by nature). The most important use case should be when users are supposed to choose values from a discrete value list whose number of values and the values themselves are unknown before workflow execution. Besides dropdowns, this also affects other discrete fields like checkboxes, radio buttons and maybe HTML.
The other two ideas are logical consequence of form node functionality that is still missing in the wait node. Since this functionality is already present in the form nodes, requirements (and maybe even some of the implementation/code) can be re-used from them. I was hoping that at least the customization options could be implemented easily this way.
Thanks for your consideration. Let me know if you have further questions or need support on this.
