Building a candidate database: fields, upkeep and software selection

1. Define the purpose: current applications or a talent pool?

A candidate database is an organised collection of application information that a team can find, associate with a role and act on. For a current vacancy, you mainly need documents, communication and the next step. A talent pool for future roles serves a different purpose: enabling a later conversation. Decide which of these you are organising before choosing fields or software. A large collection of old CVs does not answer that question.

This guide starts with managing applications against specific jobs in a small team. The result should answer a practical question: who needs to act next on which application? If several spreadsheets and inboxes currently run in parallel, the separate guide to moving away from spreadsheets covers the transition. Here, the focus is the structure and continuing quality of your data.

2. Keep the person, application and assessment distinct

One person can apply for two jobs. Each application needs its own history: different requirements, interviewers, messages and decisions. Link the records where appropriate without collapsing them into a single stage. A rejection for job A is not a decision about job B. An assessment also belongs with the requirements against which it was made.

Review possible duplicates before merging information. The same name is not sufficient evidence; a different email address does not necessarily mean a different person. Assign someone to clarify uncertain matches and preserve the connection to the original application. A later application should not silently overwrite earlier documents or observations. The useful question is which information was used, when, and for which application.

3. Template: the working information for an application record

The following template describes information your workflow should be able to locate. It is not a list of additional mandatory questions for applicants, or a promise that every product provides a separate field for every item. Much of it comes from the team's work. Start with what the particular role needs.

1. Association: internal application reference, name, contact route and specific job. Record the application date and source where these are needed for your workflow.
2. Documents: references to the documents received and their receipt dates. Identify a later version rather than maintaining independent copies of the same file in several folders.
3. Work in progress: current stage, responsible person, next action and any promised response date. A stage label does not replace the action.
4. Assessment: job-related criterion, supporting observation and unresolved question. Distinguish a statement in the CV from the team's interpretation.
5. Communication: the last information sent, its date and any outstanding reply. An absence cover colleague should be able to see what the applicant already knows.
6. Data upkeep: the person responsible for corrections, the documented processing purpose and a reference to the applicable retention rule. Schedule a review without treating its date as a universal deletion deadline.

4. Use a worked example to test whether the record helps

Fictional example: Samira Example applies for customer service job CS-04. Her CV is available; the remaining question is whether she has also handled written customer enquiries. Instead of “incomplete documents”, the working note says: “Written customer communication is not yet evidenced. The coordinator will request a short example of this work on Monday; the hiring manager will review the response on Thursday.” The message does not ask her to disclose confidential customer information.

If Samira also applies for a sales job, that application gets its own record. The customer service question is not automatically carried over as a negative sales assessment. During the weekly review, the team checks whether the question was sent and the response considered. The database now shows work and responsibility rather than just names and colours. Shared selection criteria help with the substance of the assessment.

5. Agree purpose, access and retention before adding records

The EDPB's data protection basics explain purpose limitation, data minimisation, accuracy and limited retention. Work with your data protection lead to translate these into rules for recruitment: what is needed, who may access it and when continued storage will be reviewed. Software, or a generic number of months, cannot settle those questions for every organisation.

For storing CVs for future recruitment, the EDPB's FAQ identifies consent and, following the necessary balancing assessment, legitimate interests as possible grounds. Candidates must be informed of the intended purpose. Assess your particular circumstances before moving completed applications into a talent pool. The original application is not blanket permission for every later use.

Also decide where correction and deletion requests arrive, who assesses them and how working copies are tracked. Review access when responsibilities change or a team member leaves. Use fictional records for training and software tests. The acceptance checklist below helps you choose a tool; it does not replace assessment of your own data protection obligations.

6. Test candidate database software with five tasks

Ask for demonstrations using a synthetic application. For each task, record whether it works within the product, needs an organisational workaround or is missing. A broad promise of a “central database” says little about whether a colleague covering an absence can find an unanswered question.

1. Find a record: search for a particular person, then narrow the list by job, stage and date range. Check how the product handles a large number of results.
2. Multiple applications: create two applications for the same fictional person. Do documents, messages and decisions remain associated with the correct job?
3. Handover: ask another authorised colleague to explain from the record what has already been communicated and who acts next.
4. Access: use two test accounts with different permissions to check which records and documents they can see. A hidden button alone is not a complete access test.
5. Upkeep and exit: ask how correction, export and deletion work, and test them in the agreed test environment. Clarify how copies, backups and retention exceptions are handled.

7. Start with a small set and measure its quality

Start with one active job and a small, checked set of records. A named person checks association and completeness; the hiring team checks whether the notes support the next decision. Do not bring across an old collection simply because importing it is technically possible. First establish its purpose, whether it can still be used and how duplicates will be handled.

Initially, review a manageable sample each week. Is an owner missing? Has a promised response become overdue? Is a completed application missing a decision about how its data should be handled? Count these cases separately. Fewer unresolved associations tell you more than a growing number of stored profiles. Repeat the sample after a team change or when recruiting for a new kind of role.

Where Reclyra supports job-related application management

Reclyra lets you search applications by name or email and filter by job, process stage and receipt date range. Internal notes stay with the application. This supports the daily view of active selection processes. Use the feature overview and a demo to compare these tasks with your own workflow.

If your main aim is a long-term talent pool, assess its requirements separately: permissible future contact, keeping information current and reliable retention management. A job-related application list does not automatically meet these requirements. Choose candidate database software according to the work it actually supports and the responsibilities your team still needs to carry out.