Eight Make.com™ steps automate the complete candidate screening workflow from application received to shortlist decision in under 10 minutes, eliminating 4–6 hours of recruiter administrative work per open role per week. The workflow handles parsing, scoring, ATS updates, candidate communications, and exception routing without human intervention until a shortlist decision is required. Here is each step in build sequence.

Step 1: How Do You Configure the Make.com Webhook Trigger for New Applications?

In Make.com™, create a new scenario with a Webhooks module as the trigger. Configure your ATS to POST to the Make webhook URL on each new application event. Immediately after the trigger, add a Tools > Set Variable module that captures the application timestamp and a unique run ID. This creates an auditable record even if the scenario fails downstream. The run ID links to your error log for troubleshooting.

Step 2: How Do You Retrieve the Resume File in Make.com?

Add an HTTP module configured as a GET request to your ATS’s attachment API endpoint using the application ID from Step 1. Map the response body to a binary data variable. If the GET returns empty or a non-200 status, route to an error branch (covered in Step 8). The binary data variable passes to the AI parsing module in Step 3. Always validate file size – resumes above 5MB frequently cause timeouts in downstream parsing calls.

Step 3: How Do You Call an AI Resume Parser From Make.com?

Add an HTTP module as a POST request to your parsing service API (Affinda, Sovren, or equivalent). Set Content-Type to multipart/form-data and attach the binary data from Step 2. Map the JSON response to named variables: skills array, experience years, education level, location. These four variables feed the scoring module in Step 4. Log the parse confidence score – any confidence below 80% triggers the manual review branch in Step 7. See must-have features for AI resume parser performance for parser selection and confidence scoring criteria.

Step 4: How Do You Score Candidates Inside a Make.com Scenario?

Add a Tools > Set Variable module with a numeric expression that calculates the rubric score: required skills intersection × 0.40 + experience years check × 0.20 + education match × 0.15 + location fit × 0.15 + keyword density × 0.10. Make.com™ evaluates this expression natively – no external function call required. The resulting 0-100 score passes to the routing decision in Step 5. See the Make.com HR recruiting scenario guide for the full scoring expression syntax.

Step 5: How Do You Route Candidates Based on Score in Make.com?

Add a Router module with three branches: Branch 1 (score ≥ 65): advance to shortlist; Branch 2 (score 40–64): hold for secondary review; Branch 3 (score < 40): screen out. Each branch executes a different set of downstream actions. The three-branch structure handles the full range of screening outcomes without additional logic – secondary review exists to catch borderline candidates who deserve human evaluation before rejection.

Step 6: How Do You Update the ATS and Send Candidate Communications in Make.com?

In each routing branch, add: (1) an HTTP PATCH module writing the score and decision to your ATS custom fields, and (2) an email or SMS module sending a status notification to the candidate. Shortlisted candidates receive an interview scheduling link via Calendly. Screened-out candidates receive a professional decline message with a future consideration opt-in. The ATS update and candidate communication execute in parallel using Make’s parallel route feature – total execution time under 8 seconds.

Step 7: How Do You Handle Parse Exceptions in Make.com?

Add a Router branch checking parse confidence: any resume with confidence below 80% bypasses scoring and routes to a Slack notification to the recruiting team with the application URL and a “Parse Exception” label in the ATS. Parse exceptions run in the 3-8% range for most deployments. The recruiter reviews these manually within 24 hours. Log every exception to a Google Sheet for monthly quality analysis – parse exception rates above 10% signal a formatting mismatch between your applicant pool and your parser’s training data.

Step 8: How Do You Build Error Handling for the Full Make.com Scenario?

Enable Make.com™’s Error Handler module on every HTTP call and on the router. Configure all errors to write to a dedicated error log (Google Sheet or Airtable) with the scenario run ID, error type, timestamp, and affected application ID. Set a daily digest that emails the recruiting team any error log entries from the previous 24 hours. A well-built error handler means every failed execution is visible, trackable, and resolvable – not silently dropped.

Expert Take

The most common mistake in Make.com™ screening scenarios is skipping Step 8. Error handling feels optional when the scenario works in testing – it becomes essential on the first night a parsing vendor returns a 503. Build the error handler before you go live, not after your first incident. The 45 minutes it takes to build saves four hours of manual incident recovery the first time something breaks at scale.

Key Takeaways

• Capture a run ID immediately after the webhook trigger for auditable error tracing.
• Validate binary resume data size before sending to parser – files above 5MB cause frequent timeouts.
• Log parse confidence on every call; route sub-80% confidence resumes to manual review.
• Score candidates with a native Make.com™ expression – no external function call required.
• Three routing branches (shortlist/hold/screen-out) handle the full range of screening outcomes.
• Execute ATS updates and candidate communications in parallel – total execution under 8 seconds.
• Error handler writes every failure to a log with run ID – never let errors drop silently.

Frequently Asked Questions

How many Make.com operations does this 8-step screening scenario consume?

A standard execution of this scenario consumes 12-18 Make.com™ operations depending on routing branch. At 500 applications per month, that puts you in the 6,000-9,000 operations range – well within Make’s Core plan limit of 10,000 operations per month. High-volume deployments above 2,000 applications per month should model operation counts before committing to a plan tier.

Can this Make.com screening workflow work without an ATS API?

Yes, with reduced functionality. If your ATS lacks an API, configure the scenario to write scores to a shared Google Sheet and send recruiter notifications via Slack or email. The screening logic remains intact; the ATS remains updated manually. This hybrid approach works for teams that cannot wait for an ATS migration to start automating screening.

What happens if the AI parsing vendor has an outage?

The error handler in Step 8 captures the timeout or 5xx error and writes the failed application ID to the error log. A nightly digest alerts the recruiting team. When the vendor recovers, retry the failed applications manually or build a Make.com™ retry scenario that re-processes the error log on demand.