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

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 every single time. Data filtering and mapping for HR automation exists precisely to eliminate 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 offer letter template, applies conditional logic for variable compensation, routes the document for approval, and delivers it for e-signature — without a recruiter touching a keyboard between trigger and send.

Done correctly, this workflow reduces offer turnaround from hours to minutes and removes the class of errors that produce payroll discrepancies. Done incorrectly — starting with the template before fixing the 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 fails 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 can serve as the data layer — but it must be kept 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 will break your mapping or produce 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 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: Basic build (trigger + mapping + email delivery) takes two to four hours. Full build with conditional compensation branches, approval step, and e-signature integration typically requires one to two days, depending on your ATS API documentation quality.
• Risk: A misconfigured mapping that sends an incorrect offer letter 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.

Open your ATS or data source and 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 there middle initials mixed in? Inconsistent name storage produces salutation errors in the letter.
• Salary fields: Is the value stored as a clean number (no currency symbols, no commas)? Make’s™ math functions can 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, or does your ATS use abbreviated internal codes?
• Start date: Is it stored in a consistent date format? Make’s™ date formatting functions handle conversion, but you need to know the source format to configure the function correctly.
• Compensation type indicator: If you have candidates with bonuses, equity, or relocation packages, is there a field that flags which compensation structure applies? This field drives your conditional logic in Step 5.

Document the exact field names as they appear in the ATS API response. You will use these names in Step 4. For a deeper treatment of field standardization across ATS custom fields, see our guide on mapping resume data to ATS custom fields.

McKinsey Global Institute research on knowledge worker productivity consistently identifies data rework — correcting errors in records that were wrong at the point of entry — as one of the highest-cost hidden activities in administrative workflows. Eliminating the source of those errors is more valuable than automating around them.

Step 2 — Build and Tag Your Offer Letter Template

Your template is the static structure of the offer letter. Make’s™ mapping will inject dynamic values into named placeholders at runtime.

In Google Docs (or your chosen document tool), create the full text of your standard offer letter. Every piece of information that will vary by candidate becomes a placeholder. Use a consistent naming convention — double curly braces are the most common:

• {{candidate_first_name}}
• {{candidate_last_name}}
• {{position_title}}
• {{department}}
• {{base_salary}}
• {{start_date}}
• {{manager_name}}
• {{offer_expiration_date}}

For conditional sections — content that appears only for certain candidates — use section markers your document tool supports. In PandaDoc, this is a native conditional block. In Google Docs, you will handle conditionality in Make’s™ Router (Step 5) by generating a separate template variant for each compensation structure, or by using Make’s™ text aggregator to build the conditional section as a string before inserting it into a single template.

Save the template as a master copy that Make™ will duplicate for each offer, not overwrite. In Google Docs, the standard approach is to have Make™ copy the template file, rename the copy with the candidate’s name and date, and then populate the copy. The master template remains untouched.

Step 3 — Configure the Make Scenario Trigger

The trigger determines when the workflow fires. Choose the trigger that matches your hiring process — do not let the trigger become a workaround for a broken approval process.

Recommended trigger: A webhook or polling module that fires when a candidate’s ATS status changes to your designated offer stage (e.g., “Offer Approved,” “Ready to Send”). This is the cleanest trigger because it reflects a deliberate human decision — the hiring manager has approved the offer — before automation takes over the mechanical delivery work.

Alternative trigger: A new row added to a Google Sheet, if your ATS does not support webhooks. This requires a recruiter to manually add a row as the trigger action, which reintroduces a human step but keeps the rest of the workflow automated.

In Make™, go to Create a New Scenario. Add your trigger module — this will be your ATS’s Watch Events module, a Webhooks module set to Custom Webhook, or the Google Sheets Watch Rows module. Configure the trigger to return the full candidate record, not just the status change event. You need all candidate fields in the same payload to avoid a second lookup step.

Test the trigger by manually moving a test candidate to the offer stage in your ATS and confirming Make™ receives the payload. Inspect the received data structure carefully — note the exact key names for each field. These are what you will use in Step 4.

Step 4 — Map Candidate Fields to Template Placeholders

This is the core of the workflow. Precision here is what separates a reliable automation from one that requires constant manual correction.

