Resume screening with human approval

Hiring decisions affect people's livelihoods and carry legal risk. Models can be confidently wrong, misread non-standard resumes or reflect bias in their training. So the model does the tedious part: it parses the resume, scores it against explicit requirements and quotes its evidence. A recruiter makes the actual decision. In n8n, the Wait node set to On Form Submitted makes this cheap, because the recruiter clicks one link, picks approve, reject or hold, and the same execution resumes. I also never auto-reject low scorers; they sit in a hold queue for a periodic sweep. I track how often recruiters agree with the shortlist, which tells me whether the prompt or threshold needs tuning.

An n8n Form Trigger starts one execution per application and receives the resume as binary data. Extract From File turns it into text, and an IF node sends empty extractions, such as scanned images, to manual review. Postgres upserts the applicant on email plus job ID and loads the job's requirements. A Code node redacts sensitive fields. An Information Extractor calls a model through Vercel AI Gateway and returns a score, a must-haves flag and evidence quotes. An IF node shortlists the candidate or stores them as hold. Shortlisted candidates go to a recruiter with a resume form link, and a Wait node pauses until the recruiter decides. A Switch routes the decision and writes it to Postgres. Only approved candidates get a calendar event and an invite.

I would use four tables. Jobs holds job_id, title, owner recruiter, and must-have and nice-to-have requirements as JSONB. Applicants holds id, email, job_id, name, consent flag and timestamp, status (new, manual_review, hold, shortlisted, approved, rejected, escalated) and a unique constraint on (email, job_id). Screenings holds applicant_id, score, must_haves_met, evidence JSON, model name, prompt version and execution ID. Decisions is an append-only table with applicant_id, decision, reason, recruiter identity, interview slot, decided_at and execution ID. Keeping decisions separate and append-only gives an audit trail that is never overwritten. I would keep the resume text or file reference in a restricted column or store, with a retention date.

For long waits, n8n does not keep the execution in memory. It saves the execution state, including the data so far, to its database and marks it as waiting. When the recruiter submits the form at the resume URL, n8n loads that state and continues from the Wait node with the form data. Because the state is in the database, it survives restarts and deployments, provided the database and the binary data storage are persistent and shared. The risks are upgrades that change node behaviour, and workflow edits made while executions are waiting. I would version changes carefully and test resuming old waiting executions in staging before deploying to production.

The resume URL is unique to the execution and hard to guess, but anyone who has it can submit a decision, so treat it as a bearer secret. Send it only by direct Slack message or by email to the job owner, never to a broad channel. Capture who decided: include a recruiter identity field, or better, look up the identity from your own data. Check that identity against the job owner or an allowlist in an IF or Code node before acting, and route mismatches to review. Once the form is submitted, the execution moves on and the link stops working, which prevents replays. Every decision is written to Postgres with identity and reason, so misuse can be traced.

First, the prompt treats the resume as data. It is wrapped in clear delimiters, and the system instruction says text inside it is content to assess, never instructions to follow. Second, the Information Extractor returns a fixed schema, so the model cannot take actions. It can only fill in fields. Third, a Code node checks that each evidence quote actually appears in the extracted text, so an inflated score without real evidence stands out. It can also flag phrases like 'ignore previous instructions'. Most importantly, a recruiter sees the score and evidence and must approve before anything is sent. The worst case from an injection is a wasted recruiter review, not an invite.

First, I make the model's job narrow. The Information Extractor returns a fixed schema: whether each must-have is met, a score and a direct quote from the resume as evidence for each claim. Requiring a quote makes invented judgements easy to catch, and a Code node can check that the quote actually appears in the resume text. Second, I redact signals unrelated to the job, such as photos, age and gender terms, before the text reaches the model. Third, I compare model shortlists with recruiter decisions over time and review disagreements by group where that is lawful. Finally, the human approval step is a safeguard, not a formality, so recruiters always see the evidence.

I would run n8n in queue mode with Redis and several workers, so form submissions are spread across workers instead of blocking the main instance. Waiting executions do not hold memory for long, because n8n stores them in the database until the form is submitted. For model calls, Vercel AI Gateway gives me one endpoint with fallback models if a provider rate-limits. I would also enable retry-on-fail on the extractor node. On the recruiter side, a thousand individual pings is unusable, so I would send a ranked Slack digest of the top candidates while still resuming each execution individually through its own form link.

