← Blog

August 18, 2026 · Fedor Erashev, Founder, Gemsift

How to search your own candidate database (2026): the box is answering a narrower question than you asked

How to search your own candidate database (2026): the box is answering a narrower question than you asked

Here is a thing that happens in every agency I talk to. A role comes in, the recruiter searches the database they have been building for six years, gets eleven results, three of which are people they already placed, and concludes that the base is dead. Then they go back to the job boards and pay again for candidates they already own.

The base is usually not dead. What has happened is subtler and more annoying. The search box answered a narrower question than the one that was asked, and it did not mention that it had done so. You typed a query about a person. The box ran a query about a specific slice of stored text, and returned an honest answer to that instead.

This is not a complaint about your ATS. It is a mechanical fact about how these systems store and retrieve, and once you can see it, your existing search gets noticeably better within an afternoon. This piece is about getting results out of the system you already own today, not about buying anything.

I checked vendor documentation for this piece rather than repeating the standard Boolean advice, and the specifics genuinely surprised me. Three products that all advertise "Boolean candidate search" search three different surfaces, in three incompatible syntaxes, and one of them silently switches Boolean off under a condition nobody would guess.

Contents

Quick summary

  • "Boolean candidate search" names three different products. Verified in vendor docs this month: Recruiterflow's Boolean file search runs on files attached to profiles and its documentation states plainly that it "does not search notes, activity logs, or custom fields". Manatal's Boolean runs on "data parsed from candidate resumes, social media (i.e. Linkedin profile,...), fields in candidate profiles and candidate tags". Bullhorn's Search and Match, powered by Daxtra, returns candidates whose "resume or indexed (monitored) fields" match. Three different surfaces, one label.
  • Bullhorn switches Boolean off if you mix syntaxes, by design. Its query language documentation states that "Boolean operators are only interpreted in simple full-text queries. If the query contains any other above mentioned query syntax, such as field names or condition operators, boolean operators won't be recognized." Add a field filter to your carefully built OR string and the OR stops being an OR. No warning, just fewer results.
  • The proximity syntax is not portable. Bullhorn uses brackets, where [Java developer] matches those terms in any order "possibly with one or two words in between". Loxo uses a tilde, where "sales award" ~5 finds terms within five words of each other. A string copied from a Boolean guide into the wrong system does not error. It searches for the punctuation.
  • Wildcards have rules you will hit by accident. In Bullhorn the * "can only be used at the end of a query term", "needs to be preceded by at least 2 characters", and wildcard terms "cannot be part of phrases or proximity expressions". Loxo's documentation is blunt: "Loxo only supports the wildcard as a suffix, not a prefix." Neither will tell you at the time.
  • Operators usually have to be uppercase. Manatal: "Operators AND, OR and NOT must always be written in capital letters." Recruiterflow requires uppercase for the same reason. Lowercase and is not a Boolean operator, it is a word you asked to search for.
  • Most zero-result searches are index problems, not query problems. A record with no attached document, an image-only PDF with no text layer, a two column CV whose skills rail got dropped in parsing, and one human split across two duplicate records all look identical from the search bar: absence.
  • The layer no syntax fixes: a resume is a snapshot written for a different job at one moment. If the skill was learned after the file was uploaded, it is not in the document, and no operator recovers text that was never written.
  • Semantic search buys recall and costs precision, and it hides its own cutoff. Manatal documents a relevance threshold where candidates below it simply do not appear, caps on semantic criteria (up to 20 skills, 5 job titles, 3 specialisations), and states its AI outputs "may not always be fully accurate or complete".
  • Gemsift is one answer here and I build it, so weigh accordingly. It is the AI-native ATS you move into with one export file, and it re-reads the whole base against each new role instead of waiting for you to guess the right string. Free, $99, $299 a month, and Scale from $899, as of August 2026.

Why should you listen to us?

I build Gemsift, an AI-native ATS for recruitment agencies, so I have an obvious commercial interest in you concluding that database search is hard. Read this with that in mind. I have tried to make it useful even if you never buy anything, because most of what follows makes your current tool work better and costs nothing.

The specifics here come from two places. First, vendor documentation read this month rather than from memory, quoted directly so you can check me. Second, conversations with agency owners and solo recruiters about what actually happens when they search their own base. The sentence "I know he is in there somewhere" comes up so often that it is effectively the product brief.

Where I could not verify something, I have said so rather than filling the gap with a confident number. There is a lot of confidently sourceless statistics in this category and I would rather be the boring one.

Layer 1: which surface is the box searching?

