Olmec Dynamics
H
·7 min read

How to Automate Airtable to PandaDoc Proposals Using Make.com and Slack

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).
  • 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.

  1. Create scenario (record-driven)
  • When an Airtable record enters Proposal status = Ready for PandaDoc [trigger], Make reads the record [action], checks if PandaDoc document id is already present [action], and only then creates a PandaDoc proposal from your template [action].
  • Make writes the returned PandaDoc document_id back to Airtable and advances Proposal status to Created or Waiting approval.
  1. 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 name
    • Customer email
    • Project start date
    • Total 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).

  1. Module 1: Airtable Watch records (or equivalent trigger)

    • Filter to only records where:
      • Proposal status equals Ready for PandaDoc
  2. 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.
  3. Module 3: Idempotency check (conditional)

    • If PandaDoc document id is not empty, stop the branch.
    • If empty, continue to create.

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.

  1. 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.
  2. 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.

  1. Module 6: Airtable Update record

    • Write back:
      • PandaDoc document id with the created document_id
      • Proposal status to Created or Waiting approval
      • Clear Last error if you store it
  2. Error path: Airtable Update record to Error

    • If PandaDoc creation fails, write Last error and set Proposal status = Error.

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.

  1. Module 1: Webhook trigger (PandaDoc event receiver)

    • Configure Make to receive PandaDoc events for the relevant template(s).
  2. Module 2: Extract event fields

    • Identify at minimum:
      • document_id
      • event type or status
  3. Module 3: Airtable Search records

    • Search in your proposals table where:
      • PandaDoc document id equals the webhook document_id
  4. 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.
  5. Module 5: Airtable Update record

    • Update Proposal status based on event type.
    • Examples:
      • sentWaiting approval
      • signed or completedSigned
      • declinedError or Declined
    • Save Last webhook event to the dedupe key.
  6. Module 6: Slack Send message

    • Post lifecycle updates with:
      • New status
      • Customer name
      • document_id

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.

  1. Create one Airtable record:
    • Proposal status = Ready for PandaDoc
    • leave PandaDoc document id blank
  2. Run the create scenario and confirm:
    • PandaDoc document is created
    • Airtable is updated with PandaDoc document id
  3. Trigger a PandaDoc event (send or complete it) and confirm:
    • webhook scenario updates Airtable Proposal status
    • Slack posts the correct event

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

  1. Add line items from an Airtable linked table
  • Use Make to read linked Line Items and construct the line item payload PandaDoc expects.
  1. Add approval routing
  • When PandaDoc goes to sent, post to different Slack channels based on Region or Total amount.
  1. 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.