Why Your Recruiters See Each Other's Candidates, and How to Fix It

Twice this year we shipped a recruiter filter that quietly did nothing. In May, the filter on the HireQwik inbox was looking the recruiter up by an identifier that the login did not actually carry. In July we found the same class of mistake in a different filter, one that was meant to list only the roles a recruiter owns, and it simply returned every role. Both times the symptom a customer saw was the same: “why can I see everyone’s candidates?”

Both are fixed. But the experience taught us that when a recruiter sees candidates from someone else’s role, it is worth diagnosing carefully rather than assuming the feature is broken. Today, the cause is almost always one of six setup issues, and each has a short fix.

First, confirm what they should be seeing

The rule is short: a member sees the roles they own, plus any role nobody owns, and an admin sees every role. It applies the same way to the inbox, the interview list, the shortlist and the Excel export.

So before anything else, ask two questions about the person who reported it. Are they a member or an admin? And which role are the unexpected candidates from? The answers point straight at one of the causes below.

A quick triage table

If you want the answer before the explanation, match the symptom here and jump to the cause.

Cause 1: The role has no owner

How to spot it. Open Team Management and look at the Role assignments card. If the role the stray candidates belong to shows no owner, this is your answer.

Why it happens. Roles without an owner are visible to every member on purpose. When ownership was introduced, hiding every unassigned role would have made existing work vanish for teams that had never assigned anyone. So unassigned means shared.

The fix. Pick an owner from the dropdown. The role immediately leaves every other member’s views.

This is by far the most common cause. A role gets created in a hurry, nobody sets the owner, and three weeks later all five recruiters are seeing its applicants.

It is worth explaining why we chose “visible to all” rather than “hidden until assigned,” because the trade-off is real. Hiding unassigned roles would make every recruiter’s view perfectly tidy, and it would also mean that a role created by an admin who forgot one dropdown would be invisible to the whole team. Applicants would arrive, AI interviews would complete, and nobody working day to day would know. In hiring, a candidate nobody sees is worse than a candidate everyone sees, because the second problem is at least noticeable. So we kept unassigned roles visible and made the fix a single click.

Cause 2: The person is an admin

How to spot it. Their row on the team list shows Admin or Owner.

Why it happens. Admins see the whole workspace by default, because someone has to see the whole drive. It is not a leak; it is what the level is for.

The fix. If they genuinely need admin rights, switch on the My roles toggle on the interview list to narrow it to roles they own. If they do not need admin rights, ask another admin to change them to a member. Our guide to choosing access levels covers who usually needs which.

Cause 3: The candidates are not linked to a job description

How to spot it. The stray interviews belong to a bulk drive campaign rather than a specific role, or the stray shortlist run was screened against an uploaded job description file instead of a role saved in the workspace.

Why it happens. Filtering works by role. Anything with no role attached cannot be assigned to anyone, so it stays visible to the whole team rather than disappearing from every view. Hiding it would mean nobody could find real work.

The fix. For ongoing hiring, create the role as a saved job description with an owner and run screening against that. Use a one-off uploaded file only for genuinely one-off screens.

Cause 4: Two recruiters are sharing a login

How to spot it. Two people describe seeing “their” candidates and the lists match exactly. Or the approval history shows decisions one of them does not remember making.

Why it happens. Access follows the login. Two people on one account are one person as far as the workspace is concerned.

The fix. Invite each recruiter with their own email, then give each the roles they run. Separate logins also give you an honest record of who did what, which matters if a hiring decision is ever questioned; we cover that in what legal teams ask about AI hiring audit trails.

Cause 5: One role is really two hiring decisions

How to spot it. Two recruiters both need the same role, so it is assigned to one and the other keeps asking to see it, or it is left unassigned so both can.

Why it happens. Ownership is per job description, not per candidate. A single role covering two cities, two campuses or two shifts often has two recruiters in real life.

