Connect Make and Airtable: search, create and update intake records

Choose an immutable intake key

The target behavior is one Airtable record per submission: create on the first delivery and update on a later delivery of the same request. Use a stable request_id rather than a name or an email address. This is a proposed implementation and test plan, not a report of account execution. Keep human notes outside the fields owned by the workflow.

- Sample input: request_id=REQ-1001, subject=Brochure request, status=new.

- Destination fields: Request ID, Subject, Received at and Processing status.

Scope the connection and prepare field types

Create a practice base and an intake table before configuring the Airtable connection in Make. Authorize the base needed for this exercise, checking the permissions of the connection method you select. Treat identifiers as text, timestamps as dates and status as a controlled selection. A field with the correct name but an incompatible type can still reject the write.

Handle an empty search deliberately

Search Records should look for the exact request ID. Restrict the identifier format rather than inserting arbitrary submitted text into a formula. Inspect whether the module can continue with an empty result. If zero matches produce zero output bundles, the router after it never runs; simply drawing a create branch does not solve that case. Configure and test an explicit no-match path before adding downstream actions.

Distinguish zero, one and multiple matches

Create a Record when there is no match. With one match, pass the returned Record ID into Update a Record. Send multiple matches for review instead of silently editing the first record. A search limit of one hides duplicates, so allow enough results to detect ambiguity. Where the search emits separate bundles, collect the result count before making the create-or-update decision.

Map fields without erasing manual work

Map request_id to Request ID, subject to Subject and received_at to Received at. Only overwrite fields the automation owns. Missing input is different from an instruction to clear a value: test both separately. Preserve notes added by a colleague, and define an explicit clearing action if the business process needs one. Confirm that selection values exist before enabling routine writes.

Check repeats and concurrent arrivals

Submit REQ-1001, repeat it unchanged and then change its subject. The proposed acceptance result is one record with an updated subject. Also consider two arrivals at once: both searches may return zero before either insert finishes. Search followed by create is not an atomic uniqueness guarantee. Serialize the intake or establish uniqueness in another system if concurrent duplicate creation would be unacceptable.

Reconcile writes and estimate ongoing work

Test a denied connection, an invalid selection and a failure after creation has succeeded. Keep the returned record ID alongside the intake ID so recovery can resume from the completed write. Estimate searches, creates, updates, aggregation and retries separately; these are calculations until measured in your account. For simple form collection, Airtable alone may suffice. Add Make when the cross-service steps justify the extra workflow and maintenance.

• Build an Airtable enquiry tracker: intake, owners and follow-up states
• Prevent duplicate writes in Make with stable keys and recovery states
• How to estimate Make credits: polling, rows and retries