How to Automate Job Offer Letters with Make Data Mapping: A Step-by-Step Guide

Make’s data mapping module pulls candidate data directly from your ATS or system of record, inserts it into a dynamic offer letter template, applies conditional logic for variable compensation, routes the document for internal approval, and delivers it to the candidate for e-signature — with zero manual data entry between trigger and send.

Offer letter errors are not a formatting problem. They are a data integrity problem. When a recruiter manually copies a salary figure from an ATS into a Word document, the risk of a transcription mistake is present on every single offer. Mapping your data flows before you build is the step that eliminates that manual handoff. This guide builds one specific workflow: a Make™ scenario that pulls candidate data from your system of record, maps it to a dynamic template, applies conditional logic for variable compensation, routes for approval, and delivers for e-signature — without a recruiter touching a keyboard between trigger and send.

Built correctly, this workflow cuts offer turnaround from hours to minutes and removes the class of errors that cause payroll discrepancies. Built incorrectly — starting with the template before fixing the source data — it automates the mistakes faster.

Before You Start

Build nothing until these prerequisites are confirmed. Skipping this section is the single most common reason this workflow breaks in production.

• ATS or data source access: You need API credentials or webhook access to your candidate system of record. If your ATS does not expose an API, a Google Sheet or Airtable base works as the data layer — but it must stay in sync with your ATS manually or via a separate sync workflow.
• Standardized field naming: Every candidate record must store salary, start date, job title, and name fields in a consistent format. A salary stored as 95000 in one record and $95,000 in another breaks your mapping or produces garbled output. Audit and clean before you build.
• Document tool selection: Choose Google Docs (fastest to configure, already in most Google Workspace environments), PandaDoc, or DocuSign. Each has a native Make™ module. Pick one and stick with it — do not split offer types across tools during the initial build.
• E-signature platform: Confirm your e-signature tool is accessible via Make’s app directory. Most major platforms are supported natively.
• Time estimate: A basic build — trigger, mapping, and email delivery — takes two to four hours. A full build with conditional compensation branches, an approval step, and e-signature integration requires one to two days, depending on your ATS API documentation quality.
• Risk threshold: A misconfigured mapping that sends an incorrect offer to a candidate is a compliance and trust risk. Always test with internal email addresses before going live. Run a minimum of five test records covering different compensation structures before activating for real candidates.

Step 1 — Audit and Standardize Your Candidate Data Source

The quality of your offer letter automation is capped by the quality of your source data. Resolve data issues before writing a single mapping rule.

Pull a sample of 20 to 30 recent candidate records that reached the offer stage. Check every field you intend to map:

• Name fields: Are first and last name stored separately? Are middle initials mixed in? Inconsistent name storage produces salutation errors in the final document.
• Salary fields: Is the value stored as a clean number — no currency symbols, no commas? Make’s math functions format it for display, but the source must be a raw number.
• Job title: Is the title stored exactly as it should appear in the offer letter? Inconsistent capitalization or department-specific abbreviations produce unprofessional output.
• Start date: Is the date stored in a consistent ISO format (YYYY-MM-DD)? Make’s date formatters handle the display conversion, but the source format must be uniform.
• Compensation type flag: If you offer variable compensation — commission, equity, sign-on bonus — you need a field in the source record that identifies the compensation structure. This drives the conditional branches you build in Step 4.

If you find inconsistencies, fix them at the source before proceeding. Document the corrected field names and formats — you reference this list in every subsequent step.

Step 2 — Set Up the Trigger in Make

The trigger defines what event causes Make to generate an offer letter. The right trigger depends on your workflow:

• Webhook trigger: Your ATS fires a webhook to Make when a candidate moves to “Offer” stage. This is the cleanest option — no polling, instant execution. Requires your ATS to support outbound webhooks.
• Scheduled trigger with search: Make runs on a schedule (every 15 or 30 minutes), queries your ATS or data source for new “Offer stage” records flagged for processing, and processes the batch. Use this when webhooks are not available.
• Manual trigger via Make webhook + form: An internal form (Google Form, Typeform, or a simple Make webhook URL) submits candidate data directly. Use this for low-volume hiring or when your ATS has no API access at all.

In Make, create a new scenario. Add the trigger module that matches your setup. For a webhook trigger: add the Webhooks module, select “Custom webhook,” copy the URL, and paste it into your ATS outbound webhook configuration. For a scheduled trigger: add your ATS app module (or HTTP module if using a REST API) and configure the search filter for records at the Offer stage.

Run a test trigger and confirm that candidate data arrives in Make’s data inspector in the correct format. Do not proceed to Step 3 until you have a clean test payload with all required fields populated.

Step 3 — Map Candidate Data to the Offer Letter Template

Your offer letter template must use placeholders that match the variables Make sends. The exact syntax depends on your document tool:

• Google Docs: Use double curly brace placeholders — {{candidate_first_name}}, {{job_title}}, {{base_salary}}, {{start_date}}. The Google Docs module in Make replaces these on document creation.
• PandaDoc: Create a template in PandaDoc with token variables. The Make PandaDoc module passes a tokens object that maps field names to values from your trigger payload.
• DocuSign with a Word template: Use the DocuSign tabs approach — anchor text in the Word document defines where data inserts.

In Make, add the document creation module after your trigger. In the module configuration, map each template placeholder to the corresponding field from your trigger data. Use Make’s mapping panel — click into each field, then select the variable from your trigger payload using the data inspector.

Map the following at minimum:

• Candidate first name → salutation placeholder
• Candidate full name → signature block placeholder
• Job title → title placeholder
• Base salary (formatted) → compensation placeholder
• Start date (formatted) → start date placeholder
• Manager or hiring manager name → reporting relationship placeholder
• Company signatory name → company signature placeholder

For salary formatting: use Make’s formatNumber function to convert the raw number to a currency display. Example: {{formatNumber(trigger.salary; 2; "."; ",")}} converts 95000 to 95,000.00. Wrap it in a dollar sign in the template or in the mapping field itself.

Run a test. Review the generated document carefully — every field, not just the ones you are unsure about. Map errors are invisible until you read the output.

Step 4 — Add Conditional Logic for Variable Compensation

Most offer letters are not one-size-fits-all. A commission-eligible role needs a compensation structure section that a salaried role does not. An equity grant requires additional disclosure language. A sign-on bonus triggers a repayment clause.

Make handles this with its Router module. Add a Router after the trigger and before the document creation module. Create one route per compensation type:

• Route 1 — Base salary only: Condition: compensation_type equals salary. This route generates the standard template.
• Route 2 — Base + commission: Condition: compensation_type equals commission. This route uses a template that includes the commission structure section, with additional mapped fields for OTE, commission percentage, and payment schedule.
• Route 3 — Base + equity: Condition: compensation_type equals equity. This route uses a template that includes equity grant details, vesting schedule, and cliff language.

Each route has its own document creation module with the appropriate template. The downstream approval and e-signature modules are identical across routes — connect them after the router converges, or duplicate them per route if approval workflows differ by compensation type.

Test each route individually by sending a test payload with each compensation type value. Confirm the correct template fires on each path.

Step 5 — Route the Document for Internal Approval

No offer letter leaves the building without a human sign-off. The approval step sits between document generation and candidate delivery.

Two common approaches:

• Slack approval: After the document is created, Make sends a Slack message to the hiring manager or HR lead with the document link and two buttons — Approve and Reject. A Make webhook listens for the button response and either continues the scenario (approve path) or sends a notification back to the recruiter (reject path).
• Email approval: Make sends an email to the approver with the document link and a reply-based trigger. Simpler to configure, less reliable for tracking response time.

Add a decision point in the scenario that pauses execution until the approval response arrives. In Make, use the Webhooks module to listen for the approval response, then add a filter that checks the response value before allowing the scenario to continue.

Set a time-to-approval SLA. If approval does not arrive within 24 hours, the scenario fires a reminder to the approver automatically.

Step 6 — Deliver the Offer Letter for E-Signature

After approval, the scenario sends the document to the candidate via your e-signature platform. The Make module for your chosen platform handles this step.

Configure the e-signature module to:

• Address the envelope to the candidate’s email address (mapped from your trigger payload)
• Set the signing order if the company signatory co-signs
• Set the expiration window — typically five to seven business days
• Set up completion webhook so Make receives a notification when the candidate signs

After the candidate signs, add a final step that updates the ATS record status to “Offer Accepted” and sends an internal notification to the recruiting coordinator and hiring manager. This closes the loop — no one needs to check the e-signature platform manually to know a candidate signed.

Step 7 — Test the Full Workflow End to End

Testing one step at a time is not sufficient. Run the entire workflow end to end with internal email addresses before activating it for real candidates.

Test matrix minimum:

• Salaried candidate, no variable compensation
• Salaried candidate with commission
• Salaried candidate with equity
• Candidate with a hyphenated last name
• Candidate with a non-standard start date (first of the month vs. mid-month)

On each test run, review:

• Every mapped field in the generated document — exact text, formatting, and placement
• Approval notification delivery and response handling
• E-signature envelope delivery and recipient address accuracy
• ATS status update after signing
• Internal notification content and delivery

Document any discrepancies and fix them before moving to production. A test failure on an internal address costs nothing. The same failure on a real candidate costs credibility.

Common Mapping Mistakes to Avoid

• Mapping to the wrong data level: Make’s data inspector shows nested objects. If your ATS returns candidate data nested inside a result array, you must map from result[].first_name, not first_name. Mapping the wrong level produces blank fields in the document.
• Skipping number formatting: Raw numbers in a currency field produce unprofessional output. Always apply formatNumber before inserting salary or dollar values into a document.
• Using a single template for all compensation types: Conditional sections inside a single Google Doc template are unreliable at scale. Maintain separate templates per compensation type and route to the correct one via the Router module.
• No error handler on the document creation module: If the document creation API call fails — rate limit, authentication expiry, malformed payload — Make stops the scenario silently unless you have an error handler configured. Add a builtin:Break error handler with retry logic on every external API module in this workflow.
• Forgetting to update the ATS on completion: The workflow is not finished when the candidate signs. Update the source record status in your ATS so recruiters and hiring managers do not work from stale data.

What This Workflow Delivers

A correctly built Make offer letter workflow eliminates manual data entry between ATS and candidate. It enforces the correct template per compensation structure, requires an internal approval before any document reaches a candidate, and closes the loop back to the source system when the candidate signs. The recruiter’s job becomes reviewing and approving — not copying and pasting.

The same approach applies across HR workflows — onboarding packets, policy acknowledgments, benefits enrollment confirmations. The data mapping pattern is identical. Once you have built this workflow, the next one takes a fraction of the time.

If your team needs a structured audit of which HR processes are ready to automate and in what order, the OpsMap™ discovery engagement identifies the highest-leverage starting points before any build begins. The OpsMesh™ framework governs how individual workflows like this one connect into a coherent operations layer across your entire business.