The fix. Split it into two job descriptions, one per location or campus, each with one owner. This also makes each shortlist easier to hand to the right hiring manager. If the two roles end up with similar names, the workspace labels them so they can be told apart; see duplicate job description labels.

Cause 6: Ownership was changed, but the screen was not reloaded

How to spot it. An admin reassigned a role or changed someone’s level a few minutes ago, and the person still sees the old menus.

Why it happens. The filter on the data applies immediately, because every request re-checks ownership and level on our servers. What a browser tab already has open does not repaint itself, and a newly changed level only updates the menus after a reload or fresh login.

The fix. Reload the page. If the stray candidates are still there after a reload, it is one of the other five causes.

The other direction: seeing too little

Occasionally the complaint runs the other way. An admin says they can only see a handful of roles. We had a real bug of exactly this shape in July, where a check was looking at the wrong field and treated some real admins as members. It is fixed. Today, the usual explanations are simpler:

• My roles is switched on. The toggle lives in the page address, so a bookmarked “my roles” link opens filtered. Switch it off.
• They are actually a member. Check their level on the team list.
• A role belongs to someone who has left. A role still owned by a removed account is not treated as unassigned, so members stop seeing it. Reassign it to a current recruiter. Our handover guide explains the order that avoids this.

Prevent it at the moment a role is created

Five of the six causes are setup drift, and most of that drift starts on the day a role is created. The person creating a job description is usually focused on the content: the requirements, the knockout questions, the rubric. Ownership is one dropdown among many, and it is easy to leave for later.

A simple team rule removes most of the problem: nobody saves a new role without an owner. If the person creating it is the one hiring, they pick themselves. If an admin is setting up roles for a drive in advance, they assign each one as they go rather than in a batch at the end, because the batch at the end is the step that gets skipped when applicants start arriving early.

Two other habits help at creation time:

• Name roles for the decision, not just the job title. “Graduate trainee, Pune campus, 2026” tells everyone who owns it and stops a second recruiter from assuming it is theirs.
• Connect intake after the owner is set. Once a Google Sheet or referral form is connected, applicants flow into the role straight away. If the owner is set first, the very first applicant lands in the right inbox.

What a clean setup looks like

It can help to know what “working correctly” looks like, so you have something to compare against. For a team of five recruiters and a TA lead, a clean workspace usually has these properties:

• Every open job description has an owner. The Role assignments card shows no blanks.
• Two admins. Typically the TA lead and one other person, with everyone else a member.
• One login per human. The team list has no generic “hr@” or “recruitment@” accounts.
• One job description per hiring decision. Roles that span two locations with two recruiters are split.
• Screening runs against saved roles. Uploaded job description files are the exception, used for one-off checks.

With that in place, a recruiter opening the interview list sees their roles and nothing else, a TA lead sees everything, and the exceptions are few enough to notice.

When to ask for help, and what to send

If you have worked through all six causes and a member still sees a candidate from a role that has a different owner, that is worth reporting. The fastest reports include four things:

1. The name of the role the stray candidate belongs to, and who it is assigned to on the Role assignments card.
2. The level of the person seeing it, from the team list.
3. Which screen it appeared on: inbox, interviews, shortlist or an export.
4. Whether a reload changed anything.

That is usually enough to tell within minutes whether it is setup or a genuine bug. We would much rather hear about a false alarm than have a real leak sit unreported, and the filter bugs described at the top of this post are the reason we feel that way.

A two-minute monthly check

Most of these problems come from setup drifting over time rather than from a single mistake. Once a month, or before any big drive, an admin can prevent nearly all of them:

1. Open the Role assignments card and give every open role an owner.
2. Look at the team list for shared or departed accounts.
3. Count admins: two is usually right.
4. Ask each recruiter whether their interview list shows anything it should not.

The last step is the one people skip, and it is the one that would have caught our own filter bugs sooner. The person looking at the screen every day is the best test you have. For how the whole ownership model fits together, see splitting AI screening by role, and if you would like us to check your workspace setup with you, book a demo.