The Postgres upsert is keyed on email plus job ID, and a unique constraint on those columns backs it, so a resubmission updates the existing row instead of creating a new one. That covers data duplication but not workflow duplication, because each submission still starts its own execution. So after the upsert I would check the applicant's status. If a decision is already recorded, or a recruiter request is already pending, the second execution stops or just attaches the newer resume for the recruiter to see. The invite step also checks an invite_sent flag before sending. Together, the constraint and the status checks make the workflow idempotent at the level that matters, which is one decision and at most one invite per candidate per job.

Extract From File reads the text layer of a document. A scanned image has no text layer, so the output is empty or nearly empty. If you scored that, the model would either give a very low score or make up content, and a strong candidate would quietly drop into hold for the wrong reason. An IF node that checks for empty or very short text and flags the application for manual review keeps the failure visible and puts a human in charge. Later you could add an OCR step, but the manual branch should stay as the fallback. I would also count these cases so the team can see how often the form receives unreadable files.

The rule is that no invite and no rejection is ever sent on the model's judgement alone. A low score can come from bad extraction, unusual formatting, a career change the model misreads, or requirements that are worded badly. A rejection is hard to reverse and affects the candidate directly, so the system only parks them as hold. A periodic recruiter sweep reviews held candidates, often sorted by score, and can promote or reject them with a recorded reason. This keeps the model as a way to prioritise, not a decision maker. It also gives you labelled data, because the candidates recruiters promote from hold show you where the scoring is wrong.

Limit Wait Time on the Wait node sets a deadline, for example a set number of business days that suits hiring speed. If the deadline passes before any form is submitted, the timeout branch runs. That branch writes an 'escalated' status to Postgres, notifies the job owner's manager or a shared recruiting channel with the candidate summary, and starts a new approval request with its own resume link. It must not approve or reject anything. I would also send one reminder before the deadline using a separate scheduled check, so an escalation is not the recruiter's first nudge. Every escalation is logged so you can see which roles or recruiters create bottlenecks.

The Information Extractor is given a JSON schema, but I still validate the output in a Code node. The score must be a number in range and the must-haves flag must be a boolean. There must be one evidence entry per requirement in the job record. Each quoted evidence line must appear in the resume text after normalising whitespace. If a must-have is marked met but has no verifiable quote, I set the flag to false or send the case to manual review. Malformed output gets a limited retry, and if it is still invalid, the application goes to hold with a reason, never to rejection. This turns model hallucination into a detectable data quality problem.

India's Digital Personal Data Protection Act, 2023 expects consent for a specific purpose, collecting only the data you need, keeping it secure, and honouring requests to correct or erase it. The consent checkbox records consent for screening. I would store its wording version and a timestamp. Redaction removes data the screening does not need before it leaves your system. Resumes go to a model provider through the gateway, so the privacy notice should say that, and you should check the data-use terms of the providers you route to. Set a retention period for applicant data and resume text, enforce it with a scheduled deletion workflow, and restrict Postgres access to the recruiting team. Legal counsel should confirm the details.

n8n logs executions, and those logs can include node input and output: the resume binary, the extracted text, and names and emails. Anyone who can open the workflow's executions can see that personal data, and it stays there beyond your intended retention. To reduce this, configure execution data pruning with a sensible maximum age. Consider not saving data for successful executions, while keeping error data for debugging. Use a binary data mode that stores files outside the main database, with matching retention. Limit who has access to the project. Make sure Postgres, not the execution log, is the system of record, so pruning does not lose anything you need for audits.

A retry after a timeout can resend an email that actually went through. So the invite path checks the applicant row first and skips if invite_sent is already true. After the Gmail node succeeds, it sets invite_sent and stores the message ID in the same execution. For the calendar, create the event first and store its event ID, then put the event link in the email. A retry that finds an existing event ID reuses it instead of creating a second event. Keep Max Tries small, with a wait between tries. If retries are exhausted, the error workflow alerts ops, who can see from Postgres exactly which steps completed.

