Edit Fields (Set) in n8n: Felder umbauen und mappen

Daten kommen selten in genau der Form, in der das nächste System sie braucht. Der Kontaktname heißt in der einen Quelle full_name und im CRM Name, ein überflüssiges Feld schleppt sich mit, ein anderes fehlt, ein Wert liegt als Text statt als Zahl vor. Genau dieses Umformen zwischen zwei Schritten erledigt in n8n der Edit-Fields-Node – das unscheinbarste und zugleich meistgebrauchte Werkzeug im ganzen Baukasten. Dieser Artikel zeigt Ihnen, wie er arbeitet und wo die typischen Fallen liegen – für alle, die selbst an Workflows bauen oder verstehen wollen, was unter der Oberfläche passiert.

Was der Edit-Fields-Node macht

Der Edit-Fields-Node setzt Workflow-Daten: Er legt neue Felder an und überschreibt vorhandene. In älteren n8n-Versionen hieß er schlicht „Set“, die aktuelle Bezeichnung laut Dokumentation ist „Edit Fields (Set)“ – beide meinen denselben Knoten. Sein Platz im Workflow ist fast immer die Fuge zwischen zwei Systemen: Eine Quelle liefert Daten, der Edit-Fields-Node bringt sie in die Struktur, die der nächste Schritt erwartet, und reicht sie weiter. Umbenennen, ergänzen, aussortieren, berechnen – alles ohne eine Zeile Code.

Der Edit-Fields-Node – in älteren n8n-Versionen „Set“ – ist das Standardwerkzeug, um Daten umzuformen: Er legt Felder an, überschreibt und benennt sie um und entscheidet über die Einstellung „Include in Output“, welche der ursprünglichen Eingangsfelder mitlaufen. Für einfaches Mapping zwischen zwei Systemen reicht er; komplexe Logik gehört in den Code-Node.

Manual Mapping: Felder per Klick anlegen

Ganz oben im Node wählen Sie den Modus: Manual Mapping baut die Felder über die Oberfläche, JSON lässt Sie rohes JSON schreiben. Für die allermeisten Fälle ist Manual Mapping richtig.

Der schnellste Weg zu einem Feld: Ziehen Sie einen Wert aus dem INPUT-Panel per Drag-and-drop in ein Feld. n8n übernimmt dann den Namen des Werts als Feldnamen und legt als Wert einen Ausdruck an, der genau diesen Wert referenziert. Jedes Feld besteht aus Name, Typ und Wert. Als Typ stehen fünf Optionen zur Wahl: String, Number, Boolean, Array und Object. Der Typ ist kein Kosmetik-Detail – wählen Sie „Number“ und liefern einen Text, versucht n8n zu konvertieren, und genau daran scheitern Workflows still.

Feste Werte oder Ausdrücke

An jedem Feld – sowohl beim Namen als auch beim Wert – blenden Sie per Umschalter zwischen Fixed und Expressions um. „Fixed“ trägt einen konstanten Wert ein, etwa Quelle = Website. „Expressions“ öffnet die volle Ausdruckssprache: Sie referenzieren Felder aus dem Eingang oder aus früheren Nodes, verketten sie oder rechnen.

Zwei Beispiele aus der Praxis:

• Anzeigename bauen: ein neues Feld name mit dem Ausdruck, der Vor- und Nachname zusammensetzt.
• Feld umbenennen: ein Feld email anlegen, dessen Wert auf das Eingangsfeld E-Mail-Adresse zeigt – der alte Name verschwindet, der Inhalt bleibt.

Dass sich auch der Feldname als Ausdruck setzen lässt, ist der Grund, warum der Edit-Fields-Node beim Anbinden fremder Systeme so oft die halbe Arbeit macht: Sie mappen einmal von der Quellstruktur auf Ihre Zielstruktur, und alles danach rechnet mit sauberen, erwartbaren Feldnamen. Wer Leads aus unterschiedlichen Kanälen zusammenführt, kennt das Muster aus dem Beitrag Leads sauber ins CRM übernehmen.

Der häufigste Stolperstein: Include in Output

Die Einstellung, an der die meisten hängen bleiben, heißt Include in Output (in neueren Versionen als Schalter „Include Other Input Fields“). Sie entscheidet, was mit den Feldern passiert, die Sie nicht ausdrücklich definiert haben. Standardmäßig kann der Node alles verwerfen, was Sie nicht selbst gesetzt haben – und dann wundern sich Leute, wohin ihre restlichen 20 Felder verschwunden sind.

Die Optionen laut n8n-Dokumentation:

Einstellung	Wirkung
All Input Fields	Alle unveränderten Eingangsfelder laufen zusätzlich mit
No Input Fields	Nur die oben definierten Felder verlassen den Node
Selected Input Fields	Zusätzlich nur die namentlich gelisteten Felder
All Input Fields Except	Alle Felder außer den gelisteten

