I would like to have a “n8n Form Trigger” node with the dropdown option filled already including external values received from an “HTTP request” (I have this last part fully developed and working).
I have no clue how to approach this problem, since that node is a trigger type, and I cannot link something behind (that is to say, before the form).
Is there any form to achieve it? and if so, which may be the best way?
Thanks beforehand, sorry for the inconveniences, and looking forward to hearing from you.
Kind regards.
Daniel.
Information on your n8n setup
n8n version: 1.41.1
Database (default: SQLite): The default one, SQLite
n8n EXECUTIONS_PROCESS setting (default: own, main): I guess the default one.
Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
Thank you very much again for your reply and also for your patience, I trully appreciate it.
So, according to what you say, I would need two separated workflows, am I right?
One to gather the information from the third-party API that will be shown later.
Another one where the n8n form trigger will be launched to the user with the data previously received.
Ok, on the surface, that makes sense, but deep down, what I do not understand is how to link both processes: when the first one will be launched? How that can be linked to the second one?
Here is an example, that uses one workflow as a source and updates it afterward. You can manually build the desired workflow with a Form trigger, download its content via the n8n get node, change options for the form trigger to include additional fields, and then update the workflow.
You can add a schedule node to run this workflow for whatever time you need.
I @dpergarc I have a question. What is exactly your need:
You want one of the options in the dropdown (previously added in the n8n Form node) to be pre-selected based on what you retrieve from the HTTP Request node, or…
You want the options of the dropdown to be coming from the HTTP Request node. So those options should not be previously added manually, but be dynamic.
Thank you very much for your replies, to both of you.
Regarding your question @giulioandreini, what I need is the following sequence, let me show you some pictures from a demo I have prepared in HTML + CSS + Javascript, which is currently working, and that is what I am trying to replace using the n8n platform:
I have a menu to perform some actions (“Add model”, “Delete model” and “Back to index”).
Once the “Delete model” button is pressed, the form jumps to another one, and loads information in its select field which is gathered from a third-party API.
And eventually, perform the action with the selected choice information.
So far, I have completed the 1-2 jump with n8n. I have all requests ready to read all models and delete the choosen one, but I do not have the select with the information loaded.
I hope this may clarify what I want to accomplish, if we might fully complete this little demo, n8n will be tested, and it is highly likely to be used in a PoC for a project. I am quite new to n8n, so forgive me beforehand if I do not get everything quick.
Hi @dpergarc
your use case is a bit tricky and not that easy to do.
We’re currently adding some functionalities to the n8n Form node and that’s why I was asking for more details, to be sure this use case will be easily doable in the future.
I suggest double-checking the solution posted by @barn4k
An alternative could be to use the Wait node that allows you to create another form that you can show as a second form page. Check this example below and see if it helps:
In a nutshell the logic is:
The first form node is set to respond using the “Respond to Webhook” node
You can then use a switch node or add the login you want
The respond to webhook node then is triggered when the form is submitted and is set to redirect to the URL $execution.resumeFormUrl. This URL will open a form set by the following Wait node
Give it a try and let me know if this solves your problem
Thank you very much for your reply, I trully appreciate it!
Regarding your suggestions, I am afraid that this use case has been rejected to be used in the early project phases since it appears to be a little more complicated that we expected… but do not worry, I will take it as a strong consideration in case we return to this approach (I will let you know if that is the case).
Again, thank you very much for your support, and sorry for the inconveniences!
