How to Build CRM and HRIS Integration on Make.com: A Step-by-Step Guide

Disconnected CRM and HRIS platforms don’t just create inconvenience — they create risk. When candidate data moves from a sales or recruiting CRM into an HRIS by human hand, every field is a transcription error waiting to happen. Manual entry at the offer stage has produced five-figure payroll discrepancies that no onboarding checklist catches in time. The fix is direct system-to-system integration, and Make.com™ is the platform that makes it buildable without an engineering team.

This guide covers every step required to connect your CRM and HRIS through a Make.com™ automation scenario — from defining what data needs to move, through field mapping, authentication, scenario construction, error handling, and post-launch validation. It is written for HR operations leads, recruiting managers, and the consultants who support them. If you want the strategic context for why this integration matters inside a broader HR automation program, start with Why Hire a Make.com™ Consultant for Strategic HR Automation, then return here to build.

Before You Start

Complete these prerequisites before opening the Make.com™ scenario editor. Skipping them adds debugging hours later.

• Systems access: You need admin or API-level credentials for both your CRM and your HRIS. Read-only access is not sufficient — the integration writes records.
• API availability confirmed: Verify that both platforms expose the endpoints you need. Most mid-market CRMs and HRIS platforms support REST APIs. Check your vendor documentation before designing the scenario.
• Data governance sign-off: Any flow that includes personal employee data — names, compensation, start dates — should be reviewed against your organization’s data handling policies before you build. See HR data security best practices in Make.com™ for a security checklist.
• A written field map: This is not optional. You need a document — even a spreadsheet — that lists every source field, its destination field, the data type of each, the accepted format, and any transformation required. The field map is the blueprint the scenario is built from.
• Time estimate: A focused single-trigger integration takes one to two business days to design, build, and validate. Add time for bidirectional flows, conditional routing, or enterprise systems with complex permission structures.
• Make.com™ account: You need an active Make.com™ account with sufficient operations for your expected monthly volume. Estimate operations by counting the number of modules in your scenario multiplied by the number of records you expect to process monthly.

Step 1 — Define the Integration Trigger and Data Flow Direction

The integration starts with a single question: what event in System A should cause data to move to System B? The answer determines your trigger module and establishes the direction of the flow.

The most common CRM-to-HRIS trigger is a candidate status change — specifically, when a candidate’s CRM record is updated to “Hired” or an equivalent status. That event signals that the record is ready to become an employee profile in the HRIS. Other valid trigger points include a new deal closed in the CRM (relevant for sales headcount triggers), a contract signed, or a background check cleared.

Document the trigger precisely:

• What system fires the trigger? (CRM, HRIS, or a form submission)
• What specific event or field change fires it? (status field equals “Hired”)
• What is the destination system? (HRIS — create new employee record)
• Is this unidirectional or bidirectional? Start unidirectional. Add the return flow only after the first direction is proven stable.
• Who is the system of record for each field? If the CRM and HRIS both store start date, which one wins on conflict?

Write this down. A one-paragraph integration brief prevents scope creep and gives you a test standard to validate against after launch. Familiarize yourself with the HRIS and ATS technical terminology relevant to your platforms before finalizing the trigger definition.

Step 2 — Document Your Field Map

Field mapping is the step that determines whether the integration works or silently corrupts data. Do not skip or abbreviate it.

Create a mapping document with four columns for every field that needs to move:

1. Source field name (as it appears in the CRM’s API or UI)
2. Destination field name (as it appears in the HRIS API or UI)
3. Data type and format (text, number, date — and the exact format expected, e.g., YYYY-MM-DD)
4. Transformation required (split full name into first/last, convert date format, map dropdown values to HRIS equivalents)

Common transformation requirements that trip up first-time integrations:

• Name fields: CRMs often store a single “Full Name” field. Most HRIS platforms require separate First Name and Last Name fields. Build a text-split formula in Make.com™ to handle this.
• Date formats: A date stored as “07/14/2025” in one system must be reformatted to “2025-07-14” for a system expecting ISO 8601. Make.com™’s built-in date parsing handles this, but you must specify it explicitly.
• Dropdown or enumerated values: If your CRM stores department as “Sales” but your HRIS requires a department ID number, you need a lookup table — either a Make.com™ data store or a hardcoded mapping inside the scenario.
• Required vs. optional fields: Identify every field the HRIS requires to create a new record. If the CRM record doesn’t reliably populate those fields, the create-record action will fail. Build a validation step that checks for null values before writing.

This document becomes your test checklist. After the integration runs a live record, you compare the field map against the destination record to confirm accuracy.

Step 3 — Authenticate Both Systems in Make.com™

With your field map complete, open Make.com™ and establish secure connections to both platforms before building any scenario logic.

Navigate to Connections in your Make.com™ account and create a new connection for each system:

