Hi @Mulen, thanks for your suggestions! Some great ideas in here.
Wanted to clarify what issue you’re having with current dropdown output format. Do you want it to output as a instead of Option A because of the space? I’m trying to understand in what scenario you’d need to be able to compare/ inform logic based on identifying an a vs doing same logic but just checking for Option A ? I could see it potentially help the WF be a bit more future proof if you change the user-facing label for “Option A” (but other than that; can’t think of a big benefit).
In terms of a solution for that, for each dropdown question what if we had a “Simple output” toggle. True by default; when set to “false” outputs each dropdown response as an object, like
{
"response_index": 0 // user selected first option in list
"response_label": "Option A"
//Future metadata could also be shown here
}
So that you can label what ever you want but the value is that you can take on the next node and do some logic.
Maybe there is an example like this
<label for="service">Choose a Service:</label>
<select name="service" id="service">
<option value="saas">Software as a Service</option>
<option value="paas">Platform as a Service</option>
<option value="managed">Fully Managed Service</option>
</select>
As you can see, when someone submit the form, i don’t want to take the label Platform as a Service to do the logic, nor try to find the right array index. Just take the index key named paas and do some logic.
Thanks for clarifying @Mulen . Is there any technical reason why you can’t do logic and be using a value that includes spaces? e.g. `if(“Option 1” == “Option 1”) still evaluates to true (for example in IF node or an expression; ofc one of the values would be a variable but evaluates to “Option 1” ultimately)
Or is it more of a preference, that you’re used to working with cleaner/ safer keys for logic?
I believe it’s more like a best practice to use cleaner / safer keys as you say to do logic. In our current setup we use these keys and match them from our database. In our database we have values: saas, paas, managed, so it’s easier to do logic without using the labels of these values
Thanks so much for the extra context! Especially the point about how those might already be the keys in other systems; so this way you don’t have to maintain a mapping between them. That along with feeling like more of a best practice are great reasons and IMO definitely improve UX in those cases.
I recommend you submit each of your requests above as a separate feature request. That way users can vote on each one (also if scope is more modular; it’s easier for us to accept a request and implement).
A quick note about the Date Field Type.
That field is an HTML input of type date, so the date formatting is set automatically based on the locale of the user’s browser.
Does this solve your request to define how to render the date, or do you still need to define how to render a date? (ignoring the user’s browser default).
Hey @giulioandreini Here are some my suggestions for improving the n8n Form Trigger with these features:
Time Period Selection:
Add fields for selecting a start and end date, or a duration, which can dynamically filter options based on user input.
Integrate a dropdown or a time picker to specify the time range (morning, afternoon, evening) for better scheduling options.
Allow custom time intervals (e.g., 15-minute or 30-minute blocks) to match specific appointment needs.
Calendar Display for Specific Date or Time Period:
Embed a calendar widget directly within the Form Trigger interface where users can view available slots and choose dates within a defined time frame.
Enable a date-range filter for users to view available appointments only within the specified period (e.g., one week, one month).
Include a color-coding or highlight feature to differentiate between available and booked slots within the calendar.
Enhanced Form Fields:
Add dynamic fields that show or hide based on the date/time selections, allowing for a streamlined booking process.
Include validation logic to restrict date or time selections to only available slots or working hours.
These enhancements would make the Form Trigger more powerful for use cases like appointment scheduling, event booking, and resource reservation.
I realize I may be asking for quite a bit here, and I hope it doesn’t come across as too demanding! These are just ideas that I believe could make the n8n Form Trigger even more versatile and user-friendly. Thank you for considering these suggestions, and I appreciate all the hard work that goes into making this tool better with each update!
Hi @Ruslan_Yanyshyn
Thanks for sharing your suggestions
I added notes to our internal documentation to be sure we keep track of all these.
While the current version of the form node is far from what you requested I want to share a similar use case I experimented with.
I wanted to build a form to book meetings.
I used an agent to come up with a list of proposed date/time for a meeting and injected these into a dropdown on the form page.
The agent uses a calendar tool to retrieve the list of my existing calendar events for the next 14 days and it is required to come up with some available slots for the meeting to book (that don’t overlap with existing events).
The tool could be improved to return a more readable list to the agent that seems confused by all the data returned by Google Calendar, but probably with some tuning, this could work pretty well.
Hey @giulioandreini,
Thank you so much for considering my suggestions and sharing your approach—it’s really inspiring and could be very useful for my use case as well! I love the idea of using an agent to generate available times from calendar events; it’s a clever solution. I made a few prompt adjustments, and it’s working perfectly.
One challenge I still see, though, is the lack of a visual calendar view for users. A calendar view would add clarity, making it easy to see available slots at a glance and select dates/times intuitively.
Thanks again for your help! I’m excited to see how this feature evolves!
