Olmec Dynamics
H
·7 min read

How to Automate Airtable to PandaDoc Proposals Using Make.com

Automate Airtable-ready records into PandaDoc proposals with Make.com, create from templates, send to clients, then update Airtable status.

If you are running proposals by hand, you already know the routine. Someone takes a row from Airtable, copies the fields into a PandaDoc template, sends the proposal, then remembers to update that Airtable record so everyone else knows what happened.

That last part is where things drift. You get duplicates because the “sent” status update is inconsistent, or you get stuck because a template field key does not match the data you mapped. This [Airtable to PandaDoc proposals automation] uses Make.com to turn ready records in Airtable into PandaDoc documents from a template, send them to clients, then write the PandaDoc Document ID and status back to Airtable. By the end, you will know how to build a stable Cross-Platform Automation (XPA) workflow for this end-to-end flow.

What You'll Need

  • Airtable base and table containing proposal data, including:
    • Client name and client email
    • The proposal fields you will map into the PandaDoc template (project, pricing, dates, notes)
    • A boolean or status field like Ready for PandaDoc
    • Fields to store results, such as PandaDoc Document ID, PandaDoc Status, and optionally PandaDoc Document Link
  • PandaDoc account with:
    • A configured template that has fillable fields
  • Make.com scenario build with connections enabled for Airtable and PandaDoc
  • Access/permissions:
    • Your Airtable connection must be able to read and update the target base/table
    • Your PandaDoc connection must be able to use the template you selected

How It Works (The Logic)

In plain terms, your Make.com scenario follows this trigger-to-action chain:

  1. Trigger: When an Airtable record matches your filter (for example, Ready for PandaDoc = true), Make picks up that record.
  2. Action 1: Make creates a new PandaDoc document from your template, filling template fields from the Airtable columns.
  3. Action 2: Make sends the created document to the recipient email stored in Airtable.
  4. Action 3: Make updates the original Airtable record with the PandaDoc Document ID and a status like “Sent”.

Step-by-Step Setup

This is the setup I use when teams want it to stay reliable under real-world data and re-runs.

1) Create the Make.com scenario

  • In Make.com, create a new scenario.
  • Add modules in this order:
    1. Airtable trigger (watch or watch records)
    2. PandaDoc module to Create Document from Template
    3. PandaDoc module to Send Document
    4. Airtable module to Update a record

2) Configure the Airtable trigger to only pick “ready” rows

  • Select your Base and Table.
  • Add filters:
    • Ready for PandaDoc = true
    • And add a duplicate guard, typically one of:
      • PandaDoc Document ID is empty, or
      • PandaDoc Status does not equal Sent

Why both? If you only filter on “Ready”, the automation can re-run and create duplicates if the status update fails.

3) Map Airtable fields into the PandaDoc template fields

  • In the PandaDoc Create Document from Template module:
    • Select the correct Template
    • Set the Document name using Airtable data (for example, “Proposal - {Client Name} - {Proposal Date}”)
    • Map each template fillable field key to its matching Airtable field

Example field mapping pattern (adjust names to your template keys):

  • Airtable Client Name → PandaDoc template field key ClientName
  • Airtable Client Email → PandaDoc template field key ClientEmail (if included in template)
  • Airtable Project → PandaDoc template field key Project
  • Airtable Due Date → PandaDoc template field key DueDate
  • Airtable Total → PandaDoc template field key TotalAmount
  • Airtable Notes → PandaDoc template field key Notes

Gotcha: PandaDoc will fail the create step if you map to the wrong template field key. Treat the template field keys as the source of truth, not your Airtable column names.

4) Send the document using the Document ID output

  • Add the PandaDoc Send Document module.
  • Feed it the Document ID output from the previous PandaDoc create module.
  • Set recipient details from Airtable:
    • Recipient name from Client Name
    • Recipient email from Client Email

5) Validate email and block bad rows early

Before sending, add a Make.com filter condition (between create and send, or within the trigger filter):

  • Client Email is not empty
  • (Optional) Client Email contains @

This avoids noisy failures where PandaDoc cannot send.

6) Write results back into Airtable

  • Add the Airtable Update a record module.
  • Identify the correct Airtable row using the trigger’s record identifier.
  • Update fields:
    • PandaDoc Document ID = Document ID from PandaDoc create
    • PandaDoc Status = “Sent” (or whatever your team uses)
    • PandaDoc Document Link = if your PandaDoc create or send step returns a URL/link
    • PandaDoc Sent At = timestamp (optional)

Gotcha: Make sure the Airtable field types match what you write. If your Document ID field is a single line text column, do not try to write a structured object.

7) Add failure visibility with an error route

In Make.com, configure error handling so failures do not silently die.

A practical pattern:

  • If PandaDoc create fails, update Airtable with an Error Message field and stop.
  • If PandaDoc send fails, also write Error Message and optionally notify your Slack channel.

Even a single “Error Message” field in Airtable saves hours of debugging.

8) Test with one record, then run a controlled batch

  • Test with exactly one Airtable row that you know is correct.
  • Confirm:
    • PandaDoc document content is correct
    • Client receives the proposal
    • Airtable shows the Document ID and status
  • Then, run 3 to 5 records at a time to validate field mapping consistency.

Real-World Business Scenario

An agency runs multiple proposal types. Estimators finish pricing in Airtable and set Ready for PandaDoc. Before automation, proposals were created manually in PandaDoc, sent, and only sometimes logged back in Airtable.

After implementing this Make.com scenario, every ready row:

  • generates a PandaDoc proposal from the right template,
  • sends instantly to the client email stored in Airtable,
  • and updates the Airtable row with the PandaDoc Document ID and “Sent”.

The ops team stopped doing the “did we send it and where is the link?” checks. Sales also started referencing the Document ID for follow-ups.

Common Variations

  1. Route by proposal type to different templates

    • Add a Make.com router after the trigger based on an Airtable field like Proposal Type.
    • Each route uses a different PandaDoc template.

  2. Add e-signature sending instead of basic sending

    • If your PandaDoc templates are configured for signing, swap the send module configuration to create an e-sign workflow.

  3. Add a reminder after N days

    • Create a second scenario that watches PandaDoc status or checks for “Sent but not Viewed” state (based on what PandaDoc provides) and then sends a reminder.

What You End Up With

You will have an Airtable-driven proposal pipeline where a record becomes a PandaDoc document from your template, PandaDoc sends it to the client, and Airtable becomes the system of record for what was created and when. That is the practical shape of Cross-Platform Automation (XPA) for document workflows.

If you want a version tuned to your exact Airtable schema and PandaDoc template field keys, Olmec Dynamics builds and implements these XPAs end to end, including field-by-field mappings and duplicate prevention. You can see our approach and examples in Cross-Platform Automation (XPA).