Every ATS has some version of a keyword box. What differs, invisibly, is what sits behind it. There are usually four candidate surfaces in a recruitment system:

  1. The parsed record. Structured fields the parser extracted when the file arrived: name, current title, current employer, skills, education, location.
  2. The document text. The full text pulled out of the attached CV file.
  3. Human-entered context. Notes, call logs, activity history, custom fields, tags. This is where the most valuable information in a small agency lives, because it is what the recruiter learned on the phone and the candidate never wrote down.
  4. Enriched or external data. Social profiles and third party data, where the product does that.

Now the part that matters. Products do not agree on which of those the search box covers, and their documentation is where you find out.

Recruiterflow is the clearest and the most restrictive. Its Boolean file search "let[s] you combine keywords with logical operators (AND, OR, NOT) to filter candidate files" uploaded to profiles, and the help article states the limit outright: it "does not search notes, activity logs, or custom fields". So the conversation where the candidate told you they had moved into a new specialism, typed carefully into a note, is invisible to that search. Surface 2 only.

Manatal goes wider. Its Boolean is "based on data parsed from candidate resumes, social media (i.e. Linkedin profile,...), fields in candidate profiles and candidate tags". Surfaces 1, 4, and tags, and notably built on parsed data rather than raw file text, which means parser errors propagate directly into search misses.

Bullhorn, through Daxtra Search and Match, "will return all candidates whose resume or indexed (monitored) fields contain a match to the keyword string or Boolean expression". Surfaces 1 and 2, and note the word monitored: fields are indexed if configured to be, which means the answer for your instance depends on your configuration, not just the product.

None of these is wrong. They are different design decisions. But if you have used two of these systems, you have carried habits from one into the other, and those habits quietly stopped working when you switched.

One more from the same Bullhorn documentation set, because it is a good example of how much detail hides in help pages nobody reads: radius search there "searches inside a box instead of a circle", calculated from the centre of the postcode. Your "within 20 miles" is a square. Some of your results are further away than you think, in the corners.

The 10 minute audit of your own search

Do not take my word for any of this, and do not take the vendor's marketing page either. Run this on your own system. You need one candidate you know well.

  1. Pick a person you personally placed or interviewed. Someone whose history you know without looking.
  2. Open their record and note four things: an unusual word that appears in their CV file, a fact that appears only in a note or activity log, a value in a custom field or tag, and their current job title as stored.
  3. Search each one separately from the main search box. Not four terms in one query. Four separate searches.
  4. Write down which ones return them. This is your surface map. If the note fact fails, your search does not read notes, and every piece of phone-call intelligence your team has ever captured is outside the index.
  5. Now search their exact stored job title in quotes, then without quotes, then a two word fragment of it. If the quoted version fails while the fragment works, your phrases are being broken by tokenisation or a parse error, and you should stop using quoted titles.
  6. Finally, take a term you know is in the CV and search it in lowercase with and joining it to a second term. If results jump around versus uppercase AND, your system requires uppercase operators, as Manatal and Recruiterflow both document.

Ten minutes, and you now know more about your search behaviour than most vendors will tell you in a demo. Do it once per system, write the result on a sticky note, and every search after that is aimed rather than hopeful.

Layer 2: what actually made it into the index

Suppose your syntax is perfect and you know your surfaces. You can still get zero results for someone who is definitely in there, because the text you are searching for never entered the index. The four common causes look identical from the search bar, and they need different fixes.

The record with no document. Candidates arrive from LinkedIn captures, job board feeds, CSV imports, a referral typed in during a call, or a migration from an older system. Plenty of them have a name, an email, a title, and no CV file at all. On a system like Recruiterflow, where Boolean file search runs on attached files, a candidate with no attached file cannot be found by that search at any query. They are not missing. They are unsearchable by that route.

The image-only PDF. A scanned CV, a photographed page, or an export that flattened everything into a picture has no text layer. The file opens and looks perfect to you. To the index it is an empty document. OCR is inconsistently supported across this category and, importantly, inconsistently documented, so do not assume it ran. Test it directly: open a scanned CV in your ATS and try to select the text with your cursor. If you cannot select it, your search engine cannot read it either.

The parse casualty. Two column layouts, tables, text boxes, headers and footers, and graphics-heavy design CVs all confuse parsers that infer meaning from reading order. The usual damage is a dropped skills rail, merged employers, or a header repeated on every page being read as the current employer. This matters most on systems that search parsed data rather than raw text, Manatal's Boolean being the documented example, because a skill the parser missed is a skill the search cannot find.

