How to Automate Airtable → PandaDoc Signature Using Make.com

Introduction

If contract requests live in Airtable, the manual workflow usually looks like this: export the record, fill the template in PandaDoc, send to signers, then later someone comes back to update Airtable when the signature completes.

That creates two headaches. First, retries and “just redo that envelope” behaviour produce duplicate PandaDoc documents. Second, Airtable often stays stale because webhook updates are missed or applied inconsistently.

In this guide, you will build Cross-Platform Automation (XPA) with Cross-Platform Automation (XPA) patterns so Airtable drives PandaDoc signature creation, and PandaDoc drives Airtable status updates. By the end, you will know exactly how to design the workflow logic for reliability, deduplication, and clean operational visibility.

What You'll Need

• Airtable
  • A base table like Contract Requests
  • Fields for signer details, template variables, and signature status
  • A stable request_id per contract request
  • Fields to store integration outputs, like panda_doc_id, signature_status, and last_error
• PandaDoc
  • A document template ready for API creation
  • Recipient configuration structure that matches your signers in Airtable
  • Ability to configure webhooks for document state changes
  • PandaDoc API access in Make.com
• Make.com
  • A Make.com account with Airtable, PandaDoc, Slack connections
  • A paid plan recommended for running webhook processing scenarios reliably and handling multi-step runs
• Slack
  • Permission to post into a signature updates channel
• Google Sheets (recommended)
  • A lightweight log to enforce idempotency across retries and scenario re-runs

How It Works (The Logic)

You will run two linked scenarios.

Scenario A: Airtable drives PandaDoc When a Contract Requests record becomes “ready to send,” Make.com validates required fields, checks the idempotency log for the request_id, creates a PandaDoc document, sends it for signature, writes panda_doc_id back to Airtable, logs the action, then posts a Slack message.

Scenario B: PandaDoc webhooks drive Airtable When PandaDoc fires a webhook for the document, Make.com deduplicates by webhook event ID, finds the matching Airtable record by panda_doc_id, maps the PandaDoc state to your Airtable signature_status, logs the processed webhook event, and posts Slack only for meaningful transitions.

The reliability comes from the same design principle in both directions: idempotency. PandaDoc webhooks can arrive more than once, and Make.com retries on failures. Your workflow must be safe to run repeatedly without creating duplicates.

Step-by-Step Setup

Step 1: Design Airtable fields for a safe workflow

In Airtable, in Contract Requests, create or confirm these fields:

• request_id (text, unique, stable)
• panda_doc_id (text, blank until created)
• signature_status (single select)
  • Suggested values: Not Sent, Sent, Viewed, Signed, Completed, Failed
• Signer fields, at minimum:
  • signer_1_name, signer_1_email, signer_1_role
  • Optional: signer_2_name, signer_2_email, signer_2_role
• Template variables
  • Either individual fields (recommended for mapping clarity) or a single structured field you can transform
• last_error (long text)

Common gotcha: if request_id is not truly stable, your deduplication breaks the moment a record is edited.

Step 2: Create a Google Sheets idempotency log

Create a Google Sheet with columns:

• request_id
• panda_doc_id
• status
• created_at
• panda_doc_envelope_id (optional)
• last_webhook_event_id
• notes (optional)

Why a log in Sheets? Airtable updates are part of the workflow and can lag. Sheets becomes your stable “did we already do this?” audit trail.

Step 3: Build Scenario A in Make.com (Airtable → PandaDoc → Airtable + Slack)

1. Airtable Trigger

• Create a scenario with an Airtable trigger that fires on:
  • record creation, or
  • record update where signature_status changes from Not Sent to something that indicates ready

2. Get Record (optional, but usually helpful)

• Add an Airtable “Get a record” step to normalize field values for mapping.

3. Filter to required fields

• Add a filter that only continues if:
  • request_id is not empty
  • signer_1_email is not empty
  • all required template variable fields are present

4. Idempotency check in Google Sheets

• Add Google Sheets search for request_id.
• Logic:
  • If a row exists with a non-empty panda_doc_id, route to an “Already processed” branch and stop.
  • If no matching row exists, route to “Create PandaDoc.”

5. Create PandaDoc document via API

• Use the PandaDoc module in Make.com that creates a document from your template.
• Map Airtable variables into PandaDoc template variables.
• Map recipients from signer_1_email, signer_1_name, and signer_1_role.

6. Send for signature

• Immediately after creation, call the PandaDoc send action.
• Practical gotcha: PandaDoc document state transitions can be asynchronous. If you see errors indicating the document is not ready to send (or similar 409-style timing failures), you need either:
  • a short delay step before sending, or
  • a polling loop pattern until the document is in a sendable state

