Designing a recruitment data model

A candidate withdraws from one job but has an interview booked for another. If you change their profile status to ‘withdrawn’, what will the next recruiter see? That small problem reveals a bigger design choice: information about a person isn’t the same as information about their application.

A recruitment data model defines the types of records your agency keeps and the relationships between them. It gives a fact a home. Before anyone adds a field, the team should know what it means, where it belongs and who can change it.

Key takeaways

• Keep information about a person separate from their progress on a particular job.
• Give a relationship its own record when it needs dates, an owner or a status.
• Write down the meaning, source and responsibility for each field.
• Test changes, duplicate entry and restricted access before importing real data.

Which records does your agency need?

Start with things that can exist independently: a candidate without an application, a client without an open job or a contact who moves to another company. Give each a record and connect them through relationships. That saves you from copying the same details into a fresh record for every assignment.

The following is a design exercise for a fictional permanent recruitment agency, not a required configuration for every ATS.

Record	What it represents	Information that belongs here
Candidate	A person with whom the agency has a candidate relationship	Contact details and agreed contact preferences
Company	An organisation the agency recruits for or keeps in touch with	Company name and responsible account team
Contact	A person on the client side	Business contact details
Job	A specific recruitment assignment	Requirements and responsible recruiter
Application	One candidate’s involvement in one job	Stage, feedback and next appointment

A client contact might also become a candidate. Decide whether your system uses one person record with different roles or separate records with a controlled link. Two roles don’t necessarily call for two independently maintained copies of a phone number.

When should a relationship become a record?

A relationship needs more than a simple link when you need to record facts about the connection itself. Candidates can apply for several jobs, and a job can attract several candidates. An application holds information about one candidate-job pair, such as an invitation, feedback or withdrawal date.

Microsoft’s explanation of table relationships distinguishes one-to-many from many-to-many relationships. The next question for an agency is what the relationship must tell you. Linking a person to a job doesn’t, by itself, say which interview they have reached.

Consider client contacts too. A contact may represent more than one company. If you overwrite a single ‘employer’ field when someone moves, an old conversation may become difficult to interpret. A relationship with start and end dates could preserve that context. Use it where the history matters; don’t build a separate object for every imaginable exception.

How do you give fields a shared meaning?

Write a short definition before creating a field. ‘Available’ might mean open to a conversation to one recruiter and ready to start next week to another. Separate those meanings when the team actually needs to use them independently.

A small data dictionary could look like this:

Field	Definition	Source and responsibility
Available from	Possible start date stated by the candidate	Recruiter confirms the date and records when
Application stage	Current step for this candidate on this job	Recruiter responsible for the process
Client feedback	Dated response about this application	Recipient records who supplied it
Next action	A specific action with an owner and due date	Person accepting the commitment

A blank isn’t always a mistake. Nobody may have asked about a start date yet. Distinguish ‘unknown’, ‘not applicable’ and a confirmed value where that difference affects the work. An AI parser shouldn’t turn a missing date into a plausible guess.

A required field without a responsible owner creates another problem. Colleagues may fill it just to get past a form, despite having no reliable source. The record looks complete while telling the team very little.

How do you keep copies from contradicting each other?

Use stable record IDs for references and decide which record owns each fact. A name isn’t a dependable identifier: people can share names or change them. An email address can also change or belong to a shared mailbox.

Agree who reviews a suspected duplicate before anyone merges records. Compare relevant contact details and applications as well as the name. Keep one source for current information and make sure existing relationships still point to the right record.

Decide how to handle historical relationships too. A completed application may still explain an earlier rejection, so removing a link differs from deleting a whole record. Align that choice with your retention policy.

Who should be allowed to change each record?

Include access in the design. A recruiter may own an application without needing every piece of information held by a colleague. Consider permissions by record type and, where needed, by field. Test the result using an ordinary user account rather than only an administrator account.

In Simply, you can mark a field as sensitive and limit access to the appropriate roles. A salary expectation, for example, need not be visible to every colleague. Keep field definitions with an administrator so that a new name or meaning is agreed with the team first.

In Simply’s ATS and CRM, an administrator creates objects, fields and relationships and configures access. For example, add ‘available from’ as a date field on the candidate and define it in your data dictionary. Simply Ask can also prepare a model proposal for an administrator to review before it is applied.

What does a one-candidate, two-job test reveal?

Consider this fictional example. Noor has one candidate profile. She has an interview for job A but withdraws from job B. The team records two applications and changes only the stage for B. Her appointment for A remains in place.

Noor then supplies a new phone number. A colleague updates the person record and checks that both applications still point to the current profile. The historical withdrawal from B stays unchanged. Using a restricted account, the colleague also checks which notes they can read.

Discuss the example with the colleague entering the data. Is it clear where the new agreement belongs and which information the other application shares? Adjust the model if that distinction is still unclear.

Keep the expected and observed results together. If a difference exposes an unresolved design choice, revise the model first. Imports and automated extraction come afterwards.

How can you start without a large data project?

Choose a current workflow and draw the records it uses. Walk through a real type of change with a recruiter, such as a client contact moving company or a candidate joining another process. Remove fields that nobody can connect to a clear use.

Bring that drawing to a Simply demo. Ask to see the candidate, both applications and the access check in the same environment. A useful model lets colleagues recover the right information after the situation has changed.