State assumptions clearly. If most of the 6,000 arrive in a 10-hour window, that is 600 an hour, about 10 a minute, with bursts several times higher after a job post goes out. Each execution does a file extraction, a few Postgres queries and one model call. The model call dominates time and cost, so total tokens are roughly applications times (resume tokens plus requirements plus output). Get real token counts from the gateway's spend tracking rather than guessing prices. The Wait node is cheap while waiting because state sits in the database. But a shortlist of even 10 percent means 600 recruiter reviews, so human throughput, not n8n, is usually the real bottleneck.

Wait nodes keep the logic in one readable workflow. The resume URL ties the decision directly to the candidate's execution, and the timeout handling is built in. The costs are thousands of waiting executions in n8n's database, recruiters working from scattered links in Slack or email, and trouble when you edit the workflow while old executions are still paused. A queue table in Postgres with a small review UI lets recruiters sort, filter and batch-decide. A decision then starts a sub-workflow instead of resuming an execution. That scales better for high-volume roles but means more code to maintain. I would start with Wait nodes and move to a queue once review volume makes a list view necessary.

The chat model credential points at https://ai-gateway.vercel.sh/v1 with one AI Gateway API key, so n8n never stores provider keys. Switching from 'anthropic/claude-sonnet-4.5' to 'openai/gpt-5' means changing a model name, not adding credentials. Spend tracking in one place helps with cost estimates per hire. Fallbacks let a request go to an alternative model when the primary one fails or is unavailable, which keeps screening running during a provider outage. The catch is that different models score differently, so each screening row should record the model that actually produced the score. I would only allow fallback models that have been tested on the same evaluation set.

Do not pick a number by feel. Build a labelled set of past applications for a role, with consent and redaction, where recruiters have already decided who was worth interviewing. Run the extractor on that set and plot recall and precision of the shortlist at different thresholds. Recall matters most, because a missed good candidate is costly, while extra recruiter reviews cost less. Also, because hold is reviewed anyway, the threshold mainly sets which candidates get looked at first. Keep the must-haves flag as a separate gate. Recalibrate whenever the model, prompt or job template changes, and track how often recruiters promote held candidates as a sign of drift.

Write the decision to Postgres first, then send the invite, then record that the invite was sent. If the database write fails, nothing goes out, and the error workflow raises it, so you never have an invite without an audit record. If the invite fails after the write, the state is 'approved, invite pending', which is visible and can be retried safely. The reverse order is worse: an invite sent with no recorded human approval breaks the audit trail and the core rule. n8n has no transactions across nodes, so you design with explicit status fields and idempotent steps that can be retried rather than expecting atomicity.

First, limit concurrency. In queue mode, set worker concurrency so the number of model calls running at once stays below the rate limit, and let Redis hold the backlog. Applications are not lost, they just wait in the queue. Second, enable retry-on-fail on the extractor node with a wait between tries so short spikes clear on their own. Third, configure gateway fallbacks to a tested alternative model for sustained provider problems. If an application still fails, it should go to hold or manual review with a reason and alert ops through the error workflow. It should never be dropped silently. Screening a few minutes late is fine for hiring.

In queue mode, the main instance or a webhook processor receives the form submission, but a worker may run the execution. If binary data is kept in memory or on one machine's local disk, another worker may not be able to read it, and a resumed Wait execution may run on a different worker too. So binary data has to live in storage that all instances share, such as an S3-compatible external store supported by your n8n edition. That storage needs the same encryption, access control and retention as the rest of the applicant data. Check the current n8n docs for which binary data modes your version and edition support in queue mode.

Store more than the score. Each screening row records the model name actually used, a prompt version ID, a snapshot or version of the job requirements, the score, the must-haves flag, the evidence quotes and the n8n execution ID. The decision row adds the recruiter, the reason and the timestamp. Keep prompts in version control or a prompts table rather than editing them inline without history. Reproducing the exact output may not be possible because models change or get retired, but you can always show what the system knew, what the model said with quoted evidence, and what a named human decided and why. That is what an auditor needs.

