Custom Template Nodes

Given that we already have a plain HTTP Request node and many possible nodes are just plain “Make an HTTP GET/POST request to an endpoint”, what if there was a way to make a “Template Node” which users could make in order to make custom nodes.

Example: the current discord webhook node does not allow the usage of Embeds or modifying the author’s name. What if I could take an HTTP Request Node, add in the JSON body for the payload, and then use that request as a “saved template node” for future requests. This way if people wanted to work with obscure APIs they could make template nodes to save alot of time and effort.

Hey @Helithumper,

I’ve always been a fan of templates/code reuse and this sounds like another version of that so…:+1:!

While it is not a built in “feature” of n8n, you could do something similar to this by creating a flow with just a single node that you want to become your “template”. You can then configure the node and then download it as JSON.

Now, whenever you wanted to use that “template”, all you would have to do is copy and paste the JSON into the webUI and it would pre-build your node. Simply tweak and enjoy!

That is a really nifty way to do this. It does remind me of a similar issue which I think is probably the proper modification.

When creating workflows, there is no way to specify start node inputs. If I make a sub-workflow whose job is to post whatever is in parameterName=message to discord, I have to guess that the parent workflow has provided that parameter to me.

What if the start node for a workflow had a “providesInputs” parameter which could be used to define “these are the inputs for the workflow”. I think that may also solve this issue in a clean manner.

Probably for more clarity, adding a menu like appears in “set” to the “Start” node

Would you be able to get the same result by putting a set node immediately after the start node? Or am I missing something?

While that would possibly have similar execution, it wouldn’t easily document what the inputs of the workflow are. If multiple people are modifying these workflows that would get confusing. The way I see it is “functionalizing” the workflows with defined input parameters so you could essentially “call” a sub-workflow like a function where you know exactly what it should take as an input.

Say I make a workflow that goes to my inventory system and grabs the owner of an IP Address, I could make a workflow called “grab_owner” with parameter “ip_address” which I can define when using the “workflow” node. This way the person who uses my “grab_owner” workflow would explicitly know what parameters my workflow expects instead of having to find my workflow and deduce the correct parameters.

It could be that I am misunderstanding how other people have used the “workflow” node, but if that is the case then an example of using a “workflow” node with expected inputs would be greatly appreciated :slight_smile:

There was a similar discussion here:

So agree that some kind of easier and better way should exist and it will be created in the future. The Set-Node is for sure a good work-around for now but not a permanent and good solution also for the reasons you did give.

About Template-Nodes. What is planned in the future is to allow people to fuse a node-network into a single node on which then the needed inputs and parameters can be exposed. For the users it would look almost identical to a regular node but underneath the hood will not be regular-code, like under every normal node, it will be a kind of sub-workflow. This “fused-nodes” are then supposed to be easily shareable with and so reusable by other people in the community .

Okay, so it sounds like what I think the current use case of the “workflow” node is currently planned. This would be super useful as it would allow for the “functional” process as I’m thinking of it.

Hope to see that soon!

1 Like

I also :wink: I hope we have soon some resources available to tacle that!