The split human. One person applies with a personal email in 2023 and a work email in 2025, and becomes two records. One has the good CV, the other has the notes and the submission history. Search by skill and you find the half with the CV, which has none of the context. Search by relationship and you find the half with no document. Neither half looks like a strong candidate. The whole person would have been an easy call.

The practical response is not a data cleanup project. Small agencies never finish those, and I would not advise starting one. It is narrower: for the roles you actually work, learn which of your candidates are unsearchable and stop treating a zero result as evidence of absence. When a search for an obvious term returns suspiciously little, the correct next thought is "what cannot this search see" rather than "we do not have those people".

Layer 3: what the document could possibly say

This is the layer that no syntax, no vendor switch and no cleanup fixes, and it is the biggest of the three.

A CV is not a profile of a person. It is a document one person wrote, on one particular day, aimed at one particular job, describing what they had done up to that point in the words that suited that application. Your database is a collection of those snapshots, most of them stale.

So when you search for an accountant with FP&A experience and get nothing, one entirely normal explanation is that the person moved from audit into FP&A eighteen months after they sent you that file. The evidence you want does not exist in your database. It never did. There is no query that recovers text nobody wrote.

The same effect shows up in vocabulary rather than time. The same job carries a dozen titles across employers, and candidates describe identical work in the language of their own industry. Somebody who "led a team of ten AEs closing six figure deals for our cloud platform" will never match your search for "enterprise SaaS sales manager", not because they are a bad fit but because those are different words for the same career. Boolean asks for the words. It cannot ask for the job. This is the same failure that buries good applicants in live roles, which I wrote about in why keyword filters reject good candidates.

Understanding this changes how you treat your base. Stop expecting it to answer "who can do this job today". Ask it "who was near this job when I last looked", then do the freshness work by phone. That is a smaller, more honest question, and your existing search can actually answer it.

The syntax trap: strings that fail silently

Search engines built for recruiters share a design decision that punishes their best users: a malformed query almost never errors. It just quietly means something else and returns a plausible number of results, so you never learn.

Four verified traps worth knowing:

Mixing query styles can disable Boolean entirely. Bullhorn's documentation is explicit: "Boolean operators are only interpreted in simple full-text queries. If the query contains any other above mentioned query syntax, such as field names or condition operators, boolean operators won't be recognized." You build a good OR string, add one field condition to narrow it, and the OR silently stops working. The result set gets smaller, which is exactly what you expected from adding a filter, so nothing looks wrong.

Proximity syntax does not travel. Bullhorn expresses it as [Java developer], matching those terms in any order "possibly with one or two words in between". Loxo expresses it as "sales award" ~5, meaning within five words. Neither understands the other. Paste a tilde into a system that does not support it and you are searching for candidates who wrote a tilde.

Wildcards have position rules. In Bullhorn the * "can only be used at the end of a query term", must be "preceded by at least 2 characters", and "wildcard terms cannot be part of phrases or proximity expressions". Loxo states it as plainly as possible: "Loxo only supports the wildcard as a suffix, not a prefix." So *ology does not do what you hoped anywhere, and manag* inside a quoted phrase does not do what you hoped in Bullhorn.

Case matters for operators. Manatal: "Operators AND, OR and NOT must always be written in capital letters." Recruiterflow requires the same, so that operators are not mistaken for search terms. Keywords themselves are case-insensitive in Recruiterflow, so Java and java behave identically, but a lowercase or is a word.

And the failure mode that has nothing to do with syntax: over-ANDing. On LinkedIn, adding a fifth requirement narrows a huge pool to a workable one. On your base of four thousand records with patchy parsing, adding a fifth requirement takes you to zero and convinces you the base is empty. Job board habits are the wrong habits here, because the two things being searched have almost nothing in common.

A search order that works on your own base

Here is the sequence I would use, built for a small, messy, high-value internal base rather than a normalised job board index.

1. Start with the loosest thing that could work. One or two core terms, no filters, no quotes. Your goal in the first pass is not a shortlist, it is finding out whether the population exists at all. If a single obvious term returns almost nothing, stop querying and go look at Layer 2. You have an index problem and a better string will not solve it.

2. Expand the vocabulary before you narrow the criteria. Write out five to ten ways people describe this job, including the tools, the industry words, the client-side titles and the abbreviations. (SDR OR BDR OR "sales development" OR "lead generation") finds a population. "Sales Development Representative" finds people who used your exact phrasing. Broad ORs are what internal bases reward.

3. Only then filter, and filter on things a human definitely entered. Location, most recent activity, or a status field your team genuinely maintains. Avoid filtering on parsed fields you have never verified, and remember that in some systems adding a field condition changes how the rest of your query is interpreted.

