Recruitment operations
Candidate Database Design: Fields, Structure and Rules
By Andre · · 15 min read
Candidate Database Design: Fields, Structure and Rules
A good candidate database rests on three linked records: a person, a job, and the application that connects them. Around those you add a short list of searchable fields, a rule for duplicates, and a retention schedule. For most small teams the fastest way to fill it is to build it from the CVs already arriving in your recruiting inbox, not to type them in. RecrutFlo reads CV attachments from a connected shared mailbox and turns them into searchable candidate profiles, so the design below can be live without a data-entry project.
This guide is for owners, HR teams, agencies and recruiters who receive applications by email and want a structure that still works at 5,000 candidates.
TL;DR
- Model three things separately: the candidate (a person), the job, and the application that links them. Never store a job inside a candidate row.
- Keep the original CV file, and extract only the fields you will actually search: location, skills, languages, experience, role, availability.
- Use controlled values (fixed lists) for anything you filter on, and free text only for notes.
- Decide on duplicate matching and a retention date before the first import, not after.
- A spreadsheet works to about a few hundred candidates. Past that, a purpose-built database fed from your inbox beats both manual entry and a full ATS for small teams.
Table of Contents
- What a candidate database has to do
- The three core records
- Which candidate fields are worth keeping
- Controlled values beat free text
- Duplicates: decide the matching rule first
- Search and filtering: design for the queries you run
- Spreadsheet, database or ATS?
- Building the database from CVs you already have
- Keeping data accurate over time
- Privacy, access and retention
- Start with a free plan, scale with volume
- FAQ
- Sources
What a candidate database has to do
A candidate database is the place where everyone who has ever applied to you, or been referred to you, can be found again. Its design should answer three practical questions:
- Can we find a person in under a minute? By skill, location, language or past role, not just by name.
- Do we know what happened to them? Which job they applied for, what stage they reached, who spoke to them.
- Are we allowed to keep them? Why we hold the data, who can see it, and when it gets deleted.
Every design decision below serves one of those three. If a field does not help you find, track or justify keeping a person, leave it out.
The three core records
The cleanest recruitment data models split into three entities. Bubble’s documentation for applicant tracking apps describes exactly this: a Talent record for the candidate profile, a Job record for the position, and an Application record that joins the two and carries its own status, interview date, notes and rating.
Why the split matters:
- One candidate, many applications. Someone who applied for a warehouse supervisor role in March and a logistics planner role in September is one person with two applications, not two people.
- Status belongs to the application. A candidate can be rejected for one job and still be a strong match for another. If “rejected” sits on the person, you will lose them.
- Jobs close, people stay. When a vacancy is filled, the job record is archived and the candidate pool stays searchable.
| Record | What it describes | Typical fields |
|---|---|---|
| Candidate | A person | Name, email, phone, location, current title, skills, languages, years of experience, links, source, consent date |
| Job | A vacancy or client brief | Title, department or client, location, required skills, status (open, on hold, filled), owner |
| Application | A candidate applying to a job | Candidate, job, date received, stage, interview dates, rating, notes, outcome and reason |
Agencies add one more level: a client record that owns jobs. Even if you start without it, leave room for it.
Which candidate fields are worth keeping
The common mistake is designing a form with 40 fields and then leaving 30 empty. Start from the searches you run. If you never filter by “date of birth”, do not store it; in several jurisdictions you would be wise not to hold it at all.
A practical core profile has these groups:
- Identity and contact: full name, email, phone, links to professional profiles.
- Location: city, region, country, and whether the person will relocate or work remotely.
- Role context: current or most recent title, seniority level, industry.
- Skills: a tagged list, not a paragraph.
- Languages: each language with a level.
- Experience: total years and the last two or three positions with dates.
- Availability and expectations: notice period or start date, salary expectation, work-type preference.
- Administrative: source (email, referral, job board), original file, date received, last-contact date, status, and the date until which you may keep the record.
The last group is the one teams forget and later regret. It is what turns a pile of CVs into something you can defend.
Keep the original CV
Extracted fields are a search index, not a replacement. Always store the original PDF or Word file against the profile. Parsing is never perfect on unusual layouts, and a recruiter will sometimes need to read the real document. The structured fields get you to the right ten people; the CV lets you decide among them.
Controlled values beat free text
Search quality depends on consistency. If one record says “NYC”, another “New York, NY” and a third “New York City”, a location filter finds a third of your people.
Fix this at design time:
- Location: store city, state or region and country as separate fields, with standard names.
- Seniority: a short fixed list (entry, mid, senior, lead, executive).
- Availability: immediate, within one month, within three months, passive.
- Work type: on-site, hybrid, remote; full-time, part-time, contract.
- Skills: a maintained list of tags. Merge synonyms (“JS” and “JavaScript”) once, centrally.
People Managing People makes the same point on data hygiene: set strict criteria for what enters the database, check fields and data types periodically, and tag candidates by skills or attributes so advanced searches work. Free text still has a place, but only for notes and for the raw CV text, which should itself be searchable.
For location in particular, a clean city field is what makes radius and map searches possible. Our piece on searching candidates by location shows how CV data becomes map results.
Duplicates: decide the matching rule first
In an email-driven process duplicates are guaranteed. People apply twice, apply to two jobs, or are forwarded by a colleague and also apply themselves. Without a rule you get three profiles for one person, three different statuses and a candidate who is contacted twice.
Define the rule before importing anything:
- Primary match: the email address, lowercased and trimmed.
- Secondary match: normalized phone number, or name plus city when email is missing.
- Action on a match: attach the new CV and application to the existing candidate, keep the older file, and record the date. Never silently overwrite.
- Review queue: uncertain matches (same name, different email) go to a person, not an automatic merge.
RecrutFlo flags duplicate candidates as CVs come in, and extracts contact details so that the email-based match has something reliable to work with. You still decide what happens with a flagged pair, which keeps a recruiter in control.
Search and filtering: design for the queries you run
Write down your ten most common searches before you finalize the structure. For example:
- “Forklift operators within 30 miles, available this month.”
- “Bilingual Spanish and English customer support, mid-level.”
- “Accountants with payroll experience who applied in the past 12 months.”
Each one maps to fields: location, language, availability, skills, date received. If a search needs something you did not model, you have found a missing field. If a field supports no search, you have found one to drop.
Then make sure the database supports combining filters, not only keyword search. Keyword search on CV text catches the unexpected; filters on controlled fields make results repeatable, so two recruiters running the same search get the same list.
Spreadsheet, database or ATS?
This is the decision most small teams actually face.
| Spreadsheet | Purpose-built candidate database | Full applicant tracking system | |
|---|---|---|---|
| Best for | Under a few hundred candidates, one or two users | Teams whose CVs arrive by email and who need to find people fast | Teams running structured multi-stage hiring with career pages and job-board posting |
| Data entry | Fully manual | Extracted from CVs automatically | Applicants enter data through forms |
| Duplicates | Manual checking | Detected on import | Usually detected |
| Access control | Whole-file sharing | Per-user roles | Per-user roles |
| Setup effort | Minutes | Connect a mailbox | Implementation project, often with onboarding calls |
| Weak point | Breaks at scale, no audit trail | Not a job-posting tool | Cost and complexity for small teams |
A spreadsheet fails in predictable ways: two people edit different copies, CV files live in a separate folder with no link to the row, and nobody can say who saw what. A full ATS solves those but assumes applicants arrive through its forms, and many small employers and agencies still receive most applications as email attachments.
That is the gap RecrutFlo is built for. It connects to your existing inbox (Microsoft 365, Outlook and IMAP mailboxes today, with Gmail coming soon), so you do not move candidates to a new channel. It identifies CV attachments in incoming mail, parses PDF, DOC and DOCX files, and builds the searchable profile. Setup involves no onboarding call or implementation project.
Building the database from CVs you already have
Most teams are not starting from nothing: they have years of attachments sitting in a shared inbox. The practical route is the same whether you do it by hand or with software.
- Define the fields and the lists. Use the groups above. Keep it to what you search.
- Pick the source of truth. One shared mailbox or folder, not each recruiter’s own inbox.
- Extract. Pull contact details, experience, skills, languages, location, role context, salary expectation and availability from each CV. Doing this by hand takes several minutes per CV; across a backlog of thousands it is the reason databases never get built.
- Match and merge duplicates. Apply your rule once on the historical backlog, then continuously.
- Attach the original file to the profile.
- Set status and retention date on every record.
- Spot-check. Open a sample of 20 profiles against their CVs and note which fields come out wrong.
On step 3, RecrutFlo does the extraction from the mailbox automatically, returning structured profiles you can search by skills, experience, languages, location and role. Step 7 is worth keeping as a habit: our note on candidate data quality for a recruiter inbox pilot lays out five dimensions to check. For the full workflow, see how to turn CVs in your inbox into a searchable candidate database, and how it works for the product walk-through.
Agencies managing several clients should also read about agency CV management, where the client-to-job level is added.
Keeping data accurate over time
A database is only as good as its last update. Build maintenance into the design rather than hoping for a cleanup day.
- Last-contact date. Sort by it. Anyone untouched for a year is a candidate for a refresh email or deletion.
- Correction path. The FINDHR technical report, an EU research project on fair recruitment software, says systems should keep stored data useful as they are updated and support correcting inaccurate personal information. In practice: a recruiter can edit a field, and the edit is logged.
- Source tracking. Knowing which channel produced which candidates tells you where to advertise.
- Outcome reasons. Record why someone was not progressed, in neutral, job-related terms. These notes can later be read by the candidate or a regulator in some jurisdictions, so write them as if they will be.
For teams that want to go deeper on using hiring data, a guide to data-driven hiring covers how to turn these records into decisions.
Privacy, access and retention
Candidate data is personal data. Design the controls into the structure.
Access. Give each person their own login and limit access by role. GE’s published employment-data standards call for unique user identifiers and passwords and role-limited access based on job duties, plus backups and security training. For a small team that translates to: recruiters see candidates, hiring managers see only shortlisted ones for their own jobs, and only an administrator can export or delete. A shared mailbox password used by six people fails this test; our checklist of shared inbox permissions covers what to verify.
Purpose and minimization. The same GE standards describe employment data as lawful, purpose-limited, relevant, accurate and kept only as long as necessary. That is a design rule: every field must have a recruiting purpose.
Retention in the United States. Federal rules set a minimum, not a maximum. Under 29 CFR 1602.14, employers must preserve application forms and other hiring records for one year from the date of the record or the personnel action, whichever is later. The period extends when a discrimination charge has been filed. Some states and federal contractors have longer requirements, so confirm yours with your employment lawyer. Store a “keep until” date on every profile and review it on a schedule.
Candidates outside the US. If you hire in the EU or UK, GDPR-style rules on lawful basis, notice and deletion apply on top. Our GDPR recruitment compliance guide for small teams explains them in plain terms. Rules differ by country and change, so treat any retention figure as one to verify for each place you recruit.
RecrutFlo provides workspace isolation, team access control, an audit trail and CSV export, and its approach to candidate privacy is built around EU data protection principles.
What we have learned about candidate databases
Most small teams do not have a database problem, they have an inbox problem. The candidates are already there, in attachments, and the work of copying them into a system is what never happens.
That is why we built RecrutFlo to sit on top of the mailbox you already use rather than ask you to move to a new platform. Recruiters keep control: automation does the repetitive reading and typing, and people make the decisions. Pricing and plan limits are published, and you do not need a sales call to start.
If you design the structure well, with three records, controlled fields, a duplicate rule and a retention date, the software has something clear to fill. If the design is vague, no tool will rescue it.
Marco
Start with a free plan, scale with volume
RecrutFlo’s plans are tiered by usage volume, so you can test the workflow on your own inbox before paying. The Free plan has no published price; Starter is 19 € per month, Professional 49 € per month and Business 149 € per month. If you need more capacity in a busy month, extra processing runs are a one-off purchase: 100 for 9 €, 500 for 29 € or 1,000 for 49 €. Full limits are on the pricing page, and you can see the process on how it works.
If you are replacing a spreadsheet or a heavy ATS with something simpler, connect one shared mailbox and see how many of your existing CVs become searchable profiles on RecrutFlo.
FAQ
How many fields should a candidate profile have?
As few as support your real searches, usually 15 to 25. Group them into identity, location, role, skills, languages, availability and administrative fields. Keep the original CV for everything else.
Can I use a spreadsheet as a candidate database?
Yes, for a small pool and one or two users. It stops working when several people edit it, when CV files drift away from rows, or when you need access control and an audit trail. At that point a database fed from your inbox saves the manual entry.
How long can I keep candidate data in the US?
Federal rules require employers to keep application and hiring records for at least one year under 29 CFR 1602.14. Some states and contractors require longer. Set a keep-until date per profile and check your state’s rules with an employment lawyer.
How do I stop duplicate candidates?
Match on normalized email first, then phone, then name and city. Attach new CVs and applications to the existing profile instead of creating another, and send uncertain matches to a person to review.
Sources
- Applicant Tracking System (ATS) Apps, Bubble Docs
- Build a Candidate Database to Hire the People You Need, People Managing People
- Software development guide, Technical Report, Project FINDHR
- GE employment data protection standards
- 29 CFR 1602.14, Preservation of records made or kept, eCFR
- Data-Driven Hiring: A Practical Guide for HR Leaders