7. Update Airtable record

• Update panda_doc_id and set signature_status = Sent.

8. Append to Google Sheets log

• Add a row with:
  • request_id
  • panda_doc_id
  • status = Sent
  • timestamps

9. Slack notification

• Post to your signature channel.
• Recommended message content:
  • Contract request reference: {{request_id}}
  • Signer emails
  • Link to the Airtable record for operations

Step 4: Build Scenario B in Make.com (PandaDoc webhooks → Airtable updates)

1. Webhook trigger in Make.com

• Create a webhook-receiver scenario.
• Copy the webhook URL from Make.com into PandaDoc webhook configuration.

2. Parse webhook payload

• Extract at minimum:
  • PandaDoc document identifier (panda_doc_id)
  • webhook event identifier (commonly an event ID field)
  • the document status that triggered the webhook

3. Deduplicate webhook processing

• Search Google Sheets log for the webhook event ID.
• If already processed, stop.

4. Find the Airtable record

• Find Contract Requests by matching panda_doc_id.

5. Map statuses to Airtable signature_status

• Examples of mapping logic:
  • PandaDoc document_signed → Airtable Signed
  • PandaDoc document_completed → Airtable Completed
  • PandaDoc document_viewed → Airtable Viewed (only if you want it)

6. Update Airtable

• Update signature_status to the mapped value.

7. Slack notifications for meaningful transitions

• Filter so you only post on transitions like Signed and Completed.

8. Update Google Sheets log

• Store last_webhook_event_id and the mapped status.

Step 5: Add failure handling that avoids duplicates

In Scenario A:

• Route PandaDoc send errors to a failure branch.
• Update Airtable signature_status = Failed.
• Write last_error with the error message.
• If PandaDoc document creation succeeded but send failed, store panda_doc_id anyway and rely on idempotency to prevent creating a second document.

In Scenario B:

• If a webhook event arrives but you cannot find the Airtable record by panda_doc_id, log it as an orphan in Sheets and alert ops once per event type to avoid infinite Slack noise.

Step 6: Test properly using a controlled dataset

1. Create two Airtable Contract Requests rows with different request_id values.
2. Trigger Scenario A by setting them to ready to send (or updating signature_status from Not Sent).
3. Confirm:
   • one PandaDoc document per request
   • Airtable gets panda_doc_id
   • Scenario B transitions Airtable to Signed and Completed
4. Simulate retries:
   • re-run Scenario A for an existing request_id and confirm it does not create a second PandaDoc document
5. Confirm Slack rules:
   • only post on chosen transitions

Step 7: Keep templates and variables deterministic

Your PandaDoc template variables should map from Airtable fields that do not change shape.

If you generate documents from a Google Docs template first, you can reuse the same pattern used in how to generate a PDF from a Google Docs template and route it through PandaDoc. The core contract reliability technique, idempotency, stays the same.

Real-World Business Scenario

A legal ops team at a B2B services firm ran contract requests through Airtable because it matched how they manage signer groups and variable clause fields. Before automation, a coordinator did three manual steps: create PandaDoc, send to signers, then update Airtable later.

Once they built the two-scenario Airtable → PandaDoc signature XPA:

• contract requests started sending automatically when marked ready
• Airtable status stayed accurate because PandaDoc webhooks drove updates
• duplicates stopped because request_id plus the Sheets log enforced “one request, one PandaDoc document”

Operations also got cleaner visibility because Slack only posted on Signed and Completed, not on every status change.

Common Variations

1. Add a reminder automation

• In Scenario B, when you detect Viewed but not Signed after X days, you can trigger a PandaDoc reminder action or post to Slack for manual follow-up.

2. Route by contract type

• In Scenario A, branch by Airtable contract_type:
  • different PandaDoc templates
  • different Slack channels (legal team vs procurement)

3. Build an ops digest

• Use the same Airtable-to-email daily digest pattern from how to send a daily Airtable status digest to Gmail using Make.com to produce weekly compliance reports based on signature_status.

Keeping it reliable in production

What you built is an end-to-end contract signature workflow where Airtable initiates PandaDoc signatures, and PandaDoc webhooks update Airtable as signatures progress. The key is the idempotency design, because real systems retry, and PandaDoc webhook delivery is at-least-once.

If you want this implemented across Airtable, PandaDoc, Make.com, Slack, and your reporting storage with the right deduplication and operational routing, Olmec Dynamics builds these automations for real businesses.