4. Sort by the right date, and check which date it is. Created, last modified, last activity and last contacted are four different things, and automated syncs or enrichment can bump "last modified" without a human ever speaking to anyone. Find out which field your list is actually ordered by before you use it as a proxy for relationship warmth.

5. Run a second search on a different surface. If your first pass went through file text, run the same idea through notes and tags, or through the parsed-field search, depending on what your product offers. The candidate who is invisible to one surface is often obvious in another. This single habit finds more people than any operator.

6. Exclude last, and lightly. Killing records marked as placed, do-not-contact, or unresponsive is worth doing at the end. Doing it at the start, on fields your team fills inconsistently, throws away good people who happen to have an empty field.

7. Treat the output as a call list, not a shortlist. On an internal base, the result of a good search is thirty plausible names of whom maybe six are current, reachable and interested. That is a normal, healthy outcome. The freshness pass is phone work, and doing it well without damaging your list is its own process, which I covered in how to reactivate your candidate database without burning it.

What AI search changes here, and what it does not

Almost every ATS now offers a semantic or AI search alongside the keyword box. Being honest about the trade: it is a real improvement on exactly one of the three layers, and no help at all on another.

Where it genuinely wins. Layer 3, the vocabulary problem, is what semantic matching is for. A conceptual query can connect "led a team of ten AEs closing six figure deals on our cloud platform" to your enterprise SaaS sales role without either party using the other's words. That is a category of candidate Boolean cannot reach at any level of skill, and it is why the whole approach is worth having.

Where it does not help at all. Layer 2. If the CV is an image with no text layer, or the record has no document, semantic search has nothing to embed. Zero remains zero, more expensively.

Where it costs you something. Precision and control. Concept matching is weak at hierarchy and negation: it does not reliably distinguish the senior manager from the person who mentions reporting to one, or deep expertise from a single sentence about a project that briefly touched a technology. Hard exclusions are hard to express. This is why hybrid use, a conceptual pass for reach followed by human judgement or explicit filters for precision, beats either alone.

And the part I would push back on hardest: the cutoff you cannot see. Manatal's own documentation describes a relevance threshold where candidates who fall below it do not appear in results at all, alongside caps on how many semantic criteria you can specify, up to 20 skills, 5 job titles, 3 specialisations, 5 industries. The system is deciding what you do not see, which is the same complaint recruiters have about keyword filters, wearing better clothes. To their credit, Manatal also states in the same documentation that AI outputs are "meant to guide, not replace, your judgment" and "may not always be fully accurate or complete", which is a more honest framing than most of this category manages.

The question worth asking on any demo is therefore not "does it have AI search" but "show me what it excluded and why". A percentage with no reasoning is not an answer you can defend to a client, and I have argued the wider version of this in the shift to AI-native recruiting.

When better searching is not the answer

Three situations where the honest advice is to stop optimising queries.

Your base is small enough to read. Under a few hundred candidates in the relevant vertical, the fastest path is opening them, not querying them. Every hour spent on search craft is an hour not spent on the phone.

The problem is genuinely absence. If you have never worked this vertical, your base does not contain those people, and no technique will conjure them. That is a sourcing job, and it is a different product category, one I do not sell.

Your team does not enter the data the search would need. If nobody logs calls or fills fields, no search over notes and fields will ever work, and switching tools will not change the underlying behaviour. Either fix the habit, which is hard, or use a system that reads the documents you definitely do have rather than the metadata you definitely do not.

That third case is the common one in agencies of one to twenty people, and it is why I stopped believing better search UI was the answer. Asking busy contingency recruiters to maintain a taxonomy so their search works is asking them to do unpaid librarian work between submissions. The alternative is a system that does the reading itself, on every role, without being asked.

Where Gemsift fits, honestly

Gemsift is the AI-native ATS an agency moves into when its current ATS has become a filing cabinet. You import with one export file, and when you open a role it re-reads your entire candidate base against that role and returns a client-ready shortlist with a plain English reason per person, not a percentage.

On the three layers above, the design intent is straightforward. Layer 1 stops mattering, because the re-read covers your base rather than a configured subset you have to learn. Layer 3 is the part it is actually built for: reading what someone did rather than matching the words they happened to use. Layer 2 it cannot fix by magic, and I will not claim otherwise. A CV with no text layer contains no information for anything to read, and a conversation nobody wrote down is not recoverable by any software.

The other design decision worth naming: the re-read fires when you open a role, rather than waiting for someone to remember to search. Most of the value in an agency base is lost to nobody looking, not to looking badly.

