Names, emails, companies, and rows shown in code blocks are synthetic fixtures.
They are examples, not customer records or live customer activity.
Validated connector routes
The following routes were exercised through the MantrixFlow browser workflow with real source previews and destination verification:
This is a functional verification matrix, not a throughput benchmark. Validate
your own field types, permissions, row volume, and rate-limit behavior before a
production rollout.
Shared preparation
Create and test these reusable connections:- An Airtable source connection with schema and record read access.
- An Airtable destination connection with schema read plus record read and write access. One token can be reused for both roles when your security policy permits all required scopes and bases.
- A MySQL source connection with read access to the source database.
- A MySQL destination connection with write access to the destination database and its existing tables.
Prepare reusable test data
Airtable source table
Create an Airtable table namedCustomers with these fields:
Enter at least three records. Keep
External ID unique and populated.
Airtable destination table
Create a separate table namedPipeline Sink with these writable fields:
Do not use a formula or lookup as
External ID; merge fields must be writable.
MySQL source table
MySQL destination table
Airtable to MySQL
1. Create the pipeline
- Open Data Pipelines and click New Pipeline.
- Name it
Airtable Customers to MySQL. - Choose the Airtable source connection and create the pipeline.
2. Configure Airtable source
- Open Source.
- Click Load bases and select the base containing
Customers. - Select the
Customerstable. - Preview rows and confirm
_airtable_record_id,External ID,Name, andEmailappear. - Keep Full table mode and click Save stream settings.
3. Configure MySQL destination
- Open Destinations, click Add destination, choose the MySQL connection,
set the target database to
analytics, and save. - Open Transformations, select the MySQL destination, and create a model using the Airtable source stream.
- Use this SQL, replacing the staging relation with the exact lowercase value shown in the editor:
- Save draft, Validate draft, Preview output, and Publish revision.
- Return to the destination editor.
- Under Published output targets, set
analytics.airtable_customersand selectexternal_idas the Upsert key. - Create/verify the table if needed, then save the destination.
4. Run and verify
Validate the pipeline from Overview, click Run all, and wait for Succeeded in Runs. Then run:MySQL to Airtable
1. Create the pipeline
- Create a pipeline named
MySQL Customers to Airtable. - Choose the MySQL source connection.
2. Configure MySQL source
- Open Source and click Discover catalog.
- Enable
source_app.customers. - Preview the three test rows.
- Use Full table for the first run and click Save stream settings.
3. Add the destination and publish the model
Open Destinations, add and save the Airtable destination connection. Then open Transformations, select it, create a transformation using the MySQL stream, and use:4. Map Airtable destination fields
- Return to the Airtable destination editor.
- Click Load bases, select the destination base, and choose
Pipeline Sink. - Under Published output targets, map fields:
- Save the destination, validate from Overview, and click Run all.
5. Verify Upsert
OpenPipeline Sink in Airtable and filter External ID by mysql-. Confirm
all three records and their mapped values. Update mysql-002 in MySQL, rerun,
and confirm Airtable updates the same record rather than creating a duplicate.
Airtable to Airtable
Use separate source and destination tables, even when they are in the same base. ConfigureCustomers as the source and Pipeline Sink as the destination.
external_id to External ID and select it as the merge key. The prefix
prevents collisions with IDs from MySQL, Stripe, HubSpot, or other pipelines
sharing the same sink table.
Run checklist
Before each run, confirm:- both connections still pass their connection tests;
- source discovery shows the expected table;
- preview returns representative rows;
- the published SQL model uses the staging name shown by the transformation editor;
- the database table or Airtable table already exists;
- every destination column has a compatible type or field mapping;
- the Upsert key is unique and populated for every output row; and
- the Runs tab reports
failed rows = 0.
Common errors
Production rollout
After a successful Full Table validation:- Record the source count and destination count.
- Rerun unchanged input and confirm no duplicates.
- Update a source record and confirm an in-place destination update.
- Review the token and database grants for least privilege.
- Set an operational schedule only after the manual run is stable.
- Monitor Runs for row-count changes, retries, and mapping failures.