Automating candidate screening from application to shortlist in six steps eliminates 85% of manual screening time and delivers consistent, auditable decisions within 10 minutes of each application. The complete workflow runs in Make.com without developer support: webhook validation, resume parsing, score calculation, four-branch routing, ATS update with candidate notification, and weekly QA review.

Step 1: How Do You Receive and Validate Incoming Applications?

Configure your ATS to send a webhook POST to your Make.com scenario URL on every new application event. The Make.com webhook module captures the payload and immediately validates three required fields: application ID, resume attachment URL, and job ID. If any field is missing, the scenario routes to an error branch that creates a Teamwork task for manual triage and exits. Validation before processing prevents partial-data executions from polluting your scoring data. Log every incoming webhook with a timestamp and application ID as the first step – before any processing – so you have a receipt even if the scenario fails downstream.

Step 2: How Do You Extract the Resume and Call the Parsing API?

Use an HTTP GET module to download the resume file from the attachment URL in the webhook payload. Pass the binary file to your parsing service via an HTTP POST with multipart/form-data encoding. The parser returns a structured JSON object containing skills, experience, education, and contact fields. Validate the parse response: check that the confidence score field is present and above 70%. A confidence score below 70% means the parser could not reliably extract the resume content – route these to a manual review queue rather than scoring. See Resume Parsing Optimization for HR Automation for vendor-specific HTTP module configuration details for Affinda and Sovren API calls.

Step 3: How Do You Calculate the Candidate Score in Make.com?

Add a Set Variable module immediately after the parse validation. The variable expression calculates the weighted rubric score: map each parser field to its rubric dimension, apply the dimension weight, and sum to a total score out of 100. For required skills, use a CONTAINS function to check each required skill against the parsed skills array, then multiply the match count by the dimension weight. This expression runs in under 200ms per candidate and requires no external function call. Store the score, the individual dimension scores, and the parse confidence in separate named variables for downstream use.

Step 4: How Do You Route Candidates Based on Score?

Add a Router module with four branches. Branch 1 (score 65 or above AND parse confidence 80% or above): advance to shortlist. Branch 2 (score 50-64 AND parse confidence 80% or above): hold for secondary review. Branch 3 (score below 50 AND parse confidence 80% or above): screen out. Branch 4 (parse confidence below 80%): manual review regardless of score. The four-branch structure covers every outcome. Secondary review exists for borderline candidates where human judgment adds value; it is not a catch-all for uncertain scoring – that is what the manual review branch handles.

Step 5: How Do You Update the ATS and Notify Candidates?

In each routing branch, execute two parallel actions: (1) HTTP PATCH to your ATS to write the screening score, decision, and timestamp to custom fields; and (2) a Gmail or SendGrid module to send the appropriate candidate communication. Shortlisted candidates receive a scheduling link and next-steps message. Screen-out candidates receive a professional decline. Secondary review candidates receive an acknowledgment with a 72-hour response commitment. Running these two actions in parallel using Make’s parallel route feature within each branch keeps total execution time under 15 seconds.

Step 6: How Do You Maintain Quality Assurance on the Automated System?

Build a weekly QA process into the system. Every Friday, a Make.com scheduled scenario queries the ATS for all screening decisions from the previous 7 days and exports them to a Google Sheet with score breakdown, parse confidence, and routing decision. An HR team member reviews 10% of shortlist decisions and 10% of screen-out decisions for quality. Any reviewed decision the reviewer would have made differently goes into a calibration log. When the calibration log accumulates 10 discrepancies, trigger a rubric review. This QA process takes 30 minutes per week and catches model drift before it affects hire quality.

Expert Take

Step 6 is the one most teams build and then stop running. The automated QA process feels unnecessary when the system is working well – and that is exactly when it is most valuable, because drift is invisible until it is not. Schedule the Friday QA export as a recurring Make.com scenario with a non-negotiable Slack notification. Make the QA review a weekly calendar commitment for one HR team member. Thirty minutes per week is the cost of catching a rubric calibration problem before it generates a discrimination complaint.

Key Takeaways

• Validate three required fields immediately on webhook receipt; log every incoming application before processing.
• Route resumes with parse confidence below 70% to manual review – never score on unreliable parser output.
• Calculate weighted rubric score in a single Set Variable expression – no external function call required.
• Four routing branches: shortlist (65+ / high confidence), hold (50-64 / high confidence), screen-out (<50 / high confidence), manual review (low confidence).
• Run ATS write and candidate communication in parallel – total execution under 15 seconds.
• Weekly QA review of 10% of each routing decision; calibration log triggers rubric review at 10 discrepancies.

Frequently Asked Questions

What is the difference between the “hold” and “manual review” routing branches?

Hold (50-64 score) is for candidates with reliable parse data who scored in the borderline range. They receive human evaluation of their borderline score. Manual review is for candidates where parse confidence was too low to produce a reliable score – they receive full human screening because the automated data is not trustworthy enough to use. The distinction matters: hold candidates are evaluated on their score; manual review candidates are evaluated as if no automation ran.

How do you prevent the weekly QA review from becoming a rubber stamp?

Structure the review as a blind evaluation: the reviewer looks at the resume and makes their own advance/hold/screen-out decision before seeing the system’s decision. Then compare. This blind comparison structure produces genuine calibration data rather than post-hoc agreement with automated decisions – and it surfaces rubric drift before it compounds into a pattern.

Can this six-step workflow handle multiple open positions simultaneously?

Yes. The Make.com scenario reads the job ID from the webhook payload and maps it to the appropriate rubric configuration stored in a Google Sheet lookup table. Each job ID maps to a set of required skills and scoring weights – the same scenario handles all positions, with position-specific rubric logic applied dynamically at Step 3.