The task is fixed: read one resume against known requirements and return a defined JSON structure. The Information Extractor is built for that. It takes text and a schema and returns structured fields, with one model call and predictable output. An AI Agent adds tool calling, multi-step reasoning and memory. That adds latency, cost and unpredictability, and it lets the model choose actions, which this workflow should never allow. All actions here, such as storing, notifying, waiting and inviting, are fixed nodes controlled by IF and Switch logic and the recruiter. If you later need the model to look things up, give it read-only tools, but keep sending actions outside the model.

Build a separate workflow on a Schedule Trigger, for example every weekday morning. It queries Postgres for applicants in hold status, grouped by job and sorted by score, so the recruiter reviews the most promising first. Loop Over Items processes them in batches, and the workflow sends each job owner a digest with scores, evidence and a review link. Decisions from the sweep use the same approval path, with a Wait form or a link that starts the decision sub-workflow, so they are recorded with identity and reason exactly like the main flow. Candidates held beyond a set age get escalated. Nothing in the sweep changes a status without a human decision.

The form should use a fixed dropdown or radio choice of approve, reject and hold, so free text cannot arrive. Still, the Switch should have a fallback output for anything else. The fallback writes the raw value to Postgres, marks the candidate for review, and alerts ops, and it never treats an unknown value as approval. Rules should match exact values. I would also require the reason field, and require an interview slot for approvals, by checking it in an IF node, because an approval with no slot cannot produce a valid calendar event. A failed check sends the recruiter a fresh request instead of continuing.

The Error Trigger gives you the failed workflow's name, the execution ID or URL, the failing node and the error message. Post those, plus the applicant's internal ID and current status from Postgres, so ops can find the record and see what already completed. Leave out the resume text, candidate names, emails and model output, because ops channels are often wide and those messages are kept for a long time. If someone needs details, they open the execution or the database with proper access. Group repeated alerts during an outage so the channel is not flooded, and track failure counts by node to spot systemic problems.

Track how often recruiters agree with the model: approval rates for shortlisted candidates, and promotion rates from hold. A rising promotion rate means the model is missing good people. Watch the score distribution by job and by model, especially after a gateway fallback or a model change. Sample cases where the model and the recruiter disagreed and review the evidence. Fairness is harder because sensitive attributes are redacted and not collected. Proxies like college names or locations can still influence scores, so review evidence patterns for those, and get a fairness assessment done properly with legal input. Re-run the labelled evaluation set whenever prompts or models change.

Store the owner recruiter, and optionally a backup, on the jobs table. When requirements are loaded in step 3, the workflow also gets the owner's Slack ID or email, and the notification goes only to them. The identity check at the Wait form compares against that owner. For two approvers, you can chain two Wait nodes, each with its own resume link and time limit, and send the invite only if both approve. Or you can run the approvals in parallel and combine them with a Merge node. Record each decision separately in the audit table. Any reject or hold from either approver stops the invite.

Postgres gives you a unique constraint on email plus job ID, so upserts are reliable when submissions arrive at the same moment. It also offers transactions, proper column types, indexes for the hold sweep, and row-level access control for sensitive data. Google Sheets is quick to set up, but it has no real uniqueness guarantee, gets slow and hits API limits at thousands of rows, and is easy to share too widely, which is a privacy risk for resumes. An audit trail also needs append-only, queryable history. A spreadsheet can still be useful as a read-only export or a view for recruiters, fed from Postgres.

Run it in a staging n8n instance with its own Postgres, a test Slack channel and a test calendar. Use a set of synthetic resumes covering strong matches, weak matches, scanned images, DOCX files, duplicate submissions and prompt-injection text. Pin data on nodes to replay specific cases without calling the model each time. Check every branch: manual review, hold, approve, reject, hold from the form, timeout escalation, and the Switch fallback. Force failures, such as a bad credential or a database outage, to confirm retries and the error workflow work. Confirm that no path sends an invite or rejection without a recorded human decision.

Build a small erasure workflow, triggered by a form or by an admin, that verifies the request and then deletes or anonymises the applicant's rows, screening outputs and resume text or file in Postgres and binary storage. If any execution for them is still waiting, cancel it so a late approval cannot send an invite. Also purge related n8n execution data if pruning has not already removed it. Messages already sent to recruiters in Slack or Gmail need deleting under their own retention rules. If you must keep any record of the decision for legal reasons, keep the minimum, with no resume content, and document why.

