Airtable Automations

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me automations attached to my own data, replacing the ones bundled with a table product.

The idea is right: the automation belongs beside the rows it watches, not in a separate service that polls them. Everything below is about making it reliable, because an automation that fires twice is worse than one that does not fire.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker process, separate from the web process
- Caddy in front

THE DATA MODEL
- automations: id, table_ref, name, trigger_json, conditions_json, steps_json, is_active, created_at
- runs: id, automation_id, row_id, trigger_payload_json, status, started_at, finished_at, error, dedupe_key
- step_runs: id, run_id, step_index, input_json, output_json, status, error, ms
- queue: id, run_id, run_at, attempts, locked_by, lease_expires_at
- Every step's input and output stored. When a customer gets an email they should not have, that record is the only thing that explains it

THE TRIGGER, WHICH IS WHERE THIS GOES WRONG
- A row created, updated, or entering a condition; a schedule; a webhook
- **Fire from the same transaction that made the change**, by writing a queue row inside it. Not from polling, which is late and duplicates, and not from a database trigger that can fire twice
- A row updated twice in a second should produce one run, not two: debounce per row with a short window
- 'Entering a condition' means the condition was false before and true now. Comparing only the new value fires every time the row is touched, which is the classic bug in this category

RELIABILITY
- The queue is a table with a lease. A crashed worker's run is reclaimed rather than lost
- Retries with exponential backoff and jitter, and a dead-letter list with a one-button replay
- **Idempotency for anything with an effect in the world.** A step declares whether it is safe to retry; one that is not carries an idempotency key through to the service it calls
- Deduplication on the trigger, so a redelivered webhook runs once

THE STEP THAT SENDS EMAIL, WHICH DESERVES ITS OWN RULE
- **A per-recipient daily cap, enforced centrally.** An automation looping over a filtered view is how somebody receives four hundred messages, and it happens to everybody once. This costs an afternoon and prevents a very bad day
- Every send recorded with the recipient, the template and the payload
- A test mode that renders the email and does not send it

THE INTERFACE
- The automation as a sentence: when this, if that, do these
- A run list with failures first, each expandable to every step's input and output
- **A dry run against a real row**, showing what would happen without doing it. That is the feature that makes people trust it enough to turn it on

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, SMTP_URL, ENCRYPTION_KEY
- Migrations on boot, each once; payloads pruned on a stated retention
- Health endpoint reporting queue depth, oldest unlocked run and expired leases

WHAT MATTERS MOST
The transactional trigger and the mail cap. The first stops runs being missed or doubled; the second stops one mistake becoming four hundred emails.