Nightly target accounts refresh from Crustdata to Airtable

Build a deterministic nightly data sync workflow that keeps an Airtable Target Accounts table in sync with current Crustdata firmographics. The workflow runs on a cron trigger every night at 2am local time. Every step is a known node, no LLM reasoning is required.

Step 1. Read every record from the Airtable Target Accounts table using Airtable List Records, paginating through the full table via the offset cursor until exhausted. Each row already has a company domain field and an Airtable record ID. Skip rows with an empty domain.

Step 2. Chunk the collected domains into groups of 25 (Crustdata Enrich Company accepts up to 25 comma-separated company_domain values per request). For each chunk, call Crustdata Enrich Company with fields=headcount,headcount_change_last_90_days,funding_and_investment,largest_headcount_country,industry,decision_makers. Run these chunk calls strictly sequentially, never in parallel: Crustdata enforces a leaky-bucket rate limit that trips fast on parallel fan-out. Add a small delay between chunks if needed. Track which domains return a match and which return no result.

Step 3. For every domain that matched, build an Airtable update payload keyed on the original record ID with the refreshed values: headcount, headcount_change_last_90_days, funding_stage (from funding_and_investment.last_funding_round_type), last_funding_date (from funding_and_investment.last_funding_round_date), largest_headcount_country, industry, and decision_makers_count (length of the decision_makers array). Before writing, compare the new headcount to the previous value already stored in Airtable and capture how many records moved by more than 10 percent in either direction. Send the updates back via Airtable Update Multiple Records in batches of 10, matched on Airtable record ID. Do not use upsert; these are existing rows.

Step 4. For every domain that returned no match (Crustdata 404 or empty response), call Airtable Update Record on that single row to tick a needs_review checkbox field to true. Do not overwrite any existing data on those rows.

Step 5. After all updates are written, post one Slack message to the configured ops channel using Slack Send a Message. The message should be one line in this format: "Account refresh complete: {refreshed_count} refreshed, {big_change_count} with headcount change over 10 percent, {failed_count} failed lookup." The team uses this single line to confirm the sync ran cleanly.

Inputs the workflow needs to be configurable: the Airtable base ID, the Target Accounts table ID, the names of the domain field, the record ID source, the needs_review checkbox field, and each refreshed column; the Crustdata API key; the Slack channel ID; and the headcount change threshold (default 10 percent).

This is a pure data sync pattern with discrete deterministic nodes: read, batch, enrich, write, flag, notify. Do not introduce an LLM step. Do not parallelize the Crustdata calls. Keep the failure flow strict: a single batch failure should not abort the whole run, it should just record those domains as failed and continue.