Blog

Airtable API und Zoho Flow: Historische Daten migrieren samt WorkDrive-Integration

  • Beitrags-Autor:

Von Airtable nach Zoho: So gelingt die Migration historischer Daten mit bestehender Geschäftslogik

Die Automatisierung deiner Geschäftsprozesse mit dem Zoho-Ökosystem ist ein entscheidender Schritt zur Effizienzsteigerung. Du hast vermutlich bereits komplexe Workflows in Zoho Flow oder mit Deluge-Skripten in Zoho CRM erstellt, die bei neuen Daten ausgelöst werden. Doch was passiert, wenn du Tausende von Altdaten aus einem externen System wie Airtable, einem alten CRM oder sogar aus Excel-Tabellen importieren musst? Ein einfacher CSV-Import ist hier oft der falsche Weg, denn er umgeht deine gesamte, sorgfältig aufgebaute Geschäftslogik. Verknüpfte Datensätze, Dateianhänge in WorkDrive oder Benachrichtigungen in Cliq würden nicht erstellt werden. In diesem Artikel zeigen wir dir eine praxiserprobte Methode, wie du eine große Menge an Altdaten kontrolliert migrierst und dabei sicherstellst, dass jeder einzelne Datensatz deine bestehenden Automatisierungen durchläuft.

Praxisbeispiel: Die Herausforderung der Datenkonsistenz bei der Migration

Stell dir ein typisches Szenario vor: Ein Unternehmen nutzt Airtable, um Vertriebs-Opportunities und Angebote zu verwalten. Ein etablierter Prozess sorgt über die Airtable API und einen Webhook dafür, dass jede Aktualisierung in Airtable einen Workflow in Zoho Flow anstößt. Dieser Flow ist das Herzstück des Prozesses und führt mehrere Aktionen aus:

  • Er prüft, ob im Zoho CRM bereits eine Opportunity existiert. Wenn nicht, wird sie angelegt. Andernfalls wird sie aktualisiert (Upsert-Logik).
  • Er erstellt verknüpfte Datensätze wie Angebote oder Auftragsbestätigungen.
  • Eine besonders wichtige Funktion: Er holt sich eine Dokumenten-URL aus einem Airtable-Feld, lädt die Datei herunter und speichert sie sicher in einem spezifischen Ordner in Zoho WorkDrive.
  • Anschließend generiert der Flow einen permanenten Freigabelink für das Dokument in WorkDrive und schreibt diesen Link zurück in ein Feld im Zoho CRM.
  • Abschließend wird vielleicht noch eine Aufgabe in Zoho Projects für das Onboarding angelegt.

Nun steht die Aufgabe an, etwa 6.000 historische Datensätze aus Airtable in dieses System zu überführen. Ein einfacher Import würde nur die Basisdaten ins CRM bringen, aber die gesamte Logik – insbesondere der kritische Dokumenten-Upload nach WorkDrive – würde fehlen. Die Daten wären inkonsistent und unvollständig.

Schritt-für-Schritt Anleitung zur gesteuerten Migration

Um diese Herausforderung zu meistern, verfolgen wir einen Ansatz, der nicht auf einen Massenimport, sondern auf das gezielte, wiederholte Auslösen des bestehenden Workflows setzt. So stellen wir sicher, dass jeder Datensatz den exakt gleichen, qualitätsgesicherten Prozess durchläuft wie ein neuer Live-Datensatz.

Schritt 1: Strategische Entscheidung – Zoho Flow statt DataPrep

Die erste Überlegung könnte sein, ein ETL-Tool (Extract, Transform, Load) wie Zoho DataPrep zu verwenden. DataPrep ist extrem mächtig für die Bereinigung und den Import großer Datenmengen. Für unser Szenario ist es jedoch ungeeignet, da es den bestehenden Zoho Flow umgehen würde. Die komplexe Geschäftslogik, das Feld-Mapping, die API-Aufrufe und die WorkDrive-Integration in Zoho Flow nachzubauen, wäre nicht nur zeitaufwändig, sondern auch fehleranfällig. Die bessere Strategie ist daher, den existierenden und erprobten Flow für jeden einzelnen Altdatensatz gezielt neu anzustoßen.

Schritt 2: Vorbereitung in Airtable – Das dedizierte Trigger-Feld

Damit wir den Migrationsprozess von den normalen, täglichen Änderungen in Airtable trennen können, benötigen wir einen dedizierten Auslöser. Erstelle hierfür in deiner Airtable-Tabelle ein neues Feld:

  • Feldtyp: Single line text
  • Feldname: Zoho_Sync_Trigger

