How to Sync PandaDoc Document Status to Airtable and Slack Using Make.com

Introduction

When a PandaDoc document moves from “sent” to “viewed” to “signed,” your operations team needs that status in Airtable and a clear Slack notification. The manual way is usually spreadsheet checks, searching by name or email, copy-pasting status values into Airtable, and then sending a Slack message that still needs follow-up when someone spots a mismatch.

This is exactly the kind of Cross-Platform Automation (XPA) workflow you want: PandaDoc emits events, Make.com normalises them, Airtable becomes the system of record, and Slack becomes the human alert layer. By the end, you will know how to build a production-ready Make.com scenario that handles duplicates, late webhooks, and partial payloads.

What You'll Need

• PandaDoc account with access to your documents
• PandaDoc API access and a way to configure webhooks or an existing PandaDoc status event mechanism
• Airtable base with a table for document status tracking (IDs, status, timestamps, and links)
• Slack workspace and a channel where you want notifications
• Make.com account, paid plan recommended for reliable webhook execution and retries
• Permissions:
  • Make.com connected to PandaDoc, Airtable, and Slack
  • Airtable API access token with permission to create and update records

If you are new to XPA patterns like this, this primer helps with the general approach: Cross-Platform Automation (XPA).

How It Works (The Logic)

Make.com uses a webhook trigger for PandaDoc status events. For each event, it extracts document_id, event_id (or the closest equivalent unique identifier), and the new status. It then runs an idempotency check using a processed-events store. If the event is new, it upserts the corresponding record in Airtable, updates the latest status and timestamps, and posts to Slack only for actionable transitions like Signed or Declined.

This logic assumes webhook delivery is at-least-once, so duplicates and out-of-order events are expected and handled.

Step-by-Step Setup

1) Create Airtable tables that support idempotency

In Airtable, build two tables.

Table A: Document Status Tracking

• PandaDoc Document ID (single line text, indexed if possible)
• Envelope/Doc URL (URL or text)
• Current Status (single select with values like Sent, Viewed, Signed, Declined, Completed)
• Last Status Change At (date-time)
• Last Event ID (single line text)
• Recipient Email (single line text, optional)

Table B: Processed Webhook Events

• Event ID (single line text, unique in practice)
• PandaDoc Document ID (text)
• Event Type (text)
• Received At (date-time)
• Outcome (single select: success, error, ignored)

This is the simplest way to make the Make.com scenario safe under retries.

2) Build a dedicated Make.com scenario that receives PandaDoc webhooks

• In Make.com, create a new Scenario
• Add the trigger: Webhooks > Custom webhook
• Set it to accept POST
• Copy the webhook URL and register it in PandaDoc’s webhook configuration

Gotcha: configure PandaDoc to send status transitions you actually care about, for example signed, declined, completed. Do not ingest every internal draft update unless you need it.

3) Normalise webhook payload fields right after the trigger

Immediately after the webhook trigger, add steps to extract:

• event_id (prefer a unique per-event ID if PandaDoc provides one)
• document_id (PandaDoc document identifier)
• event_type (status changed, signed, declined, etc.)
• new_status (raw value)
• event_timestamp (convert to ISO 8601 UTC if needed)
• recipient_email (if present)
• doc_url (if present)

In Make.com, use Tools modules like JSON parse, then set variables so the rest of your scenario is not coupled to payload shape.

4) Deduplicate before you touch Airtable

Add an Airtable search for Processed Webhook Events.

• Module: Airtable > Search records
• Base: Processed Webhook Events
• Filter: Event ID equals event_id

Then:

• If found: stop the scenario (Outcome = ignored)
• If not found: continue

This prevents duplicates from churning Airtable and spamming Slack.

5) Enrich missing fields only when needed

If your webhook sometimes omits recipient_email or the document URL:

• Add a conditional step: if recipient_email is empty, call PandaDoc > Get Document (or equivalent PandaDoc API request)
• Extract the missing values

