
Post: How to Automate Application to Onboarding with PandaDoc and Make: A Step-by-Step HR Workflow
To automate application to onboarding with PandaDoc and Make, connect your ATS webhook to a Make scenario that creates and sends an offer letter from a PandaDoc template, then chain a second scenario triggered by the candidate’s signature to deliver the onboarding packet. The full pipeline runs in five discrete, testable loops.
Asana’s Anatomy of Work research found that knowledge workers spend more than 60% of their time on work about work: status updates, manual handoffs, and repetitive document tasks rather than skilled work. In HR, that ratio skews worse. The application-to-onboarding gap is where most recruiting wins quietly disappear – candidates disengage, data gets re-typed, and documents sit unsigned in inboxes. Your HR document automation strategy only delivers if the pipeline itself is automated end to end.
Before You Start
Complete every item on this list before opening Make. Building on an unvalidated foundation is the single largest source of rework in HR automation projects.
- ATS access: Confirm your ATS exposes candidate status changes via webhook or native automation module. You need to trigger an external action when a candidate reaches “Offer Extended” status.
- PandaDoc account with API access: API access is required to programmatically create and send documents. Verify your plan includes this feature before building.
- Make account: You need an active Make account configured with the PandaDoc and ATS modules. For integration setup notes, see our guide on architecting your HR automation integrations.
- Field mapping document: List every data field your offer letter and onboarding documents require – candidate name, role title, start date, manager name, department, location – and confirm the exact field names your ATS uses for each. Mismatched field names are the most common build failure.
- PandaDoc templates built and tested: Your offer letter and onboarding packet templates must exist in PandaDoc with tokens matching the field names in your mapping document before the Make scenario references them.
- HRIS write access (optional but recommended): If you plan to sync completed new-hire data downstream to payroll or your HRIS, confirm API credentials and field requirements before build day.
- Time budget: Reserve 8-12 hours for a focused first build. Add time if you are configuring onboarding packets, multi-step signing sequences, or HRIS sync in the same sprint.
Step 1 – Map the Entire Data Flow Before Touching a Single Tool
Before opening Make, draw the complete data flow on paper or a whiteboard. Every field that appears in a PandaDoc document must have a confirmed source system and a confirmed field name in that source. Every status trigger must have a confirmed webhook or API event name.
Your map must answer five questions for every step in the pipeline:
- What event triggers this step?
- What data does this step need?
- Where does that data come from?
- What does this step produce or send?
- What happens if this step fails?
A typical application-to-onboarding map looks like this:
- ATS: Candidate status changes to “Offer Extended” – webhook fires
- Make scenario: Receives webhook payload, extracts candidate fields, calls PandaDoc API to create document from template, sends document to candidate email
- PandaDoc: Candidate signs offer letter – webhook fires “document completed”
- Make scenario: Receives completion webhook, triggers onboarding packet creation and delivery
- PandaDoc: New hire completes onboarding forms – webhook fires
- Make scenario: Extracts completed field data, writes to HRIS or payroll system, notifies hiring manager and IT provisioning team
Teams that build directly in Make without a data-flow map consistently discover mid-build that a required field doesn’t exist in the source system, or that two systems use different naming conventions for the same field. That discovery mid-build costs more time than the mapping exercise would have.
Expert Take
The field mapping document is the most overlooked artifact in any HR automation build. Data mismatches between ATS field names and PandaDoc token names account for the majority of document generation failures – and they are entirely preventable with 30 minutes of upfront mapping. Build the map before you open Make, not after your first failed test run.
Step 2 – Build Your PandaDoc Templates with Merge Tokens
Every field that automation will populate must be a PandaDoc token – a merge field in the format {{field_name}} – that exactly matches the field name your Make scenario passes via API. The essential PandaDoc features HR teams must master covers token configuration in detail.
For an offer letter, your template typically includes tokens for:
- Candidate full name, preferred name
- Role title, department, location
- Start date, base compensation structure, bonus structure if applicable
- Reporting manager name and title
- Benefits eligibility date
- Offer expiration date
- Company signatory name and title
For conditional content – displaying different benefit clauses for full-time vs. part-time, or different non-compete language by state – use PandaDoc conditional content blocks tied to a token value passed by Make. One template then handles every employment type without branching your scenario logic.
After building the template, generate a manual test document using hard-coded values for every token. Review the rendered document in full before connecting it to Make. Fixing a template layout error after the automation is live means re-testing the entire scenario.
Build the same way for your onboarding packet: I-9 instructions, direct deposit authorization, benefits enrollment, policy acknowledgment – each as a PandaDoc template with appropriate tokens and signature fields assigned to the correct signer role.
Step 3 – Configure the Offer Letter Trigger Scenario
This is the first live scenario you build. Keep it narrow: one trigger, one document, one recipient.
Trigger configuration: Set your Make scenario to listen for your ATS’s “offer extended” webhook event. The webhook payload contains the candidate’s record – extract the fields that match your PandaDoc token names.
Data transformation (if needed): If your ATS sends compensation as a formatted string but PandaDoc expects a raw number, add a data transformation step in Make to strip formatting before passing the value. Standardize date formats between systems at the same step. This is the most common source of document generation errors – see our PandaDoc HR automation mistakes guide for the full checklist.
PandaDoc API call: Configure the Make step to call the PandaDoc “Create Document from Template” API endpoint. Pass:
- The template ID for your offer letter
- All mapped field values as key-value pairs matching your token names
- The candidate’s email address as the recipient with “Signer” role
- Your company signatory’s email as the second signer if dual-signature is required
- Document name formatted as: Offer Letter – [Candidate Name] – [Role Title]
Send immediately or route for internal review? For most organizations, the offer letter auto-sends directly to the candidate. If your process requires a hiring manager to review before sending, add an approval step: the scenario creates the document in “Draft” status, notifies the manager with a PandaDoc review link, and a separate trigger (manager approval) advances the document to “Send.”
Build this scenario as a complete, validated standalone before adding downstream steps. Run it live for two weeks with zero errors on real candidates before chaining the onboarding packet trigger. That single validated loop is the highest-leverage build decision you will make in this project.
Step 4 – Build the Offer Completion to Onboarding Packet Trigger
Once the offer letter scenario is validated, add the next loop: when the candidate signs, automatically generate and deliver the onboarding packet. For additional patterns, see onboarding automation wins HR teams miss.
Trigger: PandaDoc fires a “document completed” webhook when all required signatures are collected. Configure your Make scenario to listen for this event, filtered to offer letter documents only – use document template ID or document name pattern as the filter.
ATS status update: As a first action in this scenario, call your ATS API to update the candidate’s status to “Offer Accepted.” This closes the loop back into your ATS so pipeline reporting stays accurate without manual updates.
Onboarding packet generation: Create each onboarding document from its PandaDoc template, passing the same candidate field values already captured in the offer letter scenario. If Make stores the candidate data in a data store or passes it through the scenario chain, retrieve it there rather than making a second ATS API call.
Staggered delivery vs. packet delivery: Send all onboarding documents as a single PandaDoc packet – the candidate completes all forms in one session – or send them in sequence tied to completion of the prior document. The packet approach produces better completion rates; the candidate sees a clear, bounded task rather than an open-ended document stream.
Reminder sequence: Configure PandaDoc’s automated reminder schedule (48 hours after send, then 24 hours before a deadline). Add a Make step that monitors document status after 72 hours and sends an internal Slack or email alert to the recruiter if the packet remains incomplete – without requiring anyone to manually check PandaDoc.
Step 5 – Close the Loop: Sync Completed Data to HRIS and Notify Stakeholders
When all onboarding documents are completed and signed, the automation pushes structured data downstream – eliminating the second round of manual data entry that most HR teams still handle today. See Make automations for the full employee lifecycle for field mapping patterns across common HRIS platforms.
HRIS / payroll sync: Configure a scenario triggered by the onboarding packet’s “document completed” webhook. Extract confirmed field values from the PandaDoc completion payload and write them to your HRIS via API: legal name, start date, pay rate, tax election selections, benefits choices, direct deposit information.
Internal notifications: At the same trigger point, fire notifications to every stakeholder who needs to act before day one:
- IT provisioning: new hire name, start date, role, department (triggers equipment and access provisioning)
- Hiring manager: confirmation that all paperwork is complete, start date reminder
- Facilities (if applicable): desk assignment, badge access
- Payroll: new employee record creation confirmation
ATS final status update: Move the candidate record to “Hired” and log a note with the onboarding completion timestamp. This keeps your ATS data clean and ensures time-to-hire reporting reflects the actual close date.
How to Know It Worked
Run three to five end-to-end tests with real or realistic test candidate data before activating the automation for live hiring. Verify each of the following:
- Every token populates correctly: Open the generated PandaDoc document and confirm every field shows the correct candidate value, not a raw token string or blank.
- Conditional content renders correctly: Test one full-time, one part-time, and one contractor scenario if your template uses conditional blocks. Confirm the correct clauses display and the incorrect ones are hidden.
- Reminder emails fire on schedule: Advance the test clock or use a short test interval to confirm the reminder sequence activates correctly.
- Completion webhook triggers the next scenario: Sign the test document as the candidate and confirm the onboarding packet is generated and delivered within the expected window.
- HRIS data writes correctly: Open the new employee record and confirm all synced fields contain correct values, including any that required data transformation.
- ATS status updates at each stage: Confirm the ATS record reflects “Offer Sent,” “Offer Accepted,” and “Hired” at the correct points in the sequence.
- Stakeholder notifications arrive: Confirm IT, the hiring manager, and payroll receive their respective notifications with correct data.
If any check fails, fix and re-test before going live. A broken automation running on live candidates is harder to remediate than a delayed launch.
Common Mistakes and How to Avoid Them
These five errors account for the majority of failed HR automation builds. Check each before and during your build.
Mistake 1 – Building the Entire Pipeline Before Testing the First Loop
Build the offer letter trigger as a complete, validated loop. Run it live for two weeks on real candidates with zero errors. Then build the onboarding packet trigger. Incremental deployment catches integration issues when they are cheap to fix.
Mistake 2 – Skipping Field Mapping Validation
A field name mismatch between the source system and the PandaDoc token is the most common cause of document generation failure. Map every field explicitly before building. Test with real data. Assume nothing matches until you confirm it does. See HR data mapping mistakes to avoid for a full diagnostic checklist.
Mistake 3 – Forgetting Error Handling
Every Make step that calls an external API needs an error handler configured. If the ATS webhook payload is missing a required field or the PandaDoc API call fails, the scenario must notify a human immediately rather than fail silently. A missed offer letter with no alert is worse than a manual process.
Mistake 4 – Treating the Onboarding Packet as One Undifferentiated Document
I-9 verification has legal timing requirements. Separating compliance documents from general new-hire paperwork in your delivery sequence prevents a completed benefits form from creating a false sense of completion before time-sensitive compliance documents are signed. Structure your packet to surface compliance documents first.
Mistake 5 – Not Updating the ATS at Each Automation Stage
If your ATS doesn’t reflect the current candidate stage, pipeline reporting breaks down and recruiters manually check PandaDoc to determine status – defeating the purpose of automation. Every scenario stage must write a status update and timestamped note back to the ATS record.
Expert Take
Mistake 3 is the hardest to catch after the fact. Most Make scenario failures during a live hire surface when a recruiter notices the candidate hasn’t responded – not when the system flags it. By then, the candidate has disengaged or taken another offer. Build the error handler before you run a single live test, not after your first production failure.
Scale From Here
Once your application-to-onboarding pipeline is validated and running, the same data-flow architecture supports additional automation layers with minimal incremental build effort. McKinsey Global Institute estimates roughly 56% of current HR administrative tasks are automatable with existing technology – the application-to-onboarding pipeline is among the highest-yield targets in that set.
- Employee handbook distribution and acknowledgment tracking – see 13 best practices for high-ROI automated onboarding for the build pattern.
- Annual policy re-acknowledgment triggered by employee anniversary dates
- Promotion and role-change document generation triggered by HRIS status changes
- Contractor NDA and engagement letter automation triggered by vendor management system events
The compounding value of this architecture is that each new document type reuses the same trigger patterns, template token conventions, and completion webhook structure you built in Steps 3 through 5. Each addition takes hours, not weeks.
The pipeline this guide builds is not a pilot. It is production infrastructure. Build it once, validate it thoroughly, and it runs every hire from that point forward – without anyone on your team touching a template, typing a name, or chasing a signature.
Frequently Asked Questions
What systems do I need to automate application-to-onboarding with PandaDoc and Make?
You need an ATS that exposes candidate status changes via webhook, a PandaDoc account with API access enabled, and an active Make account. Most mid-market ATS platforms expose webhooks or have native Make modules that make the integration straightforward.
How long does it take to build this automation end to end?
A focused build covering offer letter generation through onboarding packet delivery takes 8 to 12 hours for someone comfortable with Make. A first-time builder should budget additional time for template configuration and testing.
Do candidates need a PandaDoc account to sign documents?
No. Recipients receive an email link and sign directly in their browser without creating an account.
Can one PandaDoc template handle multiple employment types?
Yes. PandaDoc conditional content blocks display or hide sections based on field values passed by Make, so a single template renders full-time, part-time, or contractor documents without branching your scenario logic.
What is the first automation to build if I am starting from scratch?
Build the offer-letter trigger first: ATS status change triggers a Make scenario that generates and sends the PandaDoc document. This single loop delivers the highest visible impact and proves the integration end to end before you chain any downstream scenarios.

