Node name limitations

Adjustable node width or multi-line labels
Persistent tooltips on hover
Canvas display settings for label truncation
Use case: workflows with descriptive naming conventions for documentation/debugging

The idea is:

My use case:

Multiple, related workflows that are dependent on name specificity.

I think it would be beneficial to add this because:

This would save multiple clicks to find and copy names in workflows with name dependencies.

Any resources to support this?

The suggestions were literally generated from a conversation with the native AI in n8n.

Are you willing to work on this?

Absolutely.

Limiting node name width makes reading difficult, especially in complex workflows. Being able to adjust the width or have multi-line labels would be really helpful, as well as persistent tooltips to avoid constant clicking. It would be a real efficiency boost if the team could add this soon.

1 Like

Having a schedule built into the Email trigger would be convenient to avoid adding an extra node. But it would blur responsibilities: currently, the trigger’s job is to detect emails, while scheduling is handled separately. Keeping them separate makes workflows clearer and more modular.

I think that is completely a use case specific issue for example, if a workflow was designed to, “do something” with emails, ie-create, answer, evaluate, ect then you are correct but most workflows have zero to do with emails (at least on the front end) and are used in cases where a schedule is the most efficient option. Like scheduling a flow to upgrade a DB overnight. For complex workflows that call other workflows, some components the schedule makes sense, some, triggering by a call from another workflow, some manual. From almost 30 years experience in dev, the oldest and most accurate answer to most questions is, “It depends…” :slight_smile:

1 Like

Your reply made me smile, because that’s exactly what I say all the time as well: “it depends.”
And I 100% agree with you.

My point isn’t that there should be a single, imposed solution, but rather that depending on the workflow (complexity, dependencies, readability), certain UI choices can quickly become friction points.

In simple workflows, this isn’t really an issue. In more complex workflows, especially those that rely heavily on naming conventions, readability becomes critical. That’s why having configurable options makes more sense than a fixed behavior.

1 Like

Absolutely! Thanks for the clarity.

1 Like