1. ACandidate name
2. BEmail plus job IDCorrect answer
3. CExecution ID
4. DResume file name

Why: The applicant is keyed on email plus job ID, ideally enforced with a unique constraint.

1. AStores them as hold for a periodic recruiter sweepCorrect answer
2. BSends a rejection email
3. CDeletes the application
4. DRe-scores with a different model until they pass

Why: Below-bar candidates are stored as hold and are never auto-rejected.

1. AAt Specified Time
2. BOn Webhook Call with no form
3. COn Form SubmittedCorrect answer
4. DAfter Time Interval

Why: Step 7 uses a Wait node set to resume On Form Submitted.

1. AMoving to queue mode
2. BSending invites straight from the score IF node without the Wait stepCorrect answer
3. CSwitching the model from one provider to another through the gateway
4. DAdding a reminder before the Wait deadline

Why: Invites, and rejections, must never be sent on the model's judgement alone. The human Wait step is required.

1. A$execution.id
2. B$execution.resumeUrl
3. C$execution.resumeFormUrlCorrect answer
4. D$workflow.webhookUrl

Why: For a Wait node resuming On Form Submitted, n8n exposes the form address as $execution.resumeFormUrl. $execution.resumeUrl is for the webhook resume mode.

1. Ahttps://gateway.n8n.io/v1
2. Bhttps://api.openai.com/v1
3. Chttps://ai-gateway.vercel.sh/v1Correct answer
4. Dhttps://vercel.com/api/ai

Why: Vercel AI Gateway exposes an OpenAI-compatible API at https://ai-gateway.vercel.sh/v1. With an AI Gateway API key, one credential reaches models such as anthropic/claude-sonnet-4.5.

1. An8n Form TriggerCorrect answer
2. BChat Trigger
3. CError Trigger
4. DSchedule Trigger

Why: The workflow begins with an n8n Form Trigger that collects the fields and the resume file, with one execution per submission.

1. ARetry extraction forever
2. BFlag the application for manual reviewCorrect answer
3. CScore it anyway with a default value
4. DReject the candidate automatically

Why: The IF branch sends empty extractions to manual review because there is nothing reliable to score.

1. AIn the Gmail invite
2. BAfter the recruiter approves
3. CIn the error workflow
4. DIn a Code node before the model callCorrect answer

Why: Redaction happens in a Code node before the Information Extractor so the model never sees those fields.

1. AA calendar invite
2. BA free-text essay about the candidate
3. CJSON with a score, a must-haves-met flag and an evidence quote per requirementCorrect answer
4. DA final hire or reject decision

Why: Step 4 defines structured JSON output: score, must-haves flag and quoted evidence.

1. AIt replaces Postgres
2. BOne gateway key reaches many providers, with no provider keys stored in n8nCorrect answer
3. CIt removes the need for human approval
4. DIt stores resumes permanently

Why: The gateway gives one credential, model fallbacks and spend tracking without provider keys in n8n.

1. ALimit Wait TimeCorrect answer
2. BAlways Output Data
3. CExecute Once
4. DRetry On Fail

Why: Limit Wait Time sets a deadline, after which the timeout branch escalates.

1. AApprove the candidate automatically
2. BReject the candidate automatically
3. CEscalate without making a decisionCorrect answer
4. DDelete the execution silently

Why: The timeout branch escalates. Neither approval nor rejection may come from the system on its own.

1. AMerge
2. BLoop Over Items
3. CSwitchCorrect answer
4. DExtract From File

Why: A Switch node branches on approve, reject or hold.

1. AOnly the model score
2. BThe decision, the recruiter's identity and the reasonCorrect answer
3. CThe full Slack conversation
4. DThe gateway API key

Why: Step 8 records each decision with the recruiter's identity and reason.

1. AIt disables the error workflow
2. BA retry after a timeout may send a duplicate invite unless the send is idempotentCorrect answer
3. CIt deletes the calendar event
4. DIt changes the recruiter's decision