Dieses Feld dient ausschließlich dazu, die Synchronisation für einen bestimmten Datensatz manuell via API anzustoßen.

Schritt 3: Anpassung der Airtable-Automatisierung

Gehe nun zu deiner Airtable-Automatisierung, die den Webhook von Zoho Flow aufruft. Bisher wurde diese vermutlich bei „When record is created“ oder „When record is updated“ (für beliebige Felder) ausgelöst. Das ändern wir nun, um die Kontrolle zu übernehmen:

  1. Ändere den Trigger der Automatisierung auf „When a record is updated„.
  2. Füge eine Bedingung (Condition) hinzu: Die Automatisierung soll nur dann ausgeführt werden, wenn sich das Feld Zoho_Sync_Trigger geändert hat.

Dadurch wird sichergestellt, dass dein Zoho Flow ab sofort nur noch dann für einen Datensatz feuert, wenn wir explizit das Trigger-Feld beschreiben. Der normale Betrieb bleibt unberührt.

Schritt 4: Das Steuerungsskript für den kontrollierten API-Aufruf

Um nicht Tausende von Datensätzen manuell zu ändern, schreiben wir ein kleines Skript, das die Airtable API nutzt, um das Trigger-Feld für uns zu aktualisieren. Dies gibt uns die volle Kontrolle über die Geschwindigkeit und das Volumen des Imports. Du kannst dafür jede beliebige Skriptsprache wie Python, Node.js oder, wie hier im Beispiel, PHP verwenden.

Das Skript wird eine Liste von Airtable Record-IDs (die du vorab als CSV exportieren kannst) einlesen und für jede ID eine `PATCH`-Anfrage an die Airtable API senden, um das Trigger-Feld zu aktualisieren.

Hier ist ein einfaches PHP-Beispiel mit cURL:


<?php

function triggerAirtableUpdate(string $recordId, string $apiKey, string $baseId, string $tableId): array
{
    $url = "https://api.airtable.com/v0/{$baseId}/{$tableId}/{$recordId}";
    
    $headers = [
        "Authorization: Bearer {$apiKey}",
        "Content-Type: application/json"
    ];
    
    // Wir schreiben einen Zeitstempel, um eine eindeutige Änderung zu gewährleisten.
    $data = [
        "fields" => [
            "Zoho_Sync_Trigger" => "SYNC-" . date('Y-m-d H:i:s')
        ]
    ];
    
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PATCH");
    curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    
    $response = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    
    echo "Triggered {$recordId} - Status: {$httpCode}n";
    
    return json_decode($response, true);
}

// --- Anwendung ---

// Deine Airtable-Daten
$apiKey = 'keyDeinAirtableApiSchlüssel';
$baseId = 'appDeinBaseId';
$tableId = 'tblDeineTableId';

// Lese Record-IDs aus einer CSV-Datei
$recordIds = array_map('str_getcsv', file('record_ids_batch_1.csv'));

foreach ($recordIds as $row) {
    $recordId = $row[0];
    triggerAirtableUpdate($recordId, $apiKey, $baseId, $tableId);
    
    // WICHTIG: Eine Pause einlegen, um die API-Limits nicht zu überschreiten!
    sleep(2); // 2 Sekunden Pause zwischen jedem Aufruf
}

?>

Schritt 5: Testlauf und sorgfältiges Monitoring der API-Credits

Bevor du alle 6.000 Datensätze migrierst, ist ein Testlauf unerlässlich. Das Hauptrisiko bei diesem Vorgehen sind die API-Limits deines Zoho-Plans (insbesondere für Zoho Flow, CRM und ggf. Creator).

  1. Exportiere eine kleine Teilmenge von IDs, z.B. 100 Stück, in eine CSV-Datei.
  2. Führe dein Steuerungsskript mit dieser kleinen Liste aus.
  3. Beobachte währenddessen deine API-Nutzung im Zoho Admin Panel. Notiere, wie viele Flow-Aktionen und wie viele CRM-API-Aufrufe für diese 100 Datensätze verbraucht wurden.
  4. Beispielrechnung: Dein Test mit 100 Datensätzen hat 2.000 Flow-Credits (20 pro Flow) und 3.500 CRM-API-Aufrufe (35 pro Flow) verbraucht. Für die gesamten 6.000 Datensätze benötigst du also ca. 120.000 Flow-Credits und 210.000 CRM-API-Aufrufe.

Schritt 6: Die gestaffelte Durchführung in Batches

