One candidate record that actually stays current

No two desks track the same things. A contract IT desk needs right-to-work expiry, rate rather than salary, and availability by week. A retained executive desk needs board experience, sector history and a discreet-search flag. A blue-collar desk needs licence classes, shift preference and travel radius.

Custom fields are typed rather than free text, which means they can be searched, filtered and reported on. A dropdown field becomes a facet. A date field becomes an expiry reminder. A number field becomes a range filter. Adding one does not require a developer or a support ticket.

The failure worth naming is the one that comes from being generous with text fields early. A desk that captures availability as a sentence ends up with four hundred variations of the same three answers, and no filter can be built over them afterwards without somebody reading every record. It is far cheaper to decide on day one that availability is a date and a status than to normalise it in year two, which is why the field types are constrained rather than open.

Search runs across the structured fields and the parsed resume text at the same time. You can ask for a senior back-end engineer within ninety minutes of Leeds, available inside four weeks, who has worked in a regulated environment, and get an answer that respects all four constraints rather than returning everyone whose resume contains the word senior.

Searches can be saved and shared. A saved search becomes a working list that repopulates as new candidates arrive, which is the difference between a database you query occasionally and one that feeds the desk every morning.

The ordering matters more than it looks. Structured filters are applied before text ranking rather than after it, because a relevance score computed across the whole database will happily float a perfect textual match who lives four hundred miles away and is under notice until March. Filter first, rank second, and the top of the list is a set of people you could actually call this afternoon.

Candidates, clients and jobs are all first-class objects, and each carries its own activity stream. On a candidate that means every email, call, message, note, stage change, submittal, interview and outcome in one chronological list. On a client it means every requisition opened, candidate presented, interview arranged and placement made.

This matters most when a desk changes hands. Handover currently happens in a spreadsheet and a half-hour conversation, and the institutional memory is lost. An activity stream makes the handover a matter of reading the record.

It also settles arguments. Two consultants disagreeing about who spoke to a candidate first, a client questioning when a shortlist was sent, a candidate who says they were never told the role was on hold: all three are questions about a sequence of events, and a chronological record with an actor and a timestamp on every entry answers them without anybody searching a personal mailbox.

Candidate data is personal data, and in the UK, the EU and increasingly in the United States it comes with obligations about why you hold it and for how long. The candidate record is designed to carry the consent basis alongside when and how it was captured, and to support a retention window after which a dormant record is flagged for review or erasure.

Export and erasure are meant to be workflows rather than support tickets. A candidate who asks what you hold should be answerable from the record, and a candidate who asks to be removed should be removable without leaving orphaned copies in a dozen exports.

The controls that make this systematic are in build for the Wave 1 release: a fixed lawful-basis list on every record, retention measured from the last contact the candidate actually took part in, and the export and erasure workflows themselves. We describe them in the future tense on purpose. If data protection controls decide your purchase, read the consent and retention page and ask us for the current build state before you commit to anything.

Recruiters live in list views. Selecting forty candidates and tagging them, adding them to a talent pool, sending a templated message or moving them to a stage is a single action from the list rather than forty visits to forty records.

The same list supports keyboard navigation and a select-all that respects the current filter, so a shortlist of three hundred can be worked through without touching the mouse.

Bulk actions are also where the most damage gets done, so the destructive ones behave differently from the additive ones. Tagging three hundred records is instant and reversible. Anything that changes a stage, sends a message or removes data reports what it is about to touch, applies suppression and consent rules at the point of execution rather than at selection, and writes the outcome per record so the result is auditable rather than a single line saying the batch succeeded.

A database of two thousand records and a database of eighty thousand are different products even when the software is identical. At two thousand a recruiter roughly knows what is in there, and search is a convenience. At eighty thousand nobody knows, the question changes from where is that candidate to what do we actually have, and every weakness in how the data was captured turns into a weakness in what can be found.

Two things carry the weight at that size. Structured fields do the narrowing, because full-text ranking across tens of thousands of parsed resumes returns plausible noise unless a filter has already reduced the set to something meaningful. And freshness becomes a first-class attribute: last-contacted date, last-verified availability and the age of the resume on file matter as much as the skills, because a perfect match nobody has spoken to in three years is a research task, not a submittal.

We size Enterprise tenants during onboarding rather than publishing a record ceiling, and we test search behaviour at large database sizes rather than assuming it. The Starter plan is capped at five hundred candidates, which is a deliberate fit for a desk getting off spreadsheets rather than a technical limit.

The first import decides the quality of the database for years, and it is usually rushed. The order that works is to define the custom fields first, decide what a required-at-stage rule is going to be, and only then map the columns. Importing a spreadsheet into a default schema and adding fields afterwards means the fields are empty for every record that already existed, which is most of them.

The parts that generic importers handle badly are the parts an agency cares about: candidate ownership, the date of genuine first contact, the attachments, and any activity history at all. Ownership and first contact usually have to be carried across explicitly from the old system rather than inferred from a created-at timestamp, because a migration that resets them will restart every fee argument the desk has already had.

Bulk import with column mapping is in build for the Wave 1 release, and a migration off an established system runs as a paid concierge project rather than through a generic importer. That is not a sales preference. Custom fields, attachment history and ownership records are exactly where an automated import quietly loses things, and finding out six months later is expensive.

It does not create relationships. A clean, well-structured record of somebody who has never replied to you is a clean, well-structured record of a stranger. Rediscovery pays off in proportion to how many people in the database have actually spoken to your desk, and no amount of field design changes that ratio. What the structure does is make the people who have spoken to you findable again.

It also will not rescue a desk that does not log its work. If the calls happen on a mobile, the conversations happen in a personal inbox and the notes happen on paper, the record will be empty regardless of how good the schema is. The product tries to make logging nearly free, through email and calendar sync, call logging, the mobile app and templated notes. It cannot make logging happen, and a tool that claims otherwise is describing a management problem as a software feature.

Finally, this is recruitment software and not an HRIS, a payroll system, a background-check provider or an assessment platform. It holds candidate relationships, sourcing, submittals and the placement pipeline through to the first invoice. Once somebody is placed and becomes an employee or a contractor being paid, the system of record for that is somewhere else, and we would rather integrate with it than pretend to replace it.