Wie ordnest du Datenfelder in einer Make-Automatisierung richtig zu?

Kurz gesagt: Ein Datenfeld ordnest du zu, indem du das vorherige Modul einmal ausführst, den Datenbaum im Mapping-Panel bis zum tatsächlichen Feld aufklappst und dort ablegst — und danach drei Dinge getrennt prüfst: den Datentyp, ob der Wert fehlen darf, und ob mehrere Datensätze statt einem einzelnen ankommen. Wer nur den Namen des Feldes vergleicht und diese drei Punkte überspringt, bekommt am ehesten die Fehler „missing value“ oder falsch befüllte Zielfelder.

Diese Anleitung geht das an einer fiktiven Übung durch: einem Webhook, der eine Bestellung mit verschachtelten Kundendaten und mehreren Positionen entgegennimmt. Die Schritte gelten unabhängig vom Beispiel für jede Zuordnung zwischen zwei Modulen in Make.

Voraussetzungen

• Ein Make-Konto (der kostenlose Tarif reicht für die Übung)
• Ein Szenario mit mindestens zwei Modulen, wobei das erste bereits Beispieldaten liefern kann — etwa ein Webhook, eine Tabelle oder eine App-Verbindung
• Das erste Modul einmal per „Run this module only“ ausgeführt, damit Make die tatsächliche Struktur der Daten kennt. Ohne diesen Schritt zeigt das Mapping-Panel laut der Make-Dokumentation zum Mapping-Panel nur ein unstrukturiertes Ergebnis statt benannter Felder.

Fiktive Übung: eine verschachtelte Bestellung zuordnen

Angenommene Werte: Ein Webhook empfängt folgende Beispieldaten für eine Bestellung.

{
  "order_id": "A-1042",
  "customer": {
    "name": "M. Fiktiv",
    "address": { "city": "Leipzig", "zip": "" }
  },
  "items": [
    { "sku": "P-01", "qty": 2 },
    { "sku": "P-02", "qty": 1 }
  ]
}

Ziel: order_id und customer.address.city in eine Tabellenzeile schreiben, die Postleitzahl (zip) mit Rückfallwert versehen und für jede Position in items eine eigene Zeile in einer zweiten Tabelle anlegen.

Schritt 1: Das verschachtelte Feld bis zum Zielfeld nachvollziehen

Im Mapping-Panel des Tabellen-Moduls öffnest du den Datenbaum des Webhook-Moduls. customer ist dort keine ablegbare Endstelle, sondern eine Gruppe — du musst sie über das Pluszeichen aufklappen, dann address erneut aufklappen, bis city als eigener Eintrag erscheint. Erst dieses unterste Element ziehst du in das Zielfeld. Wer stattdessen die Gruppe customer oder address ablegt, bekommt eine JSON-Struktur statt eines Textwerts im Zielfeld — ein häufiger Grund für „falsch zugeordnet“, obwohl technisch etwas gemappt wurde.

Schritt 2: Datentyp separat prüfen

order_id ist Text, qty ist eine Zahl. Das Mapping-Panel zeigt den erkannten Typ neben jedem Feld an. Ein Zieltext-Feld verträgt fast jeden Typ, aber ein Zielfeld, das eine Zahl erwartet (etwa für eine Summenbildung im nächsten Schritt), quittiert einen als Text übernommenen Wert im Zweifel mit einem Berechnungsfehler in einem nachfolgenden Modul, nicht im Mapping selbst. Prüfe deshalb nicht nur, ob ein Feld befüllt ist, sondern ob der Folgeschritt mit diesem Typ etwas anfangen kann.

Schritt 3: Fehlenden Wert gezielt behandeln

zip ist im Beispiel ein leerer String. Ohne Vorkehrung landet dieser leere Wert unverändert im Zielfeld oder löst — wenn das Zielfeld im angebundenen Dienst als Pflichtfeld markiert ist — den Fehler „missing value“ beim Ausführen aus. Für ein optionales Feld trägst du im Mapping-Ausdruck einen Rückfallwert ein, etwa {{ifempty(customer.address.zip; "unbekannt")}}. Für ein tatsächlich verpflichtendes Feld ist ein Rückfallwert keine Lösung, sondern nur eine Vertuschung — dann gehört eine Prüfung vor diesen Schritt, die fehlende Pflichtangaben abfängt, statt sie stillschweigend zu ersetzen.

