Duplicate Job Descriptions With the Same Title

Two campus drives ran the same week last spring, both hiring for “Business Development Executive.” One was a Tier 1 city rollout, the other a Tier 2 city rollout for the same company. The job descriptions were nearly word for word, because HR had copied one and swapped the location line. When both landed in the same screening account, the inbox showed two filter chips that read “Business Development Executive” and gave no way to tell, at a glance, which chip belonged to which city.

This is not a rare edge case. It is what happens by default whenever a document parser reads a job description, because the parser is extracting exactly what is on the page: a title, a company name, and a skill list. If two JDs describe the same role for the same company, the parser will pull an identical title, an identical company, and often a near-identical skill set. Nothing in that extraction step knows about location, campus, or which reviewer opened which tab five minutes ago.

Where the Confusion Actually Showed Up

Before this got fixed, the collision surfaced in two places at once. The first was the filter chips on the Needs Review tab of the Trigger Inbox, where a recruiter narrows a queue of hundreds of candidates down to one role. Two identical chips meant clicking one at random and hoping it was the right city.

The second was the Jobs page itself, the list of every JD configured in the account. A recruiter scanning that list for “the one I set up this morning” had no way to distinguish a fresh upload from a JD created three weeks earlier, if both happened to carry the same parsed title. The problem compounds at scale. A mid-size enterprise running a full calendar of campus drives, several of them overlapping across cities in the same hiring season, will hit this collision often, not occasionally.

The Fix: A Label That Is Not the Parsed Title

The fix separates two things that used to be the same field: what the source document says the role is called, and what HR actually wants to see when scanning a list of live roles. HR can now set an editable per-JD label at the moment of upload, or change it at any later point, without touching the underlying document. The original parsed role title does not disappear. It stays visible as a subtitle underneath the label, so anyone who needs to confirm what the source JD literally said still can.

This matters because the label and the source document serve different audiences. The parsed title is what the JD says on paper. The label is what a recruiter needs to find the right role in three seconds while triaging a queue. Collapsing those into one field, which is what a straight parser-to-display pipeline does by default, forces every downstream screen, from filter chips to bulk actions, to inherit whatever ambiguity the source documents happened to contain.

Auto-Disambiguation Only Fires on a Real Collision

A label field alone would still leave every fresh upload with a blank, unhelpful default unless a recruiter remembers to fill it in immediately. So the second half of the fix runs automatically, but only when it actually needs to. When two live JDs share an exact title, the system appends the first suffix that makes them distinguishable: the location first, if the two JDs have different locations on file. If location does not separate them, it falls back to the upload date. If two JDs were somehow uploaded with the same title on the same day, it falls back to a short id.

A JD with a unique title in the account is left completely untouched. No suffix, no forced renaming, no cosmetic clutter on a role that was never actually ambiguous. This ordering was a deliberate choice: location is the piece of information a recruiter is most likely to actually be scanning for when two drives for the same title run in parallel, so it is the first thing offered, and the system only reaches for a less meaningful suffix, like a short id, when nothing more useful is available to disambiguate with.

Why Forcing Unique Titles Was Never the Right Fix

The simpler-sounding fix would have been to just require every JD to carry a unique title, the way some systems block a duplicate filename. That fix does not match how campus hiring actually works in India. A recruiter running the same role across five campus cities in the same week is not making a mistake by reusing the title. Reusing it is correct. The role genuinely is the same role, posted in five places, and the JD content should be allowed to stay identical because the job itself is identical.

Forcing artificial uniqueness onto the title field would have meant asking a recruiter to invent a fake distinguishing word for every parallel drive, something like appending a random number to a title just to satisfy a system constraint that has nothing to do with the actual hiring decision. That is friction for no real benefit, and it would have corrupted the one field, the title, that should stay a faithful copy of the source document. Separating the label from the title let us solve the display problem without touching the data.

What Gets Left Alone

What the fix deliberately does not touch matters as much as what it does. The parsed title never changes as a side effect of any of this. The skill list, the company name, and every other field the parser extracted from the source document stay exactly as they were read. Only the label, a display field that sits alongside the parsed data rather than inside it, is ever generated, suffixed, or edited.

That boundary is what keeps the fix safe to run automatically without a recruiter reviewing every suffix before it appears. Auto-generating a label is low-risk precisely because a label is not scored against, not matched against a resume, and not used anywhere in the actual screening logic. It exists purely so a human can tell two JDs apart at a glance. Get it wrong, and the worst outcome is a recruiter renaming it manually a moment later, not a scoring error reaching a real candidate.

