Flow.Documentation
Architect

Flow as the glue between systems

11 steps± 8 minVideoVerified 22 Oct 2026
  1. Step 1 · Open your development environment
  2. Step 2 · A table for what Flow keeps itself
  3. Step 3 · A connection to the CRM that may write
  4. Step 4 · The front door: an API with an endpoint
  5. Step 5 · Give a sample sign-up
  6. Step 6 · Remove the direct line
  7. Step 7 · Record the sign-up in Flow
  8. Step 8 · Pass it on to the CRM
  9. Step 9 · Put the steps in order
  10. Step 10 · Save and test
  11. Step 11 · Who decides what

The most built pattern: something comes in through an API, a workflow records it and passes it on to another system. You build a sign-up form integration: POST /sign-ups → workflow → a Flow table and the CRM. Along the way the trade-offs: what you keep in Flow and what not, and who decides who may come in and what may go out.

Watch the whole guide as a video11 steps in one film
Step 1 / 11

Open your development environment

The pattern in one sentence: the API decides who may come in, the workflow decides what happens, the connection decides what may go out. Three places, three responsibilities.

  1. Click Development
Open your development environment · Click Development
  1. Click Open ↗
Open your development environment · Click Open ↗
Step 2 / 11

A table for what Flow keeps itself

Record in Flow only what Flow needs to do its work and account for it: here which sign-up came in and whether the CRM received it. The customer belongs in the CRM — that stays the source. Two sources for the same fact always drift apart.

  1. Click Add to General
A table for what Flow keeps itself · Click Add to General
  1. Click New table
A table for what Flow keeps itself · Click New table
  1. Click Settings
A table for what Flow keeps itself · Click Settings
  1. In Name, type Sign-ups
A table for what Flow keeps itself · In Name, type Sign-ups
  1. Click Save structure
A table for what Flow keeps itself · Click Save structure
Step 3 / 11

A connection to the CRM that may write

The CRM's address and key live in a connection, not in the workflow: that way they differ per environment and nobody sees the key. Read and write because the workflow creates contacts; a read-only connection refuses every POST.

  1. Click Connections
A connection to the CRM that may write · Click Connections
  1. Click **General HTTP API Your own API Any REST API with a base URL and a key. Use it in **
A connection to the CRM that may write · Click **General HTTP API Your own API Any REST API with a base URL and a key. Use it in **
  1. In Name, type CRM
  2. In Base URL, type http://127.0.0.1:56848
  3. In Secret, type ••••••••
A connection to the CRM that may write · In Name, type CRM; In Base URL, type http://127.0.0.1:56848; In Secret, type ••••••••
  1. Click Read and write
A connection to the CRM that may write · Click Read and write
  1. Click Save
A connection to the CRM that may write · Click Save
Step 4 / 11

The front door: an API with an endpoint

Create an API with a POST endpoint on it. ＋ New workflow creates the workflow behind it right away (trigger → answer), links it and opens it. The API's policy — an API key by default — decides who may submit the form.

  1. Click Add to General
The front door: an API with an endpoint · Click Add to General
  1. Click New API
The front door: an API with an endpoint · Click New API
  1. In Name, type Sign-ups
  2. In Base path, type /sign-ups
The front door: an API with an endpoint · In Name, type Sign-ups; In Base path, type /sign-ups
  1. Click Save API
The front door: an API with an endpoint · Click Save API
  1. Click ＋ Endpoint
The front door: an API with an endpoint · Click ＋ Endpoint
  1. In Name, type New sign-up
The front door: an API with an endpoint · In Name, type New sign-up
  1. Click ＋ New workflow
The front door: an API with an endpoint · Click ＋ New workflow
The front door: an API with an endpoint · The workflow behind the endpoint: Event trigger → API response.
Step 5 / 11

Give a sample sign-up

Click the trigger. At the top you see how the workflow comes in (via POST on the endpoint). Put a sign-up under Sample data, so you can test without a real call.

  1. Click the Event trigger
Give a sample sign-up · Click the Event trigger
  1. Click Code
Give a sample sign-up · Click Code
  1. In Sample data, type {"name": "Ada Street", "email": "ada@example.com"}
Give a sample sign-up · In Sample data, type {"name": "Ada Street", "email": "ada@example.com"}
Step 6 / 11

Remove the direct line

Two steps go between trigger and answer. Click the connection and remove it.

  1. Click the connection
Remove the direct line · Click the connection
  1. Click Remove connection ×
Remove the direct line · Click Remove connection ×
Step 7 / 11

Record the sign-up in Flow

A Table step adds one row with the name from the request. That way you can always see later what came in, even if the CRM was down for a while.

  1. Click Add node
Record the sign-up in Flow · Click Add node
  1. Click Table
Record the sign-up in Flow · Click Table
  1. In Table, choose Sign-ups · 0
  2. In What does this step do? Look up rows Get one row (by id) Add one row Add rows fr, choose Add one row
  3. In name, type {{name}}
Record the sign-up in Flow · In Table, choose Sign-ups · 0; In What does this step do? Look up rows Get one row (by id) Add one row Add rows fr, choose Add one row; In name, type {{name}}
Step 8 / 11

Pass it on to the CRM

An HTTP request step through the CRM connection: POST /contacts with name and email. The path goes after the connection's base URL; Flow adds the key itself.

  1. Click HTTP request
Pass it on to the CRM · Click HTTP request
  1. In Connection (optional), choose CRM
  2. In Method, choose POST
  3. In URL or path, type /contacts
Pass it on to the CRM · In Connection (optional), choose CRM; In Method, choose POST; In URL or path, type /contacts
  1. Click Code
Pass it on to the CRM · Click Code
  1. In Body, type {"name": "{{name}}", "email": "{{email}}"}
Pass it on to the CRM · In Body, type {"name": "{{name}}", "email": "{{email}}"}
Step 9 / 11

Put the steps in order

Record first, then pass on, then answer. That way a sign-up is already in Flow before the CRM is called; if that call fails, the run shows exactly where and you can do it again.

  1. Click out: trigger
Put the steps in order · Click out: trigger
  1. Click in: table
Put the steps in order · Click in: table
  1. Click out: table
Put the steps in order · Click out: table
  1. Click in: HTTP request
Put the steps in order · Click in: HTTP request
  1. Click out: HTTP request
Put the steps in order · Click out: HTTP request
  1. Click in: API response
Put the steps in order · Click in: API response
Step 10 / 11

Save and test

A test run of a workflow behind an endpoint runs with that endpoint's security: what works here will work for a real consumer too. At the bottom: the row in the table, POST → 201 from the CRM, and the answer.

  1. Click Save
Save and test · Click Save
  1. Click Run
Save and test · Click Run
Save and test · POST → 201: the CRM has the sign-up.
Step 11 / 11

Who decides what

The dependencies show the glue: endpoint → workflow → table and connection. If the CRM later wants to report back through a webhook, that becomes a second endpoint with a policy of its own (a signature), not an extra path in this workflow. One endpoint, one workflow: one's security never leaks through the other.

  1. Click Insight
Who decides what · Click Insight
  1. Click Dependencies
Who decides what · Click Dependencies
Who decides what · The map with the endpoint, the workflow, the table and the connection.

This guide was carried out step by step on 22 Oct 2026 by an automated test on Flow (version 3e563176).