Only call the PandaDoc API when fields are missing. This keeps latency and API usage under control.

6) Map PandaDoc statuses to your Airtable “Current Status” enum

Create a mapping step using Make.com tools or a router:

• PandaDoc sent → Airtable Sent
• PandaDoc viewed → Airtable Viewed
• PandaDoc signed → Airtable Signed
• PandaDoc declined → Airtable Declined
• PandaDoc completed → Airtable Completed

If your statuses do not map one-to-one, normalise to stable Airtable values so your Slack filters are consistent.

7) Upsert the Airtable record safely

Make.com does not give you a true “atomic upsert” in Airtable by default, so implement upsert as search then update/create.

• Step A: Airtable > Search records in Document Status Tracking

  • Filter: PandaDoc Document ID equals document_id

• Step B:

  • If found: Airtable > Update record
  • If not found: Airtable > Create record

Update fields:

• Current Status = mapped status
• Last Status Change At = event_timestamp
• Last Event ID = event_id
• Recipient Email = recipient_email
• Envelope/Doc URL = doc_url

Gotcha: if you receive out-of-order events, consider adding a timestamp guard. Only update Airtable if event_timestamp is newer than Last Status Change At.

8) Post to Slack only for actionable transitions

Before the Slack step, add a filter.

Slack rule examples:

• Send only when new_status in [Signed, Declined, Completed]

Then:

• Module: Slack > Send a channel message

Suggested message:

• PandaDoc {{document_id}} is now *{{new_status}}*
• Recipient: {{recipient_email}}
• Airtable: {{record_url}}

Capture the Airtable record ID during upsert so you can build a direct record URL.

9) Mark the event as processed after success

After Airtable upsert succeeds, create a row in Processed Webhook Events.

• Module: Airtable > Create record in Processed Webhook Events
• Set:
  • Event ID = event_id
  • PandaDoc Document ID = document_id
  • Event Type = event_type
  • Received At = now
  • Outcome = success

If Slack fails after Airtable update, you still want the state to be correct. You can treat Slack as “best effort” and still mark the event processed.

10) Add failure handling that ops can replay

Use Make.com’s error handling route.

On persistent failure:

• Post a message to a private ops Slack channel with:
  • event_id
  • document_id
  • error text
• Do not write a “success” processed-event row

Optionally add a manual replay mechanism, for example a separate Airtable table where ops can paste an event_id to re-run processing.

Real-World Business Scenario

A legal operations team at a services business runs NDA and MSA approvals through PandaDoc. Their Airtable base is used as the internal status dashboard for each matter, while Slack is the channel for immediate action when signature completes.

After switching to this Make.com pipeline, every PandaDoc Signed or Declined transition updates the correct Airtable record through idempotent upserts. Duplicates no longer cause multiple Airtable churns, and Slack gets notified exactly when a meaningful state boundary is crossed.

The operational outcome is simple: fewer “did it sign?” messages, faster triage, and an audit-like history in the processed-events table that makes incident troubleshooting straightforward.

Common Variations

• Route by recipient domain: add a filter so Slack messages only fire for specific email domains, for example company.com.
• Create follow-up tasks: on Signed, create a ClickUp task or an Asana task using the Airtable record ID and link it back to Airtable.
• Add a daily reconciliation job: schedule a Make.com scenario that pulls PandaDoc document status for the last N days and checks Airtable drift using Last Event ID and Last Status Change At.

What you built, and how we help

You built an advanced PandaDoc status sync that works the way real Cross-Platform Automation (XPA) should: webhook ingestion in Make.com, strict deduplication, safe Airtable upserts, and Slack notifications only for actionable transitions.

Olmec Dynamics builds and hardens these exact PandaDoc → Airtable → Slack workflows, including the production details like idempotency windows, replay mechanics, and runbooks. If you want help implementing this for your document lifecycle, start at Olmec Dynamics.