CRM & Sales
Connect Pipedrive and Airtable
Close the deal in Pipedrive, run the work in Airtable, and keep both honest.
- Data flows
- 4 automated, two-way where safe
- Built with
- Pipedrive API, Pipedrive webhooks, Airtable API
- Timeline
- Live in 3 to 5 business days from scope
- Owned by
- You. Accounts, credentials and code in your name.
In short
Connecting Pipedrive to Airtable automates the handoff from a won deal to delivery, and reports progress back into the CRM. The awkward part is Pipedrive’s custom fields: they are addressed by generated hash keys rather than names, so integrations built against field labels break the moment a field is edited.
The workflows
What runs between Pipedrive and Airtable.
Each line is one automated workflow. An event in one tool, the checks and mapping in between, the action in the other, and the person who hears about it.
-
Automatic delivery setup on deal close
WhenDeal marked won in Pipedrive
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenCreate the delivery project in Airtable with contact, organisation and deal value
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Sales visibility into delivery without CRM seats for the delivery team
WhenDelivery status updated in Airtable
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenWrite a note or custom field back to the Pipedrive deal
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Reporting joined across pipeline and delivery
WhenPerson or organisation updated in Pipedrive
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenSync to the linked Airtable records, matched on Pipedrive object ID
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Renewal opportunities created from delivery milestones
WhenProject completed
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenLog the activity and create the renewal opportunity
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
Every record passes through the same stages
- 1Receive
Webhook or polling from the source tool, with a signed payload and a replay log.
- 2Validate
Required fields present, types right, record key found. Anything else goes to the review queue.
- 3Map
Fields translated to the destination schema. Enumerations, currencies and dates normalised.
- 4Upsert
Written against the record key, so a retry updates rather than duplicates.
- 5Confirm
Outcome logged. Alert if the count goes quiet. Reconciliation run nightly.
Read this first
Why the obvious route breaks.
A one-step Zap connects Pipedrive and Airtable in an afternoon. This is what goes wrong once real volume and real edge cases arrive.
Custom fields are hash keys, not names
Pipedrive exposes custom fields as generated hash identifiers. Integrations mapped against display names break silently when a field is renamed or recreated, and the failure looks like empty data rather than an error.
Pipeline stages are IDs that get reordered
Stage IDs are stable but the pipeline they belong to is not. Teams reorder and rename stages regularly, so logic keyed to stage position rather than ID misfires after any pipeline edit.
Deal, person and organisation are separate objects
A handoff needs all three plus their relationships. Fetching only the deal produces a delivery record missing the contact details the delivery team needs.
Won is not always the right trigger
Deals get marked won prematurely, then reopened. Firing delivery setup on the status change alone creates projects that should not exist, so a confirmation step or delay is usually warranted.
What it costs today
The gap, as the team feels it and as the engineer sees it.
In the team
- Won deals are handed over by forwarding an email
- Delivery asks sales for details that are in the CRM
- Sales cannot see where delivery is without asking
- Activities are logged in two places or neither
- Reporting across sales and delivery is a manual join
Under the hood
- Pipedrive webhooks fire per object, not per handoff
- Persons and organisations need separate fetches
- Custom field keys are hashes that change per account
- Two-way status updates loop without a marker
- Deleted deals need handling, not just created ones
What we wire up
The data flows.
- 01 When
Deal marked won in Pipedrive
ThenCreate the delivery project in Airtable with contact, organisation and deal value
- 02 When
Delivery status updated in Airtable
ThenWrite a note or custom field back to the Pipedrive deal
- 03 When
Person or organisation updated in Pipedrive
ThenSync to the linked Airtable records, matched on Pipedrive object ID
- 04 When
Project completed
ThenLog the activity and create the renewal opportunity
Used for
- Automatic delivery setup on deal close
- Sales visibility into delivery without CRM seats for the delivery team
- Reporting joined across pipeline and delivery
- Renewal opportunities created from delivery milestones
- Pipedrive won deal to Airtable project
- Pipedrive to Airtable sync
- Sales to delivery handoff from Pipedrive
- Pipedrive activities in Airtable
- Delivery status back to Pipedrive
- Pipedrive CRM automation
Built with
Data map
What becomes what, and what it is keyed on.
| In Pipedrive | In Airtable | Matched on | Direction |
|---|---|---|---|
| Deals | Delivery or Projects table | Pipedrive deal ID | two-way |
| Persons and organisations | People and Accounts tables | Pipedrive ID | one-way |
| Activities | Tasks table | Activity ID | one-way |
| Delivery status | Deal custom field | Deal ID | one-way |
Field-level mapping is agreed in the blueprint and written into the runbook. Two-way rows carry loop protection so a write from the sync never re-triggers the sync.
In every build
What you get with the sync, whichever pair.
Under the hood
- Upserts keyed on the record
Every write is matched on the source ID. A retry or a re-fire updates the existing record instead of creating a second one.
- Retries with backoff
Rate limits and timeouts are retried with increasing delays, then parked for review, never dropped.
- Idempotent, loop-safe writes
Two-way flows carry a marker so a change written by the sync does not re-trigger the sync.
- Reconciliation
A nightly job compares counts and totals on both sides and lists any record that differs.
- Audit log
Every run records input, mapping result, action taken and who or what triggered it. Searchable by record.
- Error monitoring
Loud failures alert within minutes. Quiet ones are caught by an outcome count that alerts when it stops moving.
- Review queue
Records the sync is not sure about land in a screen a person can read, correct and release.
- Scoped credentials
One credential per connection, limited to the objects it needs, stored encrypted, in your account.
For the team
- Slack or email notifications
The alerts go to a named person, not a channel nobody reads. You choose Slack, email, WhatsApp or all three.
- A runbook
One document per integration: what it does, what each alert means, and what to do in the first ten minutes.
- Training
A live session with the people who will use the review queue, recorded for whoever joins later.
- Handover
Admin access, billing and code sit in accounts in your name from day one. If we leave, it keeps running.
- Sixty days of hypercare
The engineers who built it stay on call after go-live, fix what breaks and tune what the team asks for.
- A monthly report
Runs, records synced, exceptions handled, and what changed. Plain language, one page.
Security and your data
Where the data goes, and who holds the keys.
- Accounts
- Every platform account is created in your name. We work through managed access you can revoke.
- Credentials
- Stored encrypted in the orchestration layer. Scoped per connection. Rotated on handover.
- Data in transit
- TLS everywhere. Webhooks verified by signature before anything is processed.
- Data at rest
- Only what the sync needs. No copies of your customer data on our machines.
- AI steps
- Where an integration uses a model, it is through a business API that does not train on your data.
- Retention
- Run logs kept 90 days by default, adjustable. Payloads redacted of card and ID numbers.
- Agreements
- DPA and NDA on request. Regional rules covered in our privacy policy.
Keys and sensitive data
How API keys, tokens and personal data are handled.
- Keys live in a vault, never in code
API keys and tokens are stored in the orchestration layer's encrypted credential store or the platform's secret manager. None are written into workflows, repos, spreadsheets or chat.
- One credential per connection
Each integration gets its own key, scoped to the objects and actions it needs. A lead sync cannot read invoices. Revoking one key stops one thing.
- Service accounts, not personal logins
Connections use a dedicated service user in your account, so nothing breaks when a person leaves and nothing runs under someone's name.
- Two-factor on every account
Every platform account we set up has two-factor authentication on, with recovery codes handed to you, not kept by us.
- Rotation on handover and on request
Keys are rotated when the build is handed over, when anyone with access leaves, and at any time you ask.
- Secrets never reach the logs
Audit logs redact tokens, card numbers, government IDs and anything you flag as sensitive before a line is written.
- Webhooks verified before processing
Inbound calls are checked against the sending tool's signature. Unsigned or stale payloads are dropped and counted.
- Access you can see and revoke
Our access is through managed roles in your accounts. You can list it, limit it, and remove it in one click without touching the build.
Engineering decisions
Decided before the first workflow is written.
- Rate limits and backoff
Every API has a ceiling. Calls are batched, queued and retried with increasing delays so a busy hour does not become a failed one.
- Backfill and pagination
The first run has to load history, not just new events. Backfills page through the source in order, resume after interruption, and never double-write.
- Out-of-order and duplicate events
Webhooks arrive twice and out of sequence. Each event carries a version or timestamp, and older versions never overwrite newer state.
- Schema changes
A renamed field or a new dropdown value is the most common silent failure. Payloads are validated against a contract, and a mismatch stops the run and raises a flag.
- Time zones, currencies, units
Dates are stored in UTC and shown local. Money carries its currency. Quantities carry their unit. Conversions happen once, in the map step.
- Sandbox first
Builds run against sandbox or test accounts with seeded data before they touch production. Go-live is a switch, not a rewrite.
- Versioned and reversible
Workflows and code are version-controlled. A release can be rolled back in minutes without losing the records processed since.
- API deprecations watched
Tools retire API versions on a schedule. We track the dates for every connection in the runbook and upgrade before the cut-off.
- Cost per run known
Each workflow has a cost per execution, including any model calls, logged alongside the run. You see the bill before it arrives.
- Metrics, not just errors
Runs per hour, records in and out, exception rate and latency are charted. Trends show a problem before an alert does.
The offer
Hire SBD to connect Pipedrive and Airtable.
A fixed scope, agreed in a thirty-minute call, and live in three to five business days. Accounts in your name. The engineers who built it on call for sixty days after.
- ScopeThirty minutes to agree the flows, the fields and the owner. Written up the same day.
- Build4 workflows, the data map above, validation, upserts, retries and reconciliation.
- Go-liveSandbox first, then a switch. Day three to five from scope for most pairs; longer only if a tool needs approval, such as WhatsApp templates.
- HandoverRunbook, training session, alerts to a named owner, admin access and code in your accounts.
- AfterSixty days of hypercare, then a care plan or run it yourself.
Questions
What people ask about this pair.
How do you handle Pipedrive custom fields safely?
We resolve field hash keys at build time and store the mapping explicitly, rather than matching on labels. We also validate the mapping on each run, so a renamed or deleted field raises an alert instead of quietly syncing blanks.
Can we trigger on something other than deal won?
Yes. Any stage change, activity, or custom field update can be the trigger. In practice a short delay or an explicit confirmation field is safer than firing on won, because deals do get reopened.
Is this different from Pipedrive’s own automations?
Pipedrive automations work well inside Pipedrive. They cannot create structured, linked records in Airtable or handle retries across systems, which is where a dedicated integration layer earns its place.
Related
-
HubSpot and Airtable
Sales stays in HubSpot, delivery runs in Airtable, and neither team re-types the other’s data.
-
Zoho Books and Airtable
Invoice from the event that earned it, and see what is outstanding without opening Books.
-
Airtable and Retool
Airtable is a good database and a limited interface. Retool fixes the second half.
- Solution
Consulting and agencies
Every workflow we automate for this kind of team.
Pipedrive and Airtable
The handoff, done by the system, with nothing missing.
Won deals arrive in Airtable with person, organisation and custom fields attached, and delivery status writes back to the deal, built in three to five business days.
Start with a thirty-minute call