Flow als lijm tussen systemen

Het patroon in één zin: de API beslist wie erin mag, de workflow beslist wat er gebeurt, de verbinding beslist wat eruit mag. Drie plekken, drie verantwoordelijkheden.

Leg in Flow alleen vast wat Flow nodig heeft om zijn werk te doen en te verantwoorden: hier welke aanmelding er binnenkwam en of het CRM hem kreeg. De klant zelf hoort in het CRM — dat blijft de bron. Twee bronnen voor hetzelfde gegeven lopen altijd uit elkaar.

Het adres en de sleutel van het CRM staan in een verbinding, niet in de workflow: zo verschillen ze per omgeving en ziet niemand de sleutel. Lezen en schrijven omdat de workflow contacten aanmaakt; een verbinding die alleen leest, weigert elke POST.

Maak een API en daarop een POST-endpoint. ＋ Nieuwe workflow maakt meteen de workflow erachter (trigger → antwoord), koppelt hem en opent hem. Het beleid van de API — standaard een API-sleutel — bepaalt wie het formulier mag insturen.

Klik de trigger aan. Bovenaan ziet u hoe de workflow binnenkomt (via POST op het endpoint). Zet onder Voorbeeldgegevens een aanmelding, zodat u kunt testen zonder echte aanroep.

Tussen trigger en antwoord komen twee stappen. Klik de verbinding aan en verwijder hem.

Een stap Tabel voegt één rij toe met de naam uit de aanvraag. Zo kunt u later altijd zien wat er binnenkwam, ook als het CRM even plat lag.

Een stap HTTP request via de verbinding CRM: POST /contacts met naam en e-mail. Het pad komt achter de basis-URL van de verbinding; de sleutel voegt Flow zelf toe.

Eerst vastleggen, dan doorgeven, dan antwoorden. Zo staat een aanmelding al in Flow voordat het CRM wordt aangeroepen; mislukt die aanroep, dan ziet u in de run precies waar en kunt u hem opnieuw doen.

Een testrun van een workflow achter een endpoint draait met de beveiliging van dat endpoint: wat hier lukt, lukt straks ook voor een echte afnemer. Onderin: de rij in de tabel, POST → 201 van het CRM, en het antwoord.

De afhankelijkheden laten de lijm zien: endpoint → workflow → tabel en verbinding. Wil het CRM later via een webhook terugmelden, dan komt daar een tweede endpoint met een eigen beleid (handtekening), niet een extra pad in deze workflow. Eén endpoint, één workflow: de beveiliging van het ene lekt nooit via het andere.