Olmec Dynamics
H
·8 min read

How to Create PandaDoc Proposals from Airtable with Slack Approval Using Make.com

Automate Airtable to PandaDoc proposals in Make.com with Slack approval gating, template field mapping, idempotency, and Airtable status write-back.

Introduction

If your proposal requests live in Airtable and approvals happen in Slack, the manual flow is brutal. Someone copies fields from Airtable into a PandaDoc template, sends for signature, then messages the team to confirm the proposal is actually in motion. That creates delays, mismatched versions, and plenty of “did we already generate this?” confusion.

A practical Airtable to PandaDoc workflow in Make.com solves it, but only if you gate document creation behind Slack approval. Otherwise you still create proposals for the wrong record state, or you accidentally generate duplicates when scenarios re-run.

By the end of this guide, you will know how to build an Airtable to PandaDoc proposal automation in Make.com with Slack approval gating, idempotency protection, and Airtable write-back.

What You’ll Need

  • Airtable base with:
    • A table for proposal requests (example: Proposal Requests)
    • Fields for client info, proposal fields, and a “status” field (example: Proposal status)
    • A stable unique key (example: Request ID) that never changes
    • Fields to store PandaDoc metadata (example: PandaDoc document ID, PandaDoc URL, PandaDoc status, Generated at)
    • An approval state you can filter on (example: Approval status values like Ready for approval, Approved, Rejected)
  • A PandaDoc template with fields you can map from Airtable
  • Make.com (paid is recommended for production, especially if you add retries and logs)
  • Slack workspace permissions to:
    • Post messages to your approval channel
    • Read the messages you depend on for the approval decision (depending on how you implement the wait step)
  • (Recommended) Google Sheets for an audit log and idempotency checks

If you want the broader pattern behind this kind of end-to-end Cross-Platform Automation, see Cross-Platform Automation (XPA).

How It Works (The Logic)

In plain English, your scenario does this:

  • Trigger: Make.com watches Airtable for records that are ready for approval.
  • Gate: it checks idempotency so one Airtable Request ID generates at most one PandaDoc proposal.
  • Human step: it posts an approval request into Slack.
  • Decision: it branches based on the approval outcome.
  • Action: on approval it creates the PandaDoc proposal from your template, then writes PandaDoc IDs, URLs, and status back into Airtable.
  • Audit: it logs the approval outcome and generation result for traceability.

Everything hinges on two guardrails, eligibility and idempotency.

Step-by-Step Setup

1) Shape your Airtable table so gating is reliable

In Proposal Requests, set up these fields at minimum:

  • Request ID (Text, unique)
  • Approval status (Single select)
    • Values: Ready for approval, Approved, Rejected
  • PandaDoc document ID (Text, initially blank)
  • PandaDoc URL (URL, initially blank)
  • PandaDoc status (Text)
  • Generated at (Date/time)

Then add the fields you will map into your PandaDoc template, for example:

  • Client name, Client email, Address
  • Proposal total, Currency
  • Line items or a structured set of line-item fields your template expects

Gotcha: approvals based on multiple “mostly populated” columns cause weird edge cases. Your best gating strategy is one predictable eligibility state, Ready for approval.

2) Create the Make.com scenario and set the Airtable trigger

In Make.com:

  1. Create a new Scenario
  2. Add the Airtable watch trigger (a “Watch Records” style module)
  3. Select the table Proposal Requests
  4. Immediately follow the trigger with a filter so only records continue when:
    • Approval status = Ready for approval
    • PandaDoc document ID is empty

That second condition is a first-pass safety net. You will still add a log-based idempotency check next.

3) Add idempotency using Google Sheets (recommended)

Create a Google Sheet called something like Proposal Generation Log with columns:

  • Request ID
  • Slack approval outcome
  • Approved by (if available)
  • Approval timestamp
  • PandaDoc document ID
  • PandaDoc status
  • Run timestamp

Then, in Make.com:

  • Add a Google Sheets “Search rows” (or equivalent lookup) by Request ID
  • Router logic:
    • If Request ID exists, stop the scenario (do not generate)
    • If not found, continue to Slack approval

This prevents duplicate PandaDoc documents if you re-run the scenario or if Airtable triggers multiple times during record updates.

4) Post the Slack approval request

Add a Slack module to post into #proposal-approvals.