What This Looks Like for a Live Campus Drive

Picture the same two-city scenario from the top of this post, but after the fix. Both JDs still say “Business Development Executive” in the parsed title, exactly as the source documents do. But the filter chips and Jobs list now read “Business Development Executive (Pune)” and “Business Development Executive (Nagpur),” suffixed automatically the moment the second JD was uploaded, because the system detected the collision against the first. A recruiter opening the queue that afternoon does not need to remember which JD was created first or guess from context. The distinguishing information is sitting right there in the label, generated without anyone having to type it.

If a recruiter later wants a more specific label than the auto-generated one, for instance distinguishing two roles at the same location by hiring wave, they can overwrite the label at any time, and the auto-generated version is simply replaced. Nothing about the parsed title changes, and nothing about already-triaged candidates gets disturbed by the relabel.

What a Three-Way Collision Looks Like

The suffix cascade described above sounds simple with two JDs. It gets more interesting with three or more, which is common during a heavy campus season when the same title is opened in several cities in the same week. Say a company uploads “Business Development Executive” for Pune, Nagpur, and then Pune again, this time for a second hiring wave a week later. The second Pune upload collides with both the first Pune JD and the Nagpur one on title, so location alone cannot separate it from the original Pune JD, since they share a location too. The system falls through to the next suffix in the order: upload date. The result is three clearly distinct labels, “Business Development Executive (Pune),” “Business Development Executive (Nagpur),” and “Business Development Executive (Pune, Aug 14),” each generated by checking, in order, which piece of information actually distinguishes this JD from the others it collides with.

This cascading behavior is what makes the location-first ordering safe to rely on rather than a rule that only works in the simple two-JD case. A recruiter never has to manually intervene to keep labels distinct as a hiring season adds more overlapping drives; the system keeps checking one level down the suffix order until it finds something that actually separates the new JD from whatever else is already live.

Why This Also Protects Bulk Actions

Ambiguous chips are not just a lookup annoyance. They are a real risk once a recruiter starts using bulk actions on the Needs Review queue, where select-all and bulk-approve operate on whatever the current filter has returned. Filter by the wrong one of two identically labeled JDs, and a bulk-reject aimed at a small pool of low-scoring Nagpur candidates could just as easily land on a batch of untouched Pune candidates instead, because nothing in the chip told the recruiter which pool they were actually looking at.

Clear, distinct labels do not just make browsing easier. They make the filter selection that a bulk action depends on trustworthy, which matters more as an account runs more parallel drives, not less. A single ambiguous chip is a minor friction on a quiet week. The same ambiguity during peak campus season, with several drives running in parallel and reviewers moving quickly through a long queue, is where a mislabeled bulk action actually costs someone a clean shortlist.

The Same Identity Problem Shows Up Elsewhere in a JD’s Lifecycle

A duplicate title is the first place this identity problem surfaces, but it is not the last. The same underlying question, which JD is this candidate actually attached to, comes up again the moment someone tries to delete a JD that still has candidates in it, and again whenever a recruiter needs to rename a JD after a campaign is already running. Both of those situations reuse the same label-versus-identity split described here, and both needed their own fix once the label stopped being tied one-to-one with the parsed title.

None of this required asking recruiters to change how they write job descriptions. A job description that is well written for AI resume matching still benefits from a clean title, a clear skill list, and specific requirements. What changed is what the system does with two of those documents once they happen to describe the same role in two places. That is a display and identity problem, not a content problem, and it needed a display and identity fix.

None of this is unique to India, though the volume and pace of campus hiring here make the collision far more frequent than it would be for a company running one or two roles a quarter. Standardized job requisition management is a known headache well beyond AI screening tools specifically. Deel’s guide to job requisitions recommends validating that a new role does not duplicate an existing one before it is even approved, which is good practice, but it does not help once two genuinely identical roles for different locations legitimately need to exist side by side, which is the normal case in campus hiring, not the exception.

This is a small fix by engineering standards, one field split into two and a suffix rule that only fires on a real collision. Its value shows up in a place that is easy to overlook when you are the one building it: the three seconds a recruiter spends deciding which chip to click, multiplied across every queue, every day, for as long as an account keeps running overlapping campus drives.

If your own screening tool still shows you two identical chips with no way to tell them apart, that is worth raising with whoever runs it. Talk to us to walk through how the label and disambiguation logic handles your own live drives.