Building a PandaDoc onboarding workflow in Make.com requires two discrete scenarios — one that triggers on a hired status in your ATS and generates the offer document, and one that fires on PandaDoc’s signed webhook and writes the completed record to your HRIS and payroll system. The full build takes six to eight hours and eliminates every manual hand-off between offer acceptance and Day 1 provisioning.

Why Two Scenarios Instead of One

Splitting the workflow into two scenarios is the correct architecture for reliability and maintainability. A single monolithic scenario creates a fragile chain where a PandaDoc API delay blocks HRIS writes, or an HRIS timeout orphans a signed document. Two scenarios communicate through a shared data store and fail independently — meaning a PandaDoc rate-limit error never prevents your ATS trigger from logging the attempt.

Scenario 1 owns everything from the ATS hire event through document delivery. Scenario 2 owns everything from signature confirmation through system provisioning. This boundary also makes error-handler logic straightforward: each scenario can retry its own failing module without re-sending documents or duplicating HRIS records.

For a broader view of what well-structured Make.com scenarios look like across the HR lifecycle, see our guide on 10 Make.com automations elevating the employee experience from onboarding to offboarding.

Prerequisites: Credentials and Templates Before You Open Make.com

Gather all six credential sets before touching the Make.com canvas — mid-build credential hunting adds hours and introduces copy-paste errors. The six you need are: ATS API key and webhook secret, PandaDoc API key, HRIS API credentials (OAuth or token depending on your platform), payroll API credentials, Google Drive or SharePoint OAuth for document archiving, and a Slack or Teams incoming webhook URL for error notifications.

On the PandaDoc side, build and publish your offer-letter template before starting. Set every dynamic field — candidate name, start date, compensation, role title, manager name — as a PandaDoc token using the {{token_name}} syntax. Tokens that are missing at send time cause a 422 error that is harder to debug mid-scenario than a pre-flight checklist failure. If your organization uses multiple offer templates (exempt vs. non-exempt, full-time vs. contractor), publish all variants and note their template IDs now.

Also pre-create the Make.com Data Store table you will use to pass the PandaDoc document ID from Scenario 1 to Scenario 2. A two-column structure works: application_id (text, indexed) and pandadoc_document_id (text). Add a created_at timestamp column for debugging.

Scenario 1: ATS Trigger to PandaDoc Document Delivery

Scenario 1 starts with a webhook trigger that your ATS fires when a candidate reaches the hired stage. Configure the Make.com webhook module first, copy the generated URL into your ATS webhook settings, and send a test payload so Make.com can infer the data structure. Do this before building any downstream modules — Make.com’s auto-mapping only works after it has seen a real payload.

Module 1 — Webhook: Watch for ATS Hired Event

Set the webhook to instant trigger. In your ATS, scope the webhook to the hired-stage event only; do not send all ATS events to this endpoint or you will need a router to filter them out. Confirm the payload includes: candidate ID, candidate full name, candidate email, role title, department, start date, hiring manager email, employment type, and compensation fields. If compensation is encrypted in your ATS payload, plan a secondary ATS API call to retrieve it.

Module 2 — HTTP / ATS API: Retrieve Full Candidate Record

Most ATS webhook payloads contain only a subset of candidate data. Use an HTTP module pointed at your ATS candidate endpoint to pull the complete record. Map the candidate ID from the webhook payload as the path parameter. Parse the response and verify every PandaDoc token field is present before the next module runs. Add a filter after this module: if any required field is null, route to an error notification (Slack or Teams) and stop the scenario execution for that record.

Module 3 — PandaDoc: Create Document from Template

Select the PandaDoc app, choose the “Create Document from Template” action, and authenticate with your PandaDoc API key. Map the template ID from your pre-built lookup (use a Set Variable module with a switch/case on employment type to select the correct template ID). Map every token field from the ATS candidate record. In the recipients array, include both the candidate (as signer) and the hiring manager (as CC or approver depending on your process). Set the document name to a consistent format — Offer_[CandidateLastName]_[StartDate] — to make archival searches reliable.

Module 4 — PandaDoc: Send Document

Use the “Send Document” action immediately after creation. PandaDoc documents are in draft status after creation; sending moves them to sent status and emails the candidate. Set the subject and message fields using your HR brand voice. Do not skip this module and rely on PandaDoc’s auto-send setting — explicit control here prevents documents from sitting in draft when the creation module succeeds but a downstream module fails.

Module 5 — Make.com Data Store: Write Document ID