Mit den Erkenntnissen aus dem Monitoring kannst du nun den vollständigen Import planen. Teile deine restlichen Record-IDs in mehrere Batch-Dateien auf, um unter den täglichen API-Limits zu bleiben. Wenn dein tägliches CRM-API-Limit beispielsweise bei 50.000 liegt, solltest du basierend auf der Beispielrechnung nicht mehr als ca. 1.400 Datensätze pro Tag migrieren. Führe dein Skript über mehrere Tage verteilt jeweils mit einer neuen Batch-Datei aus, bis alle historischen Daten sauber und vollständig in deinem Zoho-System angekommen sind.

Tipps und Best Practices

  • Daten vorab bereinigen: Nutze die Gelegenheit, um deine Altdaten in Airtable zu filtern. Schließe alte, abgelehnte oder irrelevante Angebote von der Migration aus. Das spart Zeit und wertvolle API-Credits.
  • Idempotenz im Flow sicherstellen: Gestalte deinen Zoho Flow so, dass er „idempotent“ ist. Das bedeutet, dass ein erneutes Auslösen für denselben Datensatz keinen Schaden anrichtet (z.B. keine Duplikate erzeugt). Verwende in Zoho Flow die „Fetch“- oder „Search“-Aktion, um zu prüfen, ob ein Datensatz bereits existiert, und nutze dann die „Update“- statt der „Create“-Aktion.

Ein Deluge-Snippet innerhalb einer Custom Function in Zoho CRM oder Creator könnte so aussehen, um eine Upsert-Logik zu implementieren:


// ID des externen Systems aus dem Webhook-Payload
airtableRecordId = input.get("airtable_record_id");

// Prüfen, ob bereits ein Deal mit dieser externen ID existiert
existingDeals = zoho.crm.searchRecords("Deals", "(Airtable_Record_ID:equals:" + airtableRecordId + ")");

updateMap = Map();
updateMap.put("Deal_Name", input.get("deal_name"));
updateMap.put("Stage", input.get("stage"));
// ... weitere Felder mappen

if (existingDeals.size() > 0)
{
    // Datensatz existiert: Aktualisieren
    dealId = existingDeals.get(0).get("id");
    updateResponse = zoho.crm.updateRecord("Deals", dealId, updateMap);
    info "Updated Deal: " + dealId;
}
else
{
    // Datensatz existiert nicht: Neu anlegen
    updateMap.put("Airtable_Record_ID", airtableRecordId); // Externe ID für zukünftige Abgleiche speichern
    createResponse = zoho.crm.createRecord("Deals", updateMap);
    info "Created new Deal: " + createResponse;
}
  • Sichere Verwaltung von Zugangsdaten: Speichere deinen Airtable API-Schlüssel nicht direkt im Skript, sondern nutze Umgebungsvariablen oder einen sicheren Passwort-Manager wie Zoho Vault.
  • Transparente Kommunikation: Informiere dein Team über die laufende Migration. So wundert sich niemand, warum über mehrere Tage hinweg schrittweise alte Daten im CRM auftauchen.

Fazit: Kontrolle und Konsistenz sind entscheidend

Die Migration von Altdaten ist mehr als nur ein Datenimport. Um die Integrität und den vollen Funktionsumfang deines automatisierten Zoho-Systems zu gewährleisten, ist die Erhaltung der Geschäftslogik entscheidend. Der hier beschriebene Ansatz – das kontrollierte, gestaffelte Neuauslösen bestehender Workflows über eine externe API – ist zwar aufwändiger als ein simpler Upload, garantiert aber eine 100%ige Datenkonsistenz.

Du behältst die volle Kontrolle über den Prozess, schonst deine API-Limits und stellst sicher, dass jeder einzelne historische Datensatz so behandelt wird, als wäre er heute neu erfasst worden – inklusive aller verknüpften Aktionen und Integrationen. Diese Methode zeigt eindrucksvoll, wie sich die Stärken von Zoho-Anwendungen und externen APIs zu einer robusten Lösung für komplexe, praxisnahe Herausforderungen kombinieren lassen.

Verwendete Zoho Apps in diesem Szenario:

  • Zoho CRM als zentrales System für Kundendaten.
  • Zoho Flow zur Orchestrierung des gesamten Prozesses.
  • Zoho WorkDrive für die sichere und integrierte Dateiablage.
  • Potenziell: Zoho Creator und Deluge für erweiterte Logik (Upsert-Funktionen).
  • Zur Überwachung: Das Zoho Admin Panel zur Kontrolle der API-Credit-Nutzung.