Your message should include enough context for the approver to decide in 30 seconds:

  • Request ID
  • Client name
  • Proposal total and currency
  • A link back to the Airtable record (build it from the record ID if your team uses a consistent URL pattern)
  • Any must-read notes

Implementation detail that matters: if your Slack setup supports interactive actions (buttons), use them so you can capture approve vs reject cleanly. If it does not, keep the decision mechanism deterministic, for example approval via a specific emoji reaction or a reply keyword that your “wait for response” step can detect.

5) Wait for approval and branch

Add branching logic based on the Slack decision:

  • Approved branch
    • Update Airtable Approval status to Approved (optional but useful)
    • Continue to PandaDoc creation
  • Rejected branch
    • Update Airtable Approval status to Rejected
    • Store rejection notes into a field like Rejection reason (if you have it)
    • Write an audit row to your log and stop

Gotcha: store the decision metadata in variables you also write to your log. You will thank yourself during disputes.

6) Create the PandaDoc proposal from the template

In the approved branch, add the PandaDoc module to create a document from a template.

Then map Airtable fields into PandaDoc template fields. Typical mappings:

  • Client name → PandaDoc field Client Name
  • Client email → PandaDoc field Email
  • Address → PandaDoc field Address
  • Proposal total + Currency → PandaDoc field Total
  • Line items or line-item fields → PandaDoc line-item sections
  • Terms and any custom notes → PandaDoc Terms fields

If you are unsure where mapping fits, this related guide covers the base Airtable to PandaDoc document generation approach: How to Automatically Create PandaDoc Documents from Airtable Using Make.com.

7) Write PandaDoc output back to Airtable

After PandaDoc creation succeeds, update the Airtable record with at least:

  • PandaDoc document ID
  • PandaDoc URL
  • PandaDoc status
  • Generated at

This creates a single source of truth in Airtable so your team can see exactly what was generated.

8) Append an audit row

Add a Google Sheets “Add row” module (or update the log row you created) to record:

  • Request ID
  • approval outcome
  • who approved (if your Slack capture provides that)
  • timestamps
  • PandaDoc IDs and status

This log also doubles as your idempotency dataset.

9) Add error handling that preserves idempotency

If PandaDoc creation fails:

  • Update Airtable fields so the record is not marked as Approved completed
  • Store an error message into something like Generation error
  • Write a failure row into the log

To avoid duplicates later, keep the eligibility condition tied to Airtable fields that only change when PandaDoc creation actually succeeded. Your “PandaDoc document ID is empty” gate should remain true on failure.

10) Test with real records and simulate re-runs

Run tests with:

  1. A Ready for approval record where PandaDoc document ID is blank (should create)
  2. Triggering the same record again (should not create a second PandaDoc)
  3. A record where the Slack approver rejects (should update to Rejected and stop)

Real-World Business Scenario

A small services business uses Airtable as the proposal queue, and Slack approvals for leadership sign-off. Before automation, ops copied Airtable fields into PandaDoc manually, then leadership had to follow up on whether the document was sent.

With this Make.com setup, the record becomes Ready for approval, Slack receives an approval request with the key totals and a link back to Airtable, and only after approval does Make.com generate the PandaDoc proposal. Airtable now contains the PandaDoc document ID and URL, so finance and delivery can see what was sent without guessing.

Common Variations

1) Only approve if totals match a threshold

Add a filter before Slack so only certain proposal totals reach the approver channel, for example totals above £2,000. Lower-value proposals can follow a separate path.

2) Generate different PandaDoc templates by service type

Use a router after the Airtable trigger on an Airtable field like Service line and map to different PandaDoc templates for each service category.

3) Add a “re-send” path after rejection

When a proposal is rejected, allow updates to the Airtable record, then require it to be set back to Ready for approval and clear or update any PandaDoc fields you want to regenerate.

The workflow you now have

You built an Airtable to PandaDoc proposals automation in Make.com that is gated by Slack approval, prevents duplicate documents with idempotency checks, and writes PandaDoc status and links back into Airtable.

That is exactly the kind of Cross-Platform Automation (XPA) Olmec Dynamics builds for teams where approval must happen before documents are created. If you want this mapped to your exact Airtable schema and PandaDoc template fields, you can see what we do here and explore Cross-Platform Automation (XPA) for the bigger approach.