Schritt 4: Mehrere Datensätze getrennt vom einzelnen Feld behandeln

items ist ein Array mit zwei Positionen. Ein direktes Mapping von items in ein einzelnes Zielfeld übernimmt laut der Make-Dokumentation zum Iterator nicht automatisch beide Positionen als getrennte Zeilen. Dafür schaltest du ein Iterator-Modul zwischen Webhook und die zweite Tabelle, trägst dort items als Array-Feld ein und mappst danach sku und qty aus dem Iterator statt direkt aus dem Webhook. Das Szenario läuft dann für jede Position einmal durch das Tabellen-Modul.

Erwartetes Ergebnis

Nach diesen vier Schritten legt das Szenario eine Bestellzeile mit korrektem Ort, einer aufgelösten Postleitzahl und zwei Positionszeilen mit numerisch verwertbarer Menge an.

Fehlerprüfung: die vier häufigsten Symptome

| Symptom | Wahrscheinliche Ursache | Prüfung | |---|---|---| | Zielfeld enthält eine JSON-Struktur statt eines Werts | Gruppe statt Endelement im Datenbaum abgelegt | Datenbaum bis zum untersten Feld aufklappen | | Fehler „missing value“ beim Ausführen | Pflichtfeld im Zielmodul ohne Wert in diesem Bundle | Quelle auf leere Werte prüfen, Rückfallwert oder vorgeschaltete Prüfung ergänzen | | Nur eine Position statt mehrerer übernommen | Array direkt gemappt statt iteriert | Iterator-Modul mit dem Array-Feld einsetzen | | Folgemodul meldet einen Berechnungs- oder Formatfehler | Datentyp passt nicht zur Erwartung des Folgemoduls | Typ im Mapping-Panel prüfen, bei Bedarf mit parseNumber() oder formatDate() umwandeln |

Kontrollierst du das Ergebnis im Ausführungsverlauf des Szenarios: Jedes Modul zeigt dort Input- und Output-Bundle einzeln an, ein roter Fehlerkreis markiert das Modul, an dem es scheiterte.

Wo das nicht mehr allein mit Mapping zu lösen ist

Bei wenigen Ebenen und wenigen Ausnahmen reicht dieses Vorgehen aus. Sobald ein Feld aber von zehn verschiedenen Bedingungen abhängt oder sich die Datenstruktur der angebundenen Quelle regelmäßig ändert, wird eine rein manuelle Zuordnung schnell unübersichtlich und fehleranfällig — dann ist ein Blick von außen auf den Ablauf sinnvoller als das nächste verschachtelte ifempty().

Rechtlich eng wird es beim Testen selbst: Ohne eine wirksame Auftragsverarbeitungsvereinbarung mit Make gehören keine echten Kunden- oder Personaldaten in einen Testlauf, auch nicht anonymisiert „zur Sicherheit“ — dafür sind erfundene Werte wie im Beispiel oben da. Bei Mandats- oder Patientendaten kommen zusätzliche berufsrechtliche Anforderungen hinzu, die über eine DSGVO-Vereinbarung hinausgehen.

Der nächste Schritt

Wenn du unsicher bist, ob Make für euren Fall überhaupt das richtige Werkzeug ist oder ob n8n oder ein Eigenbau besser passt, steht die Gegenüberstellung in Make, n8n oder Eigenbau: was wann sinnvoll ist. Und wenn ihr beim Aufbau selbst nicht weiterkommt oder eine zweite Einschätzung zu einem bestehenden Szenario braucht, ist das eine Frage für die KI-Beratung — dort wird vorher festgelegt, welches Ergebnis die Beratung liefern soll, statt offen draufloszuschauen.