All form information should be able to be included via tokens in the email notifications, Not solely the inputs.
Robert, Can you please elaborate? Can you share a use case or what exactly you're trying to achieve? You can always type in the Headings and other static text directly in the editor.
Hi Mandeep
I've just re-checked my notes about this one and I got it wrong, but it is related. It all came from making a large membership form that needed to change content based on selections. The resulting notification was related to this. If you want to change the title of this suggestion to be "Live Form - Ability to include non-input fields in actions" then that would be accurate.
The issue is that that one cannot include the non-input fields as items to be displayed or hidden based on selections made in the form. One can only show or hide actual inputs.
You can confirm this by adding a heading or some instructional text to a form. Then add an action on form view to show/hide stuff. Then look for the headings or text content to be available on the list of things that can be displayed or hidden. They won't be there. This is the main issue and the suggestion is to allow those items to be included when showing or hiding things.
The original suggestion about the notification content then also came into this because I realised I would not be able to modify the submitted notification based on the selections and content displayed in the form. The notification just has to show all input results at all times. So just consider this as a secondary suggestion as it wouldn't be so easy to implement. The only way I can see it happening is if the notification could auto-generate it's content based on the form as-submitted.
So don't worry about the notifications. However, the main suggestion here, to allow non-input form content to be displayed or hidden based on selections made, is definitely one that would help a lot.
In addition - A related suggestion that I recall now that I'm looking at my form again, is that the selection inputs for choosing the show/hide fields sorts them alphabetically. This made it difficult to choose inputs that were grouped together in the form and were also repeated... e.g. the same contact information fields for multiple attendees. It would be more manageable if the fields were displayed in the order they are displayed in the actual form. Then it would be easy to select a block of inputs that belong together. I've linked a screenshot of this to show where I mean.
Hope that makes more sense now. Regards Rob
Okay. That makes sense. Ability to hide/show all fields; regardless whether they're of input type or not.
On the sorting, I believe there are plenty of use cases to keep it alphabetical.
Yep cool, getting the other fields included is good.
It is now available in v5.
Excellent, thanks!