Bi-directional sync begint niet bij de tool
Een bi-directional sync werkt pas als je weet welk systeem de waarheid is. Google Sheets mag bijvoorbeeld planning bezitten, je CRM de klantstatus en je ticketingtool de supportfase. n8n koppelt die systemen aan elkaar, maar moet niet raden welke wijziging wint.
Zoek je de technische Google Sheets setup? Gebruik de Google Sheets API gids. Deze blog gaat over het sync-ontwerp: owners, conflicten, loops en logging.
Wanneer is bi-directional sync zinvol?
Gebruik twee richtingen alleen als mensen of systemen aan beide kanten echt mogen wijzigen. Een dashboard dat alleen rapporten leest heeft geen bi-directional sync nodig. Een salesproces waarin planning in Sheets staat en klantstatus in het CRM wel.
De vraag is niet: kan n8n dit technisch koppelen? Meestal wel. De vraag is: wat moet er gebeuren als twee systemen binnen vijf minuten hetzelfde veld aanpassen?
De simpele owner-regel
Kies per veld een eigenaar. Niet per systeem, maar per veld. Dat voorkomt veel twijfel.
| Veld | Eigenaar | Waarom |
|---|---|---|
| E-mailadres | CRM | Klantdata moet centraal blijven. |
| Afspraakdatum | Google Sheets | Planning wordt handmatig in Sheets beheerd. |
| Ticketstatus | Ticketingtool | Supportteam werkt daar live. |
| Laatste contactmoment | n8n | Workflow kan dit objectief berekenen uit events. |
Als je deze tabel niet kunt invullen, is de sync nog niet klaar om live te gaan.
Voorkom sync-loops met een bronstempel
De klassieke fout: n8n schrijft een update naar systeem B, systeem B vuurt een webhook terug, n8n denkt dat dit een nieuwe wijziging is en schrijft weer naar systeem A. Daarna blijft de workflow rondzingen.
Gebruik daarom een bronstempel. Zet bij elke update minimaal vast:
last_updated_by: bijvoorbeeldn8n,crmofsheets.last_synced_at: wanneer n8n de wijziging verwerkt heeft.source_record_id: de id van het record in het bronsysteem.sync_versionofupdated_at: om oudere updates te negeren.
Laat n8n updates overslaan die het zelf net heeft geschreven. Dat is saai, maar dit soort saaie regels houden productieflows overeind.
Conflictregels: automatisch, handmatig of blokkeren
Niet elk conflict hoeft menselijk werk te zijn. Maak drie niveaus:
1. Automatisch winnen
Voor velden met een duidelijke owner. Als het CRM eigenaar is van klantstatus, wint CRM. Sheets mag dat veld dan niet terugduwen.
2. Handmatige review
Voor velden met zakelijke impact, zoals prijs, contractfase of afspraakdatum. Stuur het conflict naar Slack, mail of een review-Sheet met beide waarden naast elkaar.
3. Blokkeren
Voor gevaarlijke wijzigingen. Denk aan lege e-mailadressen, ontbrekende klant-id's of een status die teruggaat van betaald naar open zonder betalingsevent.
Een veilige n8n-flow voor sync
- Trigger op webhook of Schedule Trigger.
- Haal het bronrecord op.
- Haal het doelrecord op met dezelfde externe id.
- Vergelijk alleen de velden die deze sync mag beheren.
- Check owner-regels en timestamps.
- Schrijf alleen echte verschillen weg.
- Log elke overslag, update en conflictregel.
Gebruik de HTTP Request node als de standaard app-node niet genoeg controle geeft over headers, pagination of batchupdates. Voor eenvoudige Sheets-acties is de Google Sheets node meestal sneller.
Wanneer geen bi-directional sync gebruiken?
Gebruik geen twee richtingen als één systeem duidelijk leidend is, als er geen record-id aan beide kanten bestaat, of als je niet kunt uitleggen welke wijziging wint. Dan is een one-way sync beter: minder indrukwekkend, maar veel betrouwbaarder.
Wil je dit laten ontwerpen voor jouw CRM, Sheets of ticketingtool? Begin met een korte inventarisatie: systemen, velden, owners, conflicten en rollbackroute. Daarna pas bouwen.