Idea: Enable n8n nodes to map values using nodename.variablename for all nodes, including non-adjacent ones, configurable in node settings, instead of json.variablename for directly connected nodes.
Use Case: When mapping values from a previous node, json.variablename is used for directly connected nodes, but nodename.variablename for others. This inconsistency causes mappings to break if nodes are rearranged or new nodes are inserted. Using node names consistently ensures mappings remain valid.
Benefit: Prevents broken mappings during workflow changes, enhancing reliability and ease of maintenance.
Resources: n8n Docs on Expressions (https://docs.n8n.io/expressions/) for current mapping behavior.
Willing to Work: Not specified, open to community contribution.
Note: Upvote to prioritize this request.
Dont use $json, only use nodename, even for adjacent ones. Problem solved.
No problem solved since the drag and drop mapping uses json.
nothing solved
So you expect the drag and drop to just use nodename instead of json?
Yes. That makes absolute sense since as soon as I inject another node between the one that mapped with json. the reference doesnt adjust…
when I rename a node all references adjust that as well. But not with the json.
This is what I am saying
I can’t speak for the team, but I think the best way to handle this would be set an option to force the named reference when you connect a node, instead of the $json reference. This would preserve the existing functionality that wouldn’t break anything, but would allow you and others to enable this consistent, and more flexible approach. I would prefer this approach also
maybe if you vote for it yourself it would help 
1 Like
thought this happens automatically but thanks
@rhyswynn yes exactly there is also advantages of the json.variablename when you have multiple paths leading into the same input and you want to reference that.
But an option alone would be great.
I think thats what the merge node is expected to be used for, so your json is the source, and the original node name is irrelevant. That doesnt help with complex reorganization of a workflow, but multiple incoming inputs could cause your node to try to handle each input separately, and based on how things work in n8n, it seems like an anti-pattern to avoid.
Well I am not talking about merge nodes or what not… Just the fact that you attach a node onto another and then reference/map a datapoint it says json.value if I then insert a node in between those 2 the reference of that former last one may no longer be valid … thats the problem. Simple as