• OAuth 2.0: Used by most modern CRM and HRIS platforms. Make.com™ will redirect you to the platform’s authorization page. Log in with the service account or admin credentials and grant the requested scopes. Scope the permissions to the minimum required — if the integration only reads CRM records and writes HRIS records, do not grant delete permissions.
• API Key: Some platforms authenticate via a static API key generated in the platform’s settings. Paste the key into the Make.com™ connection dialog. Store the key only in Make.com™’s connection vault — never in scenario notes, data store text fields, or documentation accessible outside your credential management system.
• Basic Auth: Legacy systems may use username/password authentication. Treat these credentials with the same care as API keys.

After creating each connection, test it using Make.com™’s built-in connection test function. A successful test confirms that Make.com™ can reach the platform and that the credentials are valid. A failed test at this stage is far easier to debug than a failed scenario mid-run.

Name your connections descriptively (e.g., “CRM — HR Integration Service Account”) so future team members understand the purpose without opening the scenario.

Step 4 — Build the Trigger-Action Scenario

Now build the scenario. The structure follows a consistent pattern regardless of which specific platforms you’re connecting.

4a. Set the Trigger Module

Add the first module using your CRM’s native Make.com™ app (if available) or the Webhook or HTTP module if a native app doesn’t exist. Configure it to watch for the event you defined in Step 1 — for example, “Watch Records” filtered to records where status equals “Hired.”

Set the polling interval appropriate to your workflow. Hiring decisions don’t happen by the second — a 15-minute or hourly poll is sufficient for most organizations and conserves your Make.com™ operations budget.

4b. Add a Duplicate Prevention Lookup

Before writing any record to the HRIS, add a search or lookup module that queries the HRIS for an existing record matching the candidate’s unique identifier — typically email address. Configure a router (Make.com™’s conditional branch module) downstream of the lookup:

• Route 1: Record found → route to an Update Record action
• Route 2: No record found → route to a Create Record action

This branch prevents duplicate HRIS profiles and ensures the scenario handles both new hires and re-hires correctly.

4c. Apply Data Transformations

Between the trigger and the create/update action, add any transformation steps your field map identified. Make.com™ handles most transformations inline within module field mappings using its built-in formula language:

• Use split() and array indexing to separate full name into first and last
• Use formatDate() to convert between date formats
• Use an if() expression to apply default values when source fields are null
• Use a Make.com™ data store for dropdown-to-ID lookups when the mapping table has more than five entries

4d. Configure the Write Action

Add the HRIS create or update module. Map every destination field using the transformed values from the previous steps. Complete required fields first. Mark optional fields clearly in your scenario with labels or notes so future maintainers understand which fields the HRIS requires versus accepts.

Run a test execution using a real candidate record (with the candidate’s knowledge if required by your data policies) and compare the resulting HRIS record against your field map document. Fix any discrepancies before proceeding.

Step 5 — Add Error Handling and Alerting

A scenario without error handling is an integration waiting to fail silently. Silent failures are worse than visible ones — they allow corrupted or missing data to propagate before anyone notices.

Add error-handler routes to every module that writes data:

• Right-click the module in Make.com™ and select “Add error handler”
• Choose Resume for non-critical failures (e.g., an optional field that couldn’t be populated)
• Choose Rollback or Break for critical failures (e.g., the create-record action failed entirely)
• On the Break route, add a notification action — an email or Slack message — that sends the failed record’s identifier, the error message, and a timestamp to the responsible HR operations contact

Configure Make.com™’s scenario-level notification settings to alert on incomplete executions. Execution logs are available in Make.com™’s scenario history for every run — including full input and output data at each module — which makes debugging specific failures straightforward.

Also set a token refresh reminder. OAuth tokens expire. If your connection uses OAuth 2.0 with a refresh token, Make.com™ handles refresh automatically — but verify this in the connection settings. Static API keys don’t expire but can be revoked; document where each key was generated so it can be rotated quickly if needed.

Step 6 — Validate with Live Records Before Retiring Manual Processes

Test runs using Make.com™’s built-in sample data are not sufficient validation. Run at least three live records end-to-end through the production scenario before treating the integration as operational.

For each live test record:

1. Trigger the event in the CRM (change a test candidate’s status to “Hired”)
2. Wait for the scenario to execute (or trigger it manually if using a webhook)
3. Open the resulting HRIS record
4. Compare every field against the source CRM record and your field map document
5. Confirm that no duplicate record was created
6. Open the Make.com™ execution log and confirm all modules completed without errors

If any field is wrong, trace it back to the specific module where the value diverged, fix the mapping or transformation, and re-run. Do not retire the manual process until all three live test records pass without intervention.

