Records from forms and emailed PDFs, kept in one place that stays right
Pick one tool as the source of truth for customer records, and have every other tool copy from it. In this system I built, that tool is Airtable. Records from forms and emailed PDFs land there once, with incomplete ones held for a person. HubSpot is then updated from Airtable after an opt-out check.
The same customer in three tools, and none of them agree
A lead fills in the form on your website, and their details land in a spreadsheet. Later the same person emails you a PDF, which someone types into HubSpot with a different spelling. Now the spreadsheet, the email and HubSpot each hold a version of that customer. Nobody can say which one is right, so every report built on them is a guess.
What is proven and what is not yet
| What it does | Status | How I know |
|---|---|---|
| It works with the real Airtable, HubSpot, Gmail, Google Sheets and Telegram, and the AI that reads the PDFs | Proven | On 2026-09-16 I ran it against each of those services for real, on accounts I own, with test records. |
| Sending the same batch again changes nothing in Airtable or HubSpot | Proven | I re-sent a batch on 2026-09-16. The record already stored was found unchanged and skipped, so Airtable wasn't written to and HubSpot was left alone. |
| An incomplete record is set aside, and I get an alert saying what's missing | Proven | On a live run, a record with no name and a broken email address was kept out of Airtable. The Telegram alert named both problems. |
| The opt-out check runs against real HubSpot | Proven | On live runs, each contact's opt-out setting was read from the real HubSpot account before the update step. |
| A fault found in a live run was fixed and run again | Proven | An emailed PDF held more than one new record. The step that looks records up in Airtable gave one answer for all of them, so the run stopped. I changed it to answer each record on its own. On the re-run on 2026-09-16, every record reached Airtable and HubSpot. |
| A backup alert fires when a run fails outright | Proven | It fired on real failures: an empty PDF, and the lookup fault above. Each time, a separate workflow logged the error and sent me a Telegram alert. |
| Every alert and log row leads back to the run that made it | Proven | On a live run on 2026-09-16, the alert ended with a link to its run. The run summary and log rows carried a run reference I can search for. |
| Marking each intake email as read once it's handled | Not yet proven | I added this step on 2026-09-16 and it hasn't run live yet. It needs the next emailed PDF. |
| The alert when the log sheet is down | Not yet proven | It needs Google Sheets to be out of reach, and that hasn't happened yet. |
| The scheduled check that compares Airtable with HubSpot | Not yet proven | It reads only the first page of HubSpot contacts across the whole account. On my test account it reports a mismatch every time it runs. Its summary sends no alert until it counts only the contacts this system created. |
| Handling a bad attachment on its own | Not yet proven | Today a broken PDF stops its whole batch. The failure alert catches it, and the good PDFs behind it wait until the bad email is moved out of the intake label. |
| Skipping a real opted-out contact | Not yet proven | The skip has only run in a test where I set HubSpot's answer to opted out. Then the HubSpot update step never ran. A real opted-out contact hasn't come through yet. |
| Recovering from a real HubSpot error | Not yet proven | I forced a HubSpot failure in a test run. The step retried, then logged the record as a handled failure. A real error sent back by HubSpot hasn't come up yet. |
What you get at handover
- It runs in an n8n account you own, signed in to your own Airtable, HubSpot, Gmail, Google Sheets, Telegram and AI model accounts.
- Your records stay in your Airtable and HubSpot, and the run log stays in a sheet you own.
- A setup guide that walks through connecting each account, so the system can be rebuilt from it.
- A step by step guide that says what each part does, for whoever runs it.
- A summary of each run's counts, and a Telegram alert when a record is set aside or a run fails.
All of its parts exist in full. The label itself says nothing about live runs.
The logic ran on sample data, with stand-ins for the outside services.
Every outside service it uses was exercised for real on test accounts I own, including failures and reruns.
Running for a client, on the client's own accounts. Nothing I have built is there yet.
Questions
Which tool becomes the one that's right?
Airtable, in the version I built. Every record is written there first, then HubSpot copies from Airtable. It runs one way only, so an edit made straight in HubSpot doesn't flow back. If your records live somewhere else, like Google Sheets or another CRM, I'd rebuild that piece for your tool. Then I'd test it again before you rely on it.
What happens to a bad record?
A record that's incomplete, like one missing a name or a valid email address, is set aside before it reaches Airtable. A Telegram alert names what's missing, so it can be fixed and sent again. The good records in the same batch carry on.
Does it touch contacts who opted out?
It checks each contact's opt-out setting in HubSpot before updating HubSpot. If they opted out, Airtable still keeps their record, and HubSpot is left alone.
What if I run the same batch twice?
Airtable and HubSpot stay as they were. Duplicates inside one batch are cut down to one copy first. Each record is then compared with the version already in Airtable, and an unchanged record is skipped.
Have you set this up for a business like mine?
Not yet. I built it and tested it against the real services on accounts I own. No client runs it today, so your install would be the first.
Related
- Duplicate contacts: why your CRM keeps making two of everyoneDuplicates come back after every cleanup because each intake lane creates its own records. One match rule, checked before any record is created, stops that.
- Two tools, two truths: which system is the source of truthWhen two tools disagree about a client, pick one owner tool for each field, let changes flow one way from it, and send edits made elsewhere back to the owner.
- Source of truthThe one system whose copy of a record wins when two tools disagree. Why it matters for opt-outs and phone numbers, and how a one-way sync keeps it that way.
- Dedupe keyA dedupe key is the field a system uses to decide two records are the same person or company. Which key to pick, an example, and what goes wrong without one.
- What a reliable automation looks likeFive properties any automation should have, checkable by an owner who doesn't build: logged runs, named alerts, one send per approval, safe reruns, an owner.
- n8n template library for service businessesEvery workflow template I have ready to show for service businesses, with its stage and how far it has been tested. None is offered as a download yet.
- The reporting bottleneck: writing what changed, every monthSomeone still writes what changed and why, every month. Draft it from the report's own numbers, mark the guesses, and let the account lead sign off.