Meine Faustregel: Bevor Sie einen Edit-Fields-Node speichern, schauen Sie bewusst auf diese Einstellung. Wollen Sie nur ein paar Felder ergänzen und den Rest durchreichen, brauchen Sie „All Input Fields“. Wollen Sie eine schlanke, kontrollierte Struktur an das Zielsystem geben – etwa bevor Sie Daten vor der Automatisierung normalisieren –, ist „No Input Fields“ das Mittel, um keinen Datenmüll mitzuschleppen.

JSON-Modus: wenn es komplexer wird

Reicht das klickbare Mapping nicht, schreiben Sie im JSON-Modus direkt das JSON, das n8n den Eingangsdaten hinzufügt. Das ist der Weg für verschachtelte Strukturen: Arrays, Objekte, mehrere Ebenen – alles mit Ausdrücken belegbar. Ein Zielsystem, das eine Adresse als eigenes Unterobjekt erwartet, bauen Sie so in einem Rutsch:

{
  "name": "{{ $json.full_name }}",
  "adresse": {
    "stadt": "{{ $json.city }}",
    "plz": "{{ $json.zip }}"
  }
}

Als Faustregel: Solange Sie flache Felder anlegen oder umbenennen, bleiben Sie bei Manual Mapping – es ist übersichtlicher und leichter zu warten. Verschachtelte Zielstrukturen oder dynamisch aufgebaute Objekte sind der Punkt, an dem der JSON-Modus die klarere Wahl ist.

Kleine Optionen, große Wirkung

Unter „Add Option“ verstecken sich Einstellungen, die selten gebraucht werden, aber im Ernstfall den Unterschied machen:

• Support Dot Notation (standardmäßig an): Ein Feldname wie number.one wird als verschachteltes Objekt interpretiert und ergibt { "number": { "one": 20 } }. Wer wirklich einen Schlüssel mit Punkt im Namen braucht, schaltet die Option ab – dann entsteht { "number.one": 20 }. Das erklärt manche „warum ist mein Feld plötzlich verschachtelt“-Überraschung.
• Ignore Type Conversion Errors (nur Manual Mapping): Lässt n8n über bestimmte Typfehler beim Mappen hinwegsehen und wendet eine weniger strenge Umwandlung an. Praktisch beim schnellen Basteln – im Produktivbetrieb nehmen Sie Typfehler lieber ernst.
• Include Binary File / Strip Binary Data: steuern, ob angehängte Binärdaten (etwa eine PDF) im Ausgang erhalten bleiben oder entfernt werden. Wichtig, sobald Dateien durch den Workflow laufen.

Edit Fields, Code oder Merge – welches Werkzeug?

Der Edit-Fields-Node ist mächtig, aber nicht für alles gedacht. In Gesprächen mit Betrieben sehe ich regelmäßig, dass Leute ihn zum Schweizer Taschenmesser umbauen, obwohl ein anderer Knoten die Aufgabe sauberer löst. Die grobe Aufteilung:

• Edit Fields (Set): geradliniges Umformen – Felder anlegen, umbenennen, mappen, aufräumen.
• Code-Node: echte Logik, Schleifen über verschachtelte Strukturen, alles, was in Ausdrücken zu unübersichtlich wird.
• Merge: zwei Datenströme über einen Schlüssel verbinden – das ist ein eigenes Thema, ausführlich im Beitrag zwei Datenquellen zusammenführen.
• IF / Switch / Filter: Datensätze nach Bedingungen auf verschiedene Pfade leiten, statt sie umzubauen – siehe Workflows verzweigen.

Als Faustregel: Sobald Sie im Edit-Fields-Node anfangen, mit Ausdrücken zu programmieren, ist meist der Code-Node die wartbarere Wahl. Der Edit-Fields-Node soll den Datenfluss verständlich halten, nicht Logik verstecken.

Der ehrliche Nutzen

Der Edit-Fields-Node wirkt banal, entscheidet in der Praxis aber darüber, ob eine Schnittstelle stabil läuft oder ständig an Feldnamen und Datentypen scheitert. Wer ihn beherrscht – Mapping, Include in Output, die richtige Modus-Wahl – spart sich einen Großteil der typischen „warum kommt im Zielsystem Unsinn an“-Fehlersuche.

Wenn Sie gerade überlegen, welche Prozesse sich in Ihrem Betrieb überhaupt sauber automatisieren lassen, oder eine bestehende n8n-Umgebung ordentlich aufsetzen wollen: In einem kostenlosen Prozess-Check schauen wir uns Ihren konkreten Fall gemeinsam an. Und wenn Sie tiefer in die Umsetzung wollen, finden Sie in der n8n-Beratung den passenden Rahmen dafür.