Add the document generation module to your scenario. For Google Docs, this is the Google Docs > Replace Text in a Document action on the copied template file. For PandaDoc or DocuSign, use their respective Make™ modules for creating a document from a template.

In the module configuration, you will see a field for each placeholder you defined in Step 2. For each placeholder, click into the field and select the corresponding output value from your trigger module’s data payload. This is the mapping step:

• {{candidate_first_name}} → mapped to the first_name field from your ATS payload
• {{position_title}} → mapped to the job_title field
• {{base_salary}} → mapped to the salary field, with a formatNumber function applied to add currency formatting
• {{start_date}} → mapped to the start_date field, with formatDate applied to convert from ISO format to a human-readable string

Use Make’s™ built-in text and date functions directly in the mapping field — you do not need a separate function module for most formatting operations. For more complex transformations, the essential Make filters for recruitment data guide covers the filtering and transformation functions that apply here.

Run a test with a real (internal) candidate record. Download the generated document and read every field. Confirm that no placeholder text remains unfilled and that formatting is correct. Do not proceed to Step 5 until this test passes cleanly on at least three different candidate records.

Step 5 — Add Conditional Compensation Logic with a Router

Standard base-salary-only offers require no branching. If your organization uses bonuses, equity grants, sign-on payments, or relocation allowances, you need a Router module to handle each compensation structure without maintaining a separate template for every variant.

After your trigger module and before your document generation module, insert a Router. Each Router path represents one compensation structure:

• Path 1 — Base salary only: Filter condition: compensation_type equals “standard.” Maps base salary fields only.
• Path 2 — Base + bonus: Filter condition: compensation_type equals “bonus_eligible.” Maps base salary plus bonus_percentage or bonus_target fields.
• Path 3 — Base + equity: Filter condition: compensation_type equals “equity.” Maps base salary plus equity_grant_amount and vesting_schedule fields.
• Path 4 — Executive / custom: Filter condition: compensation_type equals “executive.” Routes to a separate approval workflow rather than auto-generating the document.

Each path connects to its own document generation module configured with the appropriate field mappings for that compensation structure. If you are using Google Docs, each path can reference the same master template (which contains all possible placeholders) — unused placeholders in a given path are simply left blank or removed via a text-replacement rule that maps them to an empty string.

This router architecture is the same conditional logic framework used in interview scheduling automation with conditional logic — the pattern transfers directly.

Step 6 — Insert an Approval or Pre-Send Review Step

Full automation without a review checkpoint is appropriate only after you have validated the workflow across enough real-world records to trust the data quality. For new builds, keep a human-in-the-loop step before the document reaches the candidate.

Lightweight approval option: After document generation, add an Email or Slack module that sends the generated document link to the responsible recruiter with an approve/reject prompt. Use Make’s™ Webhooks module to receive the approval response. If approved, the scenario continues to e-signature delivery. If rejected, the scenario routes to a notification that prompts the recruiter to correct the source record in the ATS and re-trigger.

Structured approval option: For organizations with formal offer approval chains (HR director sign-off, legal review, finance confirmation), build a sequential approval flow where each approver receives a notification only after the previous approver confirms. Make’s™ scenario can hold execution in a waiting state by polling a status field updated by each approver’s response.

Asana research on knowledge worker time allocation consistently finds that approval bottlenecks — not the work itself — are the primary driver of process delays. A well-configured approval step in Make™ is faster than an email chain and produces a documented audit trail, which matters for offer letter compliance. For a full treatment of error handling and approval resilience, see the guide on error handling in Make workflows.

Step 7 — Connect E-Signature and Confirm Delivery

After approval, the document routes to your e-signature platform. Add the appropriate module for your tool — PandaDoc Send Document, DocuSign Create Envelope, or Adobe Sign Send Agreement. Configure the module with:

• The generated document file or document ID from Step 4 or 5
• The candidate’s email address (mapped from the trigger payload)
• The signing deadline (calculate from offer_expiration_date using Make’s™ date functions)
• The internal copy recipients (recruiter, HR director, hiring manager)

After the e-signature module, add two confirmation steps:

