What a candidate database is
A candidate database (قاعدة بيانات المرشحين), also called a recruitment database, is the organised store of records on people who have applied to an organisation or whom the organisation has contacted, built so that any record can be retrieved when it is needed.
Two parts of that definition carry the weight. The store covers contact in both directions: people who came to the organisation by applying, and people the organisation approached itself. And it is built for retrieval. A record that was saved but cannot be found again when a vacancy calls for it has been kept without being of use.
Moving a candidate towards a particular vacancy is not the work of a candidate database. That movement, from one stage of hiring to the next for a named role, is the candidate pipeline. The database holds the record, and the pipeline carries the person through the stages of one vacancy.
What makes a record in a candidate database retrievable
A record can be retrieved when it has been written in a form that a search can reach. Four kinds of information do that work:
- Standard fields instead of free text. The role, years of experience, location and specialism, each entered in its field rather than in a paragraph, so that a search can filter on them.
- The source of the record. It names the channel the person came through: an advertisement, an employee referral, direct search or a job fair. Counting by channel is a separate measure, source of hire, which looks only at the people hired.
- Where the record ended. The stage at which the person stopped, and the reason they were not hired, written down.
- Two dates. The date the record was last updated, and the date of the last contact with the person it describes.
A CV uploaded without these fields remains a file that opens only when someone searches for a name they already know. That is the condition in which a candidate database grows and goes unused: the records are there, but the only way into each of them is a memory somebody already holds.
A careful search string, such as one built with Boolean search, defines the results deliberately, but it can only match what the records contain. Where the role, the location and the specialism were never entered, the search has little to work with beyond the name, and the record stays where it was put.
Duplicate records in a candidate database
One person can apply for three vacancies in two years. If the email address or mobile number is not tied to a single key, that person ends up with three separate records.
The effect is practical, not cosmetic. The candidate’s history is spread across records, so they are asked again about things they have already answered, and any statistic built on the database counts them as three people.
Those two effects fall in different places. Being asked again falls on the candidate and becomes part of their candidate experience, the impression they form of the organisation across the hiring journey. The miscount falls on the organisation: a figure drawn from the database reports three applicants where there was one person, and any rate calculated over that figure carries the same error.
The remedy follows from the cause. One identifier is set for each person, the email address or the mobile number, and every later application is attached to it rather than opening a new record.
How a candidate database record goes out of date
Candidate data describes the moment it was written. Since then, the salary the person asked for may have changed, the job they held may have been left, and the city they lived in may be one they have moved away from.
For that reason every record in a candidate database is taken together with its date. A record that has not been updated for two years is taken as a starting point for contact, not as ready information on which to base a decision.
The two dates listed earlier serve this purpose. The date of the last update shows how old the content of the record is, and the date of the last contact shows how long it has been since anyone spoke to the person. Together they tell whoever opens the record whether they are reading a description of the candidate now or of the candidate as they were.
The record was accurate when it was written. What has moved is the person it describes, and the record cannot follow them unless someone contacts them and updates it.
A candidate database holds personal data on people who are not employees
Candidate records are personal data on people who are not employees of the organisation. Handling them is subject to the provisions of the Personal Data Protection Law (نظام حماية البيانات الشخصية) in the Kingdom, which include specifying the purpose for which data is collected and limiting what is collected to the minimum needed for that purpose.
That the people concerned are not employees does not take their records outside that law. Its scope turns on the processing, in the Kingdom, of personal data relating to individuals, not on whether an employment relationship exists, and a name and contact numbers are among the examples of personal data the law itself gives.
Alongside those provisions, disciplined practice for a candidate database has three parts: a declared purpose for keeping the records, a written period for keeping them, and defined access for the people who use the database. These are matters of practice that the organisation sets, not a restatement of the statutory provisions named above.
The difference from an employee file lies in whom the records describe. An employee file is kept on the organisation’s own workers, from contracting to the end of the relationship. The records in a candidate database describe people with whom no employment relationship may ever begin.
How a candidate database differs from a talent pool
A candidate database is a store: it keeps the record and allows it to be retrieved. A talent pool (مخزون المواهب) is a selected group whose members are actively followed, and in which the reason each person was not hired, the date of the last contact and any change in their situation are written down. The difference lies in the active follow up, not in the container.
The word “database” is also used for the followed group itself. A talent pool can be defined as an organised database of potential candidates, and talent acquisition can be described as keeping a candidate database that the organisation stays in contact with. In both usages the word names the talent pool in the sense set out above, not the store that a candidate database is.
How a candidate database differs from an applicant tracking system
An applicant tracking system (نظام تتبّع المتقدمين) is a system that collects job applications and tracks each candidate through the stages of hiring. A candidate database is one of its components: the searchable store of CVs.
So every applicant tracking system contains a candidate database, but a candidate database on its own does not become an applicant tracking system. An organisation that keeps its records in a spreadsheet has a candidate database, but it has no tracking.
The missing part is the stages. A spreadsheet can hold every field listed above, including the stage at which a person stopped, but it holds that stage as a value someone typed in. Tracking means following each candidate through the stages of hiring, which is the part an applicant tracking system adds to the store it contains.
How a candidate database is measured
The size of a candidate database is not an indicator of anything. The practical question about it is a retrieval question: if a vacancy opened today, how many matching records would it return, and how many of the records it returned would not fit the role?
A candidate database that returns one hundred records, half of which do not match, moves the work to screening instead of reducing it. Fifty records have to be opened and set aside by hand before the fifty that fit can be considered. The measure of its quality is the accuracy of what it returns, not the number.
The two halves of the question are separate, and an answer to one says nothing about the other. A short list of results can still leave out people the database holds, if their fields were never filled in, and a long list can be long because the fields are too loose to separate one role from another. Both outcomes trace back to how the records were written.
This is an explanation of the concept and of the statutory provisions cited, not legal advice.
A standalone Saudi HR system
One employee file holding the contract, the documents and their expiry dates, the attendance record, leave, salary and end-of-service entitlements. End-of-service, overtime and leave-balance calculations are built into the system.
A standalone system on its own subscription. The connection to Qoyod Accounting is now available.