Prices as of August 2026, and confirm them on the site since they change: Free at $0 for a base of 100 people with no card, Solo at $99 a month for 1,000 people, Agency at $299 a month for 5,000 people with three seats, and Scale from $899 for larger bases or more seats. Annual billing gives two months free. Full export as CSV or JSON is on every plan including the free one, which is the leverage you should insist on from any vendor, mine included. You can also run it against built-in sample data without uploading a real resume.

Where it is not the answer:

  • You need heavy integrations, job board posting, or enterprise compliance tooling. Keep a traditional ATS. This is not that.
  • You are a pure outbound headhunter. Your problem is finding people who never applied to you. That is sourcing, not reading your base.
  • Your volume per role is single digits. Read them yourself, you will be faster.
  • You want the relationship history back. We read what is in the documents. We cannot recover a call nobody logged.

If you want a fair test rather than a demo, run the same real role through your current search and through a re-read of the same base, and compare the two lists person by person. The interesting number is not how many each returns. It is how many good people appear on one list and not the other.

Start free, no card

FAQ

Why does my ATS search return nothing when I know the candidate is in there?

Three possibilities, in order of likelihood. The search is running over a surface that does not contain your term, for example file text when your evidence lives in a note. The text never entered the index, because the CV is an image with no text layer, the record has no attached document, or the parser dropped that section. Or the term was never in the document at all, because the person acquired that experience after they sent you the file. Run the 10 minute audit above and you will know which of the three you have.

How is this different from the AI already in my ATS?

Your ATS ranks on keyword and field overlap against the record it parsed when the resume arrived, and it runs your pipeline. Gemsift does the judgement call: who is worth a call and why, read against the context of the specific role including the unwritten requirements you keep in your head and never put in the public job post, with the reasoning in plain English so you can agree or overrule it.

There are two honest paths from here. Move into an AI-native system where that reading is the spine, or keep your current ATS and add a layer that does the reading. Both work. What does not work is expecting a keyword index to surface someone who described the same work in different words.

Should I clean up my database before I try to search it properly?

No, and the cleanup project is a trap. Small agencies start them and never finish, because the work is unbillable and the payoff is diffuse. Do the narrow version instead: for the vertical you actually work, find out which records are unsearchable and why, and merge the duplicates you trip over as you trip over them. Everything else can wait for a system that reads documents rather than depending on metadata you were never going to maintain.

Is Boolean search still worth learning in 2026?

Yes, for precision work and for exclusions, which is where concept matching is weakest. But learn your own system's dialect rather than the generic guides, because the syntaxes are not compatible: proximity is brackets in Bullhorn and a tilde in Loxo, wildcards are suffix-only in both, operators must be uppercase in Manatal and Recruiterflow, and in Bullhorn mixing field syntax into a Boolean query stops the Boolean being interpreted. A string that is correct on one platform fails silently on the next.

Half the resumes in my base are AI-written now. Won't AI just be fooled by them?

That is what it is built for. Half the pile is now near-identical AI-written applications, and honest candidates write to the filter too, so signal gets buried on both sides.

Gemsift judges the substance under the wording instead of rewarding the best prompt. An AI-written resume is not a weak candidate, so nobody is disqualified for looking AI. We flag the low-signal filler and surface the actual person, so the strong applicant who wrote like a human does not sink.

I already do this in Claude or ChatGPT. Why would I pay for a system?

If you already feed a model your role context for each role, you have proven the point: that context is what makes the call good.

What you would pay for is the part you rebuild by hand every time. Structure, so you are not reassembling prompts and files per role. Consistency, so the same criteria apply across a whole base and across your team rather than one careful chat. A persistent base, so last quarter's candidates are still there when this quarter's role lands. And an explanation you did not have to write yourself. If a tuned project already gives you all of that, keep it.

Is my candidate data safe?

Your uploads are used to score your own pile, and you can evaluate the reasoning on built-in sample data without uploading a real resume. If your organisation has data-governance rules, start there and ask us for a data-handling summary covering where data lives and how long it is kept. Several recruiters have told us they cannot trial anything with real client data at all, which is a fair constraint and the reason the sample path exists.

Search behaviour quoted in this article was read from vendor help documentation in August 2026, and prices from vendor pricing pages in the same month. Vendors change both, sometimes quietly. Confirm current behaviour and pricing on the vendor's own documentation before you rely on it.

Related reading: candidate rediscovery software, three machines under one label · ATS for a small recruitment agency · how to reactivate your candidate database