Why: If the first attempt actually succeeded, a retry can resend it, so check an invite_sent flag first.

1. AThe AI Gateway
2. BThe Wait node
3. CRedis with worker processesCorrect answer
4. DGoogle Sheets as a queue

Why: Queue mode uses Redis to distribute executions to workers.

1. ARaise the model temperature
2. BRemove the evidence field
3. CTrust the score if it is high
4. DTreat the resume as delimited data, validate the structured output and keep human approvalCorrect answer

Why: Treating input as data, checking the schema and evidence, and requiring human approval limit what an injection can achieve.

1. AError Trigger in an error workflowCorrect answer
2. BMerge node
3. CLoop Over Items
4. DExecute Workflow

Why: A workflow can be assigned an error workflow that starts with an Error Trigger node. That workflow runs on failure and can, for example, alert ops in Slack.

1. AExtract From FileCorrect answer
2. BEdit Fields (Set)
3. CSummarization Chain
4. DHTTP Request

Why: Extract From File converts the binary document into text that later nodes can process.

1. AThe Form Trigger strips attachments
2. BIt has no text layer to extractCorrect answer
3. CPostgres rejects image files
4. DThe gateway blocks images

Why: Text extraction reads embedded text, and a scanned image contains only pixels unless OCR is applied.

1. AInserts cannot store JSON
2. BUpserts make the model call cheaper
3. CA resubmission updates the existing row instead of duplicating itCorrect answer
4. DUpserts skip the consent check

Why: An upsert on a unique key makes repeated submissions idempotent at the data layer.

1. AA vector store
2. BA chat model sub-nodeCorrect answer
3. CA Webhook node
4. DA memory sub-node

Why: LangChain-based AI nodes in n8n need a connected chat model, here an OpenAI-compatible one pointed at the gateway.

1. Aanthropic/claude-sonnet-4.5Correct answer
2. Bhttps://anthropic/claude
3. CANTHROPIC_SONNET
4. Dclaude@anthropic

Why: Gateway models use the provider/model format, for example "anthropic/claude-sonnet-4.5" or "openai/gpt-5".

1. ADecision (approve, reject or hold), a reason and an interview slotCorrect answer
2. BOnly a thumbs-up button
3. CThe candidate's new score
4. DThe model name to use

Why: Step 7 lists approve, reject or hold, a reason field and an interview slot.

1. AThey are moved to hold
2. BThey are sent to the error workflow
3. CThey are re-scored by the model
4. DThey get a Google Calendar event and a Gmail invite, with retry-on-failCorrect answer

Why: Step 9 creates a calendar event and sends a Gmail invite, both with retry-on-fail.

1. AIn Redis
2. BIn the Postgres schema
3. CAs a per-node settingCorrect answer
4. DOnly in the gateway dashboard

Why: Retry-on-fail, with max tries and wait between tries, is set on individual nodes.

1. A10 per minuteCorrect answer
2. B60 per minute
3. C1 per minute
4. D100 per minute

Why: 6,000 divided by 600 minutes is 10 applications per minute, before accounting for bursts.

1. AAsk the model whether it hallucinated
2. BCount the words in the score
3. CCheck that the quote appears in the extracted resume textCorrect answer
4. DCompare it with the job title only

Why: A real evidence line should be a substring of the resume text, after normalising whitespace.

1. AIn the Form Trigger
2. BInside execution logs
3. CEncrypted, and referenced by nodesCorrect answer
4. DIn plain text inside each node

Why: n8n stores credentials encrypted, and nodes reference them rather than embedding them.

1. AIgnore it and send an invite
2. BAs must-haves met
3. CAs grounds for automatic rejection
4. DAs not shortlisted, sent to hold or review, never rejectedCorrect answer

Why: Missing or invalid fields should fail safe to hold or review, never to an automatic decision.

1. AMerge
2. BExecute WorkflowCorrect answer
3. CSwitch
4. DWait

Why: Execute Workflow calls another workflow as a sub-workflow.

1. AChat Trigger
2. BLoop Over ItemsCorrect answer
3. CExtract From File
4. DError Trigger

Why: Loop Over Items processes items in batches.