Write the PandaDoc document ID (returned in the Create Document response) and the ATS application ID to your pre-created Data Store table. This record is the handoff to Scenario 2. Include the candidate email and start date as additional columns — Scenario 2 will need them for HRIS provisioning without making a second ATS API call.

Module 6 — Google Drive or SharePoint: Archive Draft Document Link

Create a folder in your document archive using the pattern Offers/[Year]/[Month]/[CandidateLastName]_[ApplicationID] and write a text file containing the PandaDoc document URL, the document ID, and the timestamp. This is not a PDF archive (the signed PDF comes in Scenario 2) — it is a paper trail proving the document was sent and when.

Module 7 — Slack or Teams: Notify Recruiter

Send a formatted notification to the recruiter’s DM or a designated onboarding channel. Include candidate name, role, document sent timestamp, and a direct link to the PandaDoc document. This notification serves as both a confirmation and a starting point if the recruiter needs to resend or void the document manually.

Expert Take

The Data Store handoff between Scenario 1 and Scenario 2 is the most failure-prone seam in this architecture. Add a TTL (time-to-live) cleanup routine — a third lightweight scenario that runs nightly and deletes Data Store rows older than 30 days where the signature has been confirmed. Without it, stale rows accumulate and the Data Store approaches its row limit, causing silent write failures on new records.

Scenario 2: Signature Webhook to HRIS and Payroll Provisioning

Scenario 2 is triggered by PandaDoc’s document-completed webhook, which fires when all required signers have signed. This is a push event from PandaDoc — no polling required. The scenario reads the Data Store to retrieve context from Scenario 1, then provisions the new hire across HRIS, payroll, and any other systems in your stack.

Module 1 — Webhook: Watch for PandaDoc Document Completed

Create a new Make.com webhook and register it in your PandaDoc workspace under Settings → Webhooks. Select the document_state_changed event and set status filter to document.completed. Copy the webhook URL into PandaDoc. Send a test completion event from a sandbox document to load the payload structure into Make.com. The payload includes data.id (the document ID) — this is the key you use to look up the Data Store row.

Module 2 — Make.com Data Store: Retrieve Candidate Context

Search the Data Store for a row where pandadoc_document_id equals the document ID from the webhook payload. If no row is found, the document was not created by Scenario 1 — add a filter to stop execution and send an alert. A missing row at this point means either the Data Store write in Scenario 1 failed or the document was created manually in PandaDoc outside the automation, both of which require human review.

Module 3 — PandaDoc: Download Signed Document

Use the PandaDoc Download Document action to retrieve the signed PDF. Store the binary content in a Make.com variable for the archival step. Do not skip this module and rely on PandaDoc’s retention — your HR records policy likely requires you to hold signed documents independently of your document-execution vendor.

Module 4 — Google Drive or SharePoint: Archive Signed PDF

Upload the signed PDF to the same folder created in Scenario 1, Module 6. Naming convention: [CandidateLastName]_[ApplicationID]_SIGNED_[SignedDate].pdf. Set folder permissions to match your HR records access policy — not the general company drive permissions.

Module 5 — HRIS: Create Employee Record

Use an HTTP module or your HRIS’s native Make.com app to POST a new employee record. Map all fields from the Data Store row: name, email, start date, role title, department, employment type, and compensation. Check your HRIS API documentation for required fields versus optional fields — a missing required field returns a 400 error that stops provisioning without an obvious error message in Make.com’s log unless you have error handlers in place.

Module 6 — Payroll: Add Employee to Payroll Run

Use an HTTP module pointed at your payroll API’s employee creation endpoint. Map compensation, pay frequency, and employment type from the Data Store row. If your payroll system requires a separate tax-information step, add an additional module here and send the candidate a follow-up email (via a Make.com email module) with the link to complete their tax forms.

Module 7 — Slack or Teams: Notify HR Ops and IT

Send a dual notification: one to the HR ops channel confirming HRIS and payroll provisioning is complete, one to the IT provisioning channel with the new hire’s name, start date, and role so equipment and system access requests can begin. Include the signed document archive link for the HR ops notification.

Module 8 — Make.com Data Store: Mark Row as Completed

Update the Data Store row with a status: completed field and a completed_at timestamp. This powers your nightly cleanup routine and gives you a queryable audit log of every hire that passed through the workflow.

Error Handling: What to Build Before Going Live

Error handling is not optional — it is the difference between a workflow that runs in production and one that runs in a demo. Add error handlers to every module that calls an external API. Make.com’s error-handler route (the red connector) lets you define fallback behavior per module without stopping the entire scenario.

