I would like to suggest two improvements to the way outputs are handled.
Simpler error management:
Right now I see we can have an error trigger on a separate workflow.
Which I find not very flexible + it requires additional workflows when I could just have one node with a push notification or something.
Unless I’m mistaken, it seem to be the only way to manage errors without tinkering with a “always output data” + “if” node.
I would suggest the following:
Instead of having the setting to select an error workflow, we could have a settings switch to activate error path:
I find myself crowding workflows with set nodes just to limit the number of fields in my workflow, or to rename the values. I think set nodes should really be necessary when needing to modify the value itself (like using .replaceAll, etc.).
I think it would be great if we could select the output format (both the existence of the field + the field title) using something like this:
Thanks a lot for that! Something similar to that got discussed before, and we even updated the internal data structure around 1.5 years ago to make something like that possible. Sadly it would potentially require some manual work to make that behavior possible for most nodes. Esp. the older ones. For all new ones who got created in the declarative design, that would be very simple. That said, it could potentially not be too implement that.
Anyway, a short tip until something like that got implemented. It does not totally solve it, but maybe it makes it easier in some cases:
It is not required that you create a separate Error Workflow and set it as such via the Workflow Settings. What you can also do, is create an Error Trigger Node in the same workflow. n8n will then use the same workflow as its own Error Workflow.
First one would be nice to have indeed. I don’t mind using error workflows though, as it makes sure your error handling is done in one place. @jan also posted a great tip on having it in the same workflow which could help you out a little bit.
The second one I was very annoyed with, which is why I created a PR for the Rename keys node and now also developed a community node with a keep only renamed slider. If you only input a current key it will just simply grab the field and not rename it. It doesn’t solve everything, but makes it a little bit simpler to deal with than set nodes where you have to name and set the value.
Also adds the option to use a template for your renaming.
@Joachim_Brindeau love this Funnily enough I had a very similar concept already in my head. Generally am a big fan of these sort of semantically labelled node outputs.