1. Notification: Send a confirmation to the recruiter and hiring manager that the offer letter has been delivered, including the candidate’s name, position, and offer expiration date.
2. ATS update: Use your ATS’s Update Candidate or Update Application module to log the offer send event — date sent, document ID, and expiration date — directly in the candidate record. This eliminates the manual ATS update that recruiters typically forget to make after sending an offer.

Parseur’s Manual Data Entry Report estimates the cost of a single manual data entry employee at $28,500 per year when accounting for salary, time, and error correction. The ATS update step alone — eliminating the need for a recruiter to manually log each offer send — is a measurable time recovery at scale. Gartner research on talent acquisition technology similarly identifies administrative logging tasks as a primary candidate for elimination in high-volume hiring environments.

How to Know It Worked

Before activating the workflow for live candidates, run a structured validation sequence:

• Test 1 — Standard compensation: Trigger with a base-salary-only candidate record. Confirm the generated document contains no unfilled placeholders, salary is formatted correctly, and start date is human-readable.
• Test 2 — Variable compensation: Trigger with a bonus-eligible record. Confirm the correct Router path executed and the bonus field appears in the document.
• Test 3 — Missing field: Trigger with a record that has a blank start_date field. Confirm the error handler catches it, blocks document generation, and sends the alert notification to the recruiter.
• Test 4 — Approval rejection: Trigger a standard offer, then reject it at the approval step. Confirm the scenario does not proceed to e-signature delivery and the rejection notification is sent correctly.
• Test 5 — ATS log: After a successful end-to-end test, open the candidate record in your ATS and confirm the offer send event was logged with the correct date and document reference.

All five tests must pass before the workflow is activated for production use. Document the test results — date, tester, outcome — as a baseline for future troubleshooting. SHRM data on hiring process consistency indicates that documented, standardized offer processes directly reduce time-to-offer and improve candidate acceptance rates by reducing the perception of disorganization.

Common Mistakes and How to Avoid Them

Mistake 1 — Building the template before auditing the data

The template is the last step of the design process, not the first. Every hour spent on template design before the data is clean is potentially wasted when you discover that your ATS stores salary as a formatted string rather than a number. Audit data first. Always.

Mistake 2 — Using a single template with unfilled placeholders for inapplicable fields

A candidate who does not have an equity grant should not receive a letter with {{equity_grant_amount}} visible in the text. Either use Router branching to generate from the correct template variant, or map inapplicable placeholders to empty strings explicitly. Do not rely on the document tool to ignore unfilled placeholders — most will not.

Mistake 3 — Skipping the ATS status update at the end of the workflow

When the ATS is not updated automatically, recruiters update it manually — inconsistently, incompletely, and often days late. The scenario closes the loop only when the ATS record reflects the current state of the offer. Build the update step in from the start.

Mistake 4 — Removing the approval step too early

Full automation without approval is appropriate after the workflow has proven itself across 30 to 50 real offers without errors. Remove the approval step incrementally: first make it optional for standard offers, then conditional only for executive packages. Earn the automation, do not assume it.

Mistake 5 — Ignoring error handling on the mapping module

A null value in a required field does not cause Make™ to fail visibly by default — it can produce a document with a blank where the salary should be, which then reaches the candidate. Configure an error handler on every mapping module that catches null or empty values and routes to a human alert before document generation runs. The guide on eliminating manual HR data entry with Make covers error prevention architecture in more detail.

What Comes Next

The offer letter workflow is not a standalone automation — it is the entry point for the entire onboarding sequence. Once the signed document returns from e-signature, the same Make™ scenario can fire a second trigger that creates the HRIS employee record, provisions IT equipment, assigns onboarding tasks, and schedules the first-day orientation. The candidate data payload that generated the offer letter contains everything needed to start all of those downstream processes.

That downstream extensibility is why getting the mapping architecture right from the beginning matters. A mapping layer built on clean, standardized source data becomes a reusable foundation. A mapping layer built on inconsistent data becomes a liability that requires constant manual correction. The principles that govern this workflow — enforce data quality at the source, then automate the mechanical work downstream — are the same principles covered across the production-grade HR data pipeline in the parent pillar.

For the next layer of the onboarding sequence, the guide on onboarding data precision with Make filtering shows how to apply the same filtering and mapping logic to post-offer workflows.