The error-handling pattern for this workflow: on any HTTP 4xx error, send an immediate Slack alert with the module name, the error code, the candidate name, and the application ID. On any HTTP 5xx or timeout error, configure Make.com to retry up to three times with exponential backoff (30 seconds, 2 minutes, 10 minutes), then alert if all retries fail. On the PandaDoc Create Document module specifically, add a duplicate-check filter before the module runs — query PandaDoc for documents with the same candidate email created in the last 24 hours to prevent double-sending if the ATS fires the webhook twice.

For a catalog of the mistakes that break Make.com HR automation in production, read our analysis of 11 critical Make.com mistakes to avoid for successful HR automation.

Testing Protocol Before Production Launch

Test in this exact sequence to catch integration failures before they affect real candidates. First, run Scenario 1 with a test ATS webhook payload using a sandbox candidate record. Verify the PandaDoc document is created in draft, sent to the test email address, and the Data Store row is written correctly. Second, complete the sandbox document by signing it as the test candidate. Verify Scenario 2 fires, retrieves the Data Store row, downloads the PDF, and writes the HRIS and payroll records. Third, intentionally break each external API call — use an invalid API key, a missing required field, and a malformed endpoint URL — and verify your error handlers fire the correct Slack alerts and do not leave partial records in HRIS or payroll.

Run the full test sequence three times with different employment types (full-time exempt, full-time non-exempt, contractor) to confirm template routing and HRIS field mapping work correctly across all variants. Document the expected output for each test run in a checklist so future maintainers can re-run validation after any template or HRIS schema change.

For the broader strategic case for automating the document layer of onboarding, see our breakdown of 11 signs it’s time to automate your HR documents with PandaDoc and Make and our post on 12 critical mistakes to avoid in PandaDoc HR automation.

Deployment and Ongoing Maintenance

Activate both scenarios in Make.com and set each to run immediately on trigger (not on a schedule). Set the maximum number of concurrent executions to 5 for Scenario 1 and 3 for Scenario 2 — this prevents queue buildup during high-volume hiring periods without overwhelming your HRIS API rate limits.

Maintenance items after launch are limited to three categories: offer-letter template updates when compensation structures or legal terms change (update the PandaDoc template and re-test token mapping), HRIS field-schema updates when your HRIS adds or renames required fields (update the HTTP module body mapping in Scenario 2), and quarterly review of error-handler logs to identify drift — API endpoints that have changed, rate limits that have tightened, or new required fields added by vendors without notice.

The $103K annual labor hours Make.com automation case study documents the measurable impact this class of workflow delivers at scale. For teams evaluating whether the investment in this build is justified, that case study provides the cost-per-hire and time-to-productivity data points your CFO will ask for.

If your organization needs this workflow built and validated without the internal build hours, the 4Spot Make.com HR document management practice delivers production-ready scenarios through our OpsSprint™ engagement model, with OpsBuild™ for organizations that need full-stack integration across ATS, HRIS, and payroll, and OpsCare™ for ongoing scenario maintenance after launch.

Frequently Asked Questions

How long does the full build take?

Six to eight hours is the realistic range for an experienced Make.com builder. The first hour covers credential configuration and Data Store setup, the next four hours cover building and connecting the two scenarios, and the final one to three hours cover testing across employment types and error-handler configuration. Builders new to PandaDoc’s API should add two hours for template token debugging.

What credentials do I need before starting?

Six credential sets are required before opening Make.com: ATS API credentials and webhook secret, PandaDoc API key, HRIS API credentials, payroll API credentials, Google Drive or SharePoint OAuth tokens, and a Slack or Teams incoming webhook URL. Assembling all six before starting eliminates the most common build interruption — mid-session credential requests that break flow and introduce copy errors.

Can the same architecture handle international hires?

Yes — add conditional routing in Scenario 1 after the ATS data-retrieval module, branching on the candidate’s country field. Each branch maps to a country-specific PandaDoc template and routes to country-specific HRIS and payroll API endpoints in Scenario 2. The Data Store handoff structure requires no changes; add a country_code column to carry the routing context through to Scenario 2.

What is the maintenance burden after launch?

Maintenance is low once the workflow is in production. The three recurring items are: updating PandaDoc templates when offer-letter terms change, updating HRIS module field mappings when your HRIS vendor adds or renames required fields, and reviewing error-handler logs quarterly to catch API drift before it causes silent failures. No ongoing developer involvement is required for routine operations.