Automate Airtable to PandaDoc proposals in Make.com, map merge fields safely, dedupe creates, sync PandaDoc status back to Airtable and Slack.
Introduction
If your team builds PandaDoc proposals manually after a customer record lands in Airtable, you already know the pain. Someone copies fields, selects the wrong template once, and a blank merge field turns into a client-facing mistake. Then approvals go missing because the Slack message was sent “in the moment” but never tied back to the source record.
In this guide, you will build a production-grade Cross-Platform Automation (XPA) that automatically creates PandaDoc proposals from Airtable records using Make.com. You will also wire a PandaDoc webhook flow that updates Airtable status and posts to Slack when the document state changes.
By the end, you will know exactly how to set up a robust Airtable to PandaDoc XPA with idempotency and status syncing.
What You'll Need
- Make.com scenario builder with permissions to use the Airtable, PandaDoc, and Slack apps.
- Airtable base with:
- A single select field like
Proposal status(example values:Ready for PandaDoc,Created,Waiting approval,Signed,Error). - A text field like
PandaDoc document id(blank initially). - The fields you will map to PandaDoc merge fields (customer, dates, totals).
- A single select field like
- PandaDoc template(s) with merge fields matching what you send from Make.
- Slack workspace and a channel (or channels) for proposal events.
- Ability in PandaDoc to receive webhook events.
If you want to see the underlying XPA pattern in context, this is the one we build around: Cross-Platform Automation (XPA).
How It Works (The Logic)
Your Airtable to PandaDoc XPA runs in two scenarios.
- Create scenario (record-driven)
- When an Airtable record enters
Proposal status = Ready for PandaDoc[trigger], Make reads the record [action], checks ifPandaDoc document idis already present [action], and only then creates a PandaDoc proposal from your template [action]. - Make writes the returned PandaDoc
document_idback to Airtable and advancesProposal statustoCreatedorWaiting approval.
- Webhook scenario (event-driven)
- When PandaDoc sends a webhook event for that document [trigger], Make finds the matching Airtable row by
PandaDoc document id[action]. - Make deduplicates repeated webhook deliveries [action], updates
Proposal status, logs event details, and posts a Slack message.
The result is state synchronization, not a one-off document creation.
Step-by-Step Setup
Step 1: Create your Airtable fields as the control plane
In Airtable, you need fields that act like the contract between systems.
Proposal status(single select)PandaDoc document id(single line text)Last webhook event(optional, single line text for dedupe key)Last error(optional, long text)- Your merge field inputs, for example:
Customer nameCustomer emailProject start dateTotal amount
Recommendation: use Airtable field types that behave predictably when passed to Make and then into PandaDoc, especially for dates and currency.
Step 2: Build the Airtable → Make create scenario
In Make.com, create a scenario named Airtable to PandaDoc create (idempotent).
-
Module 1: Airtable Watch records (or equivalent trigger)
- Filter to only records where:
Proposal statusequalsReady for PandaDoc
- Filter to only records where:
-
Module 2: Airtable Get record (optional, but safer)
- Fetch the full record by id from the trigger.
- This reduces “missing field” issues when the watch payload is minimal.
-
Module 3: Idempotency check (conditional)
- If
PandaDoc document idis not empty, stop the branch. - If empty, continue to create.
- If
Gotcha: filtering only on Proposal status is not enough. Retries, scenario re-runs, or webhook races can still cause duplicates. Checking PandaDoc document id is the actual dedupe gate.
-
Module 4: Data preparation (formatting)
- Normalize values before sending.
- Examples that prevent blank or malformed merge fields:
- Convert dates to a consistent string format.
- Ensure currency totals are strings or numbers in the format your template expects.
-
Module 5: PandaDoc Create document from template
- Select the PandaDoc template.
- Map fields into the PandaDoc merge field inputs.
If you want a field-mapping walk-through with the same Airtable to PandaDoc pattern, you can follow this earlier implementation: generate PandaDoc proposals from Airtable records using Make.com.
-
Module 6: Airtable Update record
- Write back:
PandaDoc document idwith the createddocument_idProposal statustoCreatedorWaiting approval- Clear
Last errorif you store it
- Write back:
-
Error path: Airtable Update record to Error
- If PandaDoc creation fails, write
Last errorand setProposal status = Error.
- If PandaDoc creation fails, write
Step 3: Post a Slack “proposal created” message (optional but useful)
Still inside the create scenario, add a Slack message step after the Airtable update.
- Post a concise message with:
- Customer name
- Airtable record link or record id
- PandaDoc
document_id
Keep this short. Let webhook updates handle later lifecycle events like sent, viewed, and signed.
Step 4: Build the PandaDoc webhook → Airtable + Slack scenario
Create a second scenario named PandaDoc webhook to Airtable + Slack.
-
Module 1: Webhook trigger (PandaDoc event receiver)
- Configure Make to receive PandaDoc events for the relevant template(s).
-
Module 2: Extract event fields
- Identify at minimum:
document_id- event type or status
- Identify at minimum:
-
Module 3: Airtable Search records
- Search in your proposals table where:
PandaDoc document idequals the webhookdocument_id
- Search in your proposals table where:
-
Module 4: Dedupe webhook deliveries (conditional)
- Create a dedupe key conceptually like:
dedupeKey = document_id + ':' + event_type
- Compare it against
Last webhook event(or an equivalent stored key). - If already handled, stop.
- Create a dedupe key conceptually like:
-
Module 5: Airtable Update record
- Update
Proposal statusbased on event type. - Examples:
sent→Waiting approvalsignedorcompleted→Signeddeclined→ErrororDeclined
- Save
Last webhook eventto the dedupe key.
- Update
-
Module 6: Slack Send message
- Post lifecycle updates with:
- New status
- Customer name
document_id
- Post lifecycle updates with:
For the status sync pattern, this is the related deep dive we often reference: sync PandaDoc document status to Airtable and Slack using Make.com.
Step 5: Run-order testing with a single “staging” record
Do not test with production data first.
- Create one Airtable record:
Proposal status = Ready for PandaDoc- leave
PandaDoc document idblank
- Run the create scenario and confirm:
- PandaDoc document is created
- Airtable is updated with
PandaDoc document id
- Trigger a PandaDoc event (send or complete it) and confirm:
- webhook scenario updates Airtable
Proposal status - Slack posts the correct event
- webhook scenario updates Airtable
If you see webhook updates arriving before Airtable has the id:
- Add a safeguard in the webhook scenario: if Airtable search returns no record, log it and stop, or retry after a short delay.
Real-World Business Scenario
A mid-market B2B consultancy used Airtable for proposal intake and PandaDoc for signing. The manual workflow was fragile: proposals were generated by a coordinator, and the Slack approval message was written from memory.
After implementing this Airtable to PandaDoc XPA, every record marked Ready for PandaDoc automatically creates the correct PandaDoc document. The automation then syncs PandaDoc lifecycle events back into Airtable and posts every state change into Slack. Their ops team stopped chasing “where is the document” emails, because Airtable became the system of record, and Slack became the event log.
Common Variations
- Add line items from an Airtable linked table
- Use Make to read linked
Line Itemsand construct the line item payload PandaDoc expects.
- Add approval routing
- When PandaDoc goes to
sent, post to different Slack channels based onRegionorTotal amount.
- Store a signed PDF link in Airtable
- When status becomes
Signed, have Make fetch or generate the signed PDF file and store it in Google Drive, then write the link back to Airtable.
Building blocks you can reuse across XPA
This is the core “create + lifecycle sync” design you will reuse across many XPAs: Airtable triggers, Make transformations, PandaDoc document generation, and webhook-driven state updates.
Olmec Dynamics builds automations like this for teams that want reliability under real edge cases, not just a demo that works once. If you want more patterns, you can browse Cross-Platform Automation (XPA) and see what we build.