Turn a resume backlog into records you can search

An import that finishes with the message nine hundred records imported has told you nothing worth knowing. The number you need is how many of those nine hundred are usable, how many landed on top of somebody already in the database, and which files the parser could not read at all.

Each row in a Surhires batch carries its own result, and the batch is reviewable before it is committed. You can sort the review screen by outcome, open any row to see the parsed values next to the source text, correct a field, or exclude the row entirely. Committing writes only what you accepted.

Most importers check an incoming row against records that already exist. That is the easy half, and on its own it is why a folder containing three copies of the same person, saved by three recruiters under three filenames, becomes three new records.

Duplicate detection runs in both directions here. Every row is compared against the live database and against every other row in the same batch, on email address, phone number and the combination of name with a recent employer. Exact matches merge automatically and say so. Near matches are held on a review screen where you decide, and a merge keeps both resume versions rather than discarding the older document.

Parsing consumes AI credits at a published weight per document, and a scanned page that needs optical recognition weighs more than a text-layer PDF. Discovering that after processing a four thousand file archive is not a reasonable way to run a business.

Before a batch commits, the import dialog shows the file count broken down by type, the credit cost of the run at current weights, and what your balance will be afterwards. You can trim the batch, split it across two months, or import in store-only mode where files are held against records and parsed later. Professional includes one hundred credits per user per month, and further credits are an add-on at a published price.

Imports are the single most common way a database loses track of where its data came from. Two years later somebody asks why you hold a particular candidate and the honest answer is that they arrived in a spreadsheet nobody remembers.

Batch-level defaults are set before the run and written onto every record it creates: source label, record owner, consent basis and the channel through which it was captured, the retention window that applies, and any tags or talent pool the batch should join. Where the source file carries that information per row, map the column instead of applying one value to everything. Records created by an import are indistinguishable from records created by hand, except that they know which import made them.

Any import large enough to be worth automating will partly fail. Files will be corrupt, a scanned page will be a photograph of a photograph, and a handful of documents will turn out to be cover letters with no resume behind them.

A batch is a durable record, so you can close the tab and come back to it. Failed rows are listed with the reason they failed, and you can retry only those rows once the underlying problem is fixed without reprocessing the ones that succeeded. Every record a batch creates carries that batch identifier, which means a bad import can be found, reviewed and reversed as a set rather than hunted down one row at a time.

Importing does not improve the data it is given. A backlog of resumes with no consent basis behind them is a compliance problem after the import in exactly the way it was before, and putting it into a searchable system makes the problem easier to see rather than smaller.

Age matters too. A five-year-old resume produces a record whose salary expectation, notice period and contact number are all likely wrong. The useful pattern is to import the backlog, mark it clearly by source and date, and treat it as a rediscovery pool to be re-consented and refreshed on contact rather than as a list to start messaging on Monday.