Recruiting · First-pass screening
WorkflowRecruitingScreening applicants against written criteria, with a person deciding
A coordinator with 240 applications for one role has three options for the first pass. This guide compares them, and shows a workflow that summarises each applicant against written criteria while a person makes every decision.
Valnora & Elric team6 min read
Compared in this guide
- AManual screening
- BKeyword filters
- CCriteria-based summaries
A recruiting coordinator opens Monday with 240 new applications for a customer success role (an illustrative figure). The hiring manager wants a shortlist by Thursday. The coordinator has three ways to do the first pass, and each one fails differently.
This guide compares them and then walks through the third: a workflow in Agent Serve that summarises each applicant against criteria the hiring manager wrote down, quotes the evidence, and leaves every decision with a person.
Three ways to do the first pass
Three ways to do the first pass on applications
| Approach | How it works | Where it helps | Where it goes wrong |
|---|---|---|---|
| Manual screening | A coordinator reads every resume and makes notes in the tracker. | Full context and judgement on every applicant. | Slow at volume. Criteria drift between the first and the two-hundredth resume, and notes rarely say why. |
| Keyword filters | The tracker or a script rejects or sorts on words such as a tool name or a degree. | Fast and cheap. Easy to explain the rule. | Misses people who describe the same skill in other words, and rewards resumes stuffed with keywords. |
| Criteria-based summaries | A workflow compares each resume with written criteria and quotes the evidence for each one. | Consistent against the same written criteria. Every claim points to a quote a person can check. | Needs well-written criteria and a person who actually reads the summary. The model can misread a resume. |
Manual screening is the honest baseline. Its problem is not judgement, it is consistency: by resume two hundred, the bar has moved and the notes say "maybe" without saying why. Keyword filters fix speed by giving up meaning. A person who "ran renewals for a book of SaaS accounts" may never type the phrase in your filter.
Criteria-based summaries sit between the two. They do not decide. They make each resume easier to read against the same written bar, and they show their working.
Start with criteria a person would sign
The quality of the summary depends on the criteria, so write them first and get the hiring manager to agree them. For the customer success role, that might be:
- Must-haves: two or more years owning B2B SaaS accounts; owned renewals or expansion; working Spanish.
- Nice-to-haves: experience with a ticketing tool; onboarding larger customers.
- Do not consider: name, age or graduation years, gender, nationality, photos, address, marital or family status, disability, religion, and gaps in employment.
Store the criteria as a short document in the Knowledge Base, one per role, so the workflow reads the current version and anyone can see what it was told.
How the workflow runs
From a new application to a summary a coordinator reads
Workflow · Summarise one applicant
- 01New applicationA webhook from Greenhouse or Ashby calls the workflow’s Webhook trigger with the application ID.
- 02Resume and answersThe Greenhouse or Ashby block fetches the application; a document parsing block turns the resume into text.
- 03Mask personal dataA Guardrails block masks name, contact details, address, date of birth and photo links before any model reads the text.
- 04Written criteriaThe role’s must-haves, nice-to-haves and a do-not-consider list, kept in the Knowledge Base.
- 05Criteria summaryFor each criterion: met, not met or not found, with a quote from the resume. No score and no ranking.
- 06Screening summariesOne row per application, linked back to the record in the tracker.
People · Decide
- 07Coordinator readsReads the summary and the resume, checks any quote that matters, and moves the applicant on or not in the tracker.
- 08Hiring managerAgrees the criteria up front and reviews a sample of decisions each week.
The workflow is built in the workflow builder and runs once per application:
- Trigger. Greenhouse and Ashby can send a webhook when an application is created. Point it at the workflow's Webhook trigger.
- Fetch. The Greenhouse or Ashby block reads the application and its resume. A document parsing block turns the file into text.
- Mask. A Guardrails block with PII detection masks the name, email, phone, address, date of birth and links before the next step. The model never sees who the applicant is.
- Compare. An Agent block reads the criteria and the masked resume. Its instructions are strict: for each criterion return met, not met or not found, and quote the line that supports it. If there is no quote, the answer is not found. Never infer a protected trait, never score, never rank.
- Record. The result is written to a Screening summaries table in Tables, with a link to the application in the tracker.
The workflow has no step that changes an application's stage or contacts an applicant. That is a design choice, not a setting someone can forget.
What the coordinator reads
What the solution produces
Screening summary for one applicant (illustrative)
Record- Application
- APP-4471 · Customer Success Manager · Ashby
- Must-have 1: B2B SaaS accounts
- Met. "Owned a book of 38 mid-market SaaS accounts, renewals and expansion" (2022 to now).
- Must-have 2: Renewal ownership
- Met. "Ran quarterly business reviews and renewal forecasts for my book."
- Must-have 3: working Spanish
- Not found. No language is mentioned. Ask at phone screen if relevant.
- Nice-to-have: Ticketing tools
- Met. "Daily user of Zendesk for escalations."
- Not considered
- Name, age, gender, nationality, photo, address, graduation years and employment gaps, per the role’s do-not-consider list.
- Decision
- None made. The coordinator decides in the tracker.
The coordinator opens the table filtered to the role, reads each summary next to the resume, and checks quotes on anything borderline. "Not found" prompts a question at phone screen rather than a rejection, because people leave things off resumes. The decision to move someone forward or decline them is made in Greenhouse or Ashby, by the coordinator, as before.
The hiring manager reviews a sample each week: a few applicants moved forward and a few declined, read against the full resume. If the summaries keep missing a skill, the fix is usually in the criteria wording, and it is made in one document.
Keeping personal data out of logs
Masking before the model is one layer. The run record is another. Run logs normally keep each block's inputs and outputs, which for this workflow would include resume text. Turn on PII redaction in Settings → Data retention for logs, workflow input and block outputs, and set a retention period that matches your recruiting privacy notice.
Controls and governance
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
GDPR ready
Retention from one day to five years, deletion and access controls support GDPR obligations. Ready means the controls are in place, not a certification.
More on how Agent Serve handles access, data and audit on the security page.
Limit the table to the recruiting team with row-level access, and deploy the workflow as a versioned release, so a change to its instructions is reviewed before it touches live applications.
Before you switch it on
Some places regulate automated tools in hiring. New York City's Local Law 144, for example, sets requirements for automated employment decision tools. A setup where a person reads evidence and decides is different from one that scores and filters, but ask your legal or people team which rules apply where you hire, and tell applicants how their data is processed. For a wider view of how to check written policies against practice, see policy and procedure QA.
Questions teams ask
Does the workflow reject anyone?
No. It writes a summary and nothing else. It does not change an application’s stage, send a message to the applicant or produce a score. The coordinator moves applicants in Greenhouse or Ashby as they do today.
Why no score or ranking?
A single number invites people to sort by it and stop reading. A list of criteria with quotes keeps the reader looking at evidence, and makes a misread visible because the quote either says what the summary claims or it does not.
Can the summary be wrong?
Yes. A model can miss a skill described in unusual words or misread a date. That is why each criterion carries a quote, and why "not found" means "ask", not "no". Sample a few decisions each week against the full resume.
What you need
- Greenhouse or Ashby connected, with a webhook for new applications pointed at the workflow
- Written criteria per role: three to five must-haves, a few nice-to-haves and a do-not-consider list, agreed with the hiring manager
- PII redaction turned on in Settings → Data retention for logs, workflow input and block outputs
- A Screening summaries table with row access limited to the recruiting team
- A named coordinator who reads every summary and makes every decision in the tracker
- Advice from your legal or people team on local rules for automated tools in hiring