For context on the financial stakes of getting this right, the real-world HR automation results we’ve documented show that a single data transfer error at the offer stage — the exact failure point this integration prevents — can generate a five-figure payroll discrepancy before the employee’s first paycheck.

Step 7 — Monitor and Maintain the Integration Ongoing

Integrations are not set-and-forget. They require periodic maintenance to remain reliable as platforms update their APIs, credential tokens change, and business rules evolve.

Build a monitoring cadence into the integration’s ownership:

• Weekly: Review Make.com™ execution logs for incomplete or errored runs. Confirm the scenario is executing on schedule.
• Monthly: Run a record count audit — compare the number of “Hired” CRM records from the prior month against the number of HRIS records created via automation. Discrepancies indicate missed triggers or failed writes.
• Quarterly: Review the field map against both systems. Platforms add and rename fields during product updates. A field that disappears in the source or destination without scenario updates causes silent failures.
• On platform updates: When either your CRM or HRIS publishes a major update, review the changelog for API changes. Re-test the scenario after any significant vendor update before trusting it with live records.

Assign an explicit owner for this integration — a specific person, not a team — who is responsible for monitoring alerts and maintaining the scenario. Shared ownership reliably results in no ownership.

For the broader ROI picture of what a well-maintained integration delivers, see quantifying the ROI of HR automation, which covers how to measure time savings, error reduction, and downstream productivity gains attributable to automation investments.

How to Know It Worked

The integration is working when all of the following are true:

• Three or more live records have passed end-to-end with zero field discrepancies
• No duplicate HRIS records have been created during the test period
• Make.com™ execution logs show 100% completion rate with no error routes triggered
• The HR operations owner has received at least one test error notification (confirming the alerting path works)
• The manual data entry process the integration replaces has been formally retired with the team notified
• A monitoring cadence with a named owner is documented and scheduled

Common Mistakes and How to Avoid Them

Building before mapping

Opening the scenario editor before completing the field map produces scenarios that need to be rebuilt. The field map is faster to create than it is to reverse-engineer from a broken scenario. Write the map first, always.

Polling too frequently

Setting a trigger to poll every minute when the business process generates one record per day wastes Make.com™ operations and can trigger API rate limits on the source system. Match the polling interval to the actual frequency of the triggering event.

Skipping the duplicate check

The first time a re-hire or a test record creates a second HRIS profile is the last time the team trusts the integration. The duplicate-check branch takes fifteen minutes to build and prevents a data cleanup project that takes days.

Using personal admin accounts for connections

If the connection is authenticated with an individual’s credentials and that person leaves the organization, every scenario using that connection breaks simultaneously. Create a dedicated service account for each integration with the minimum required permissions, and document where it was created.

Skipping error handler routes

An unhandled error in Make.com™ stops the scenario at the failed module and records the run as incomplete. Without an error-handler notification, that failure may go unnoticed for days while new hire records pile up unprocessed. Error handling is not optional on any module that writes data.

Extending the Integration

Once the core CRM-to-HRIS flow is stable, the same scenario architecture extends to adjacent automation opportunities:

• Onboarding triggers: A new HRIS record can trigger a separate Make.com™ scenario that creates accounts in IT systems, sends onboarding task assignments, and schedules orientation calendar invites. See automating employee onboarding tasks for a step-by-step guide to that flow.
• Compliance logging: Every record write can be logged to a centralized audit trail — a Make.com™ data store or a connected spreadsheet — that captures who was hired, when, and what data was transferred. This supports GDPR and CCPA data lineage requirements.
• Bidirectional sync: After three to six weeks of stable unidirectional operation, add a return flow that pushes HRIS status updates (e.g., employment termination) back to the CRM. Build this as a separate scenario, not an extension of the original, so failures in one direction don’t affect the other.

For the full landscape of what Make.com™ can automate across the HR function — beyond CRM-HRIS integration — see Automate HR with Make.com™: Transform Processes and Strategy.

When to Bring in a Consultant

The steps above are buildable by an HR operations professional with no coding background. But three conditions warrant bringing in a consultant before you start rather than after you’ve built something that needs to be rebuilt:

1. Your integration involves regulated data fields (compensation, SSN, benefits elections) that require specific handling under GDPR, CCPA, or HIPAA
2. Your scenario requires conditional routing based on complex business rules — multiple departments, multiple HRIS regions, or role-based data access controls
3. You need bidirectional sync on day one because the business process requires both systems to remain authoritative simultaneously

In these cases, the cost of a scoped engagement is reliably less than the cost of a misconfigured integration discovered after it has processed hundreds of records. For criteria to evaluate your options, see choosing the right Make.com™ consultant for HR.

The goal of a well-built integration is simple: data moves once, correctly, without human intervention. When that’s true, HR stops being a data entry function and starts being a strategic one — which is exactly the outcome the broader HR automation program is designed to deliver.