Resume parsing and screening
Tavnit reads resumes in any layout and returns consistent candidate records: contact details, skills, job titles with dates, education and certifications. Because every candidate is described in the same fields, screening becomes filtering a table rather than opening two hundred PDFs.
Why this is painful
Resumes are the least standardised document most teams handle. Two columns or one, tables or prose, a design-led layout with the dates in a sidebar. A human reads any of them; software usually reads about half.
The real cost is inconsistency. When a hundred resumes are each summarised slightly differently, comparing candidates on the same criteria stops being possible, and screening quietly becomes whoever the first reviewer happened to like.
What to extract
| Field | Why it needs care |
|---|---|
| Name and contact details | Frequently in a header, a sidebar or an image — one of the more common extraction failures. |
| Job titles with employers and dates | A repeating table, not a single value. Table fields keep each role as its own row. |
| Total years of experience | Rarely stated. A formula Cleaner can compute it from the role dates rather than trusting a claim. |
| Skills | Best extracted verbatim, then normalised — a category Cleaner can map 'JS', 'JavaScript' and 'ES6' to one value. |
| Education and certifications | Institution, qualification, year. Another repeating structure. |
| Location and work authorisation | Often the first hard filter, and often buried in the header. |
What makes resume screening hard
Two-column layouts break naive readers
A design-led resume with a sidebar reads top-to-bottom as interleaved nonsense to anything doing simple text extraction. Layout-aware extraction keeps the sidebar and the main column separate, which is why contact details in a sidebar still land in the right field.
Skills need normalising or the filter is useless
Extracted verbatim, you get 'JS', 'JavaScript', 'Javascript (ES6)' and 'JAVASCRIPT' as four distinct values, and filtering on any one misses the others. A category Cleaner maps variants onto a controlled vocabulary so the filter actually returns everyone qualified.
This is personal data, and the rules are stricter
Resumes are personal data by definition, and in several jurisdictions candidate data carries retention limits and a right to erasure. Bucket visibility and per-user access grants let you keep candidate records restricted to the people running the process rather than visible organisation-wide.
How the pipeline handles it
- Flows — Table fields keep each role and each qualification as its own row rather than one text blob.
- Cleaners — Normalises skill names onto a controlled vocabulary and computes total experience from role dates.
- Buckets — Candidate records as a filterable table, with per-bucket access so applicant data is not visible org-wide.
- Email Integration — Applications that arrive by email get processed on arrival, attachments included.
Common questions
- Does it handle two-column and designed resumes?
- Yes. Extraction is layout-aware rather than reading raw text top to bottom, so sidebars and multi-column layouts do not interleave into nonsense.
- Can it standardise skill names?
- Yes. Extract verbatim, then use a category Cleaner to map variants onto a controlled vocabulary so filtering on a skill returns every candidate who has it.
- How is candidate data kept private?
- Buckets can be private rather than organisation-visible, with per-user Viewer or Editor grants. Candidate records stay restricted to the people running the process.
Other document types
Try it on one document
Build a flow, send a real resume screening through it, and see what comes back. Free credits to start.
Start free