Enterprise screening packages tracked against the requisition

A staffing firm with fifteen enterprise clients is running fifteen different screening standards. One wants seven-year criminal history and education verification. Another adds a credit check for finance-adjacent roles and a drug screen for anything on site. A third requires an international component for anyone who has lived abroad in the last five years, and a fourth requires rescreening every twelve months for the duration of an assignment.

That matrix usually lives in a spreadsheet and in the head of one operations manager. When they are on leave and a contractor needs to start on Monday, the wrong package gets ordered, the client rejects the file and the start date moves. Holding the required package against the client and the requisition is the part of this that is actually worth building.

Surhires does not run background checks and is not a consumer reporting agency. The account, the contract, the packages, the pricing and the service levels are between you and Sterling. We make no representation about what a report contains or how quickly it will return, because we are not the party producing it.

The consequential parts also stay with you. Whether ordering a given check on a given role is lawful, the candidate authorisation that permits it, the adverse action process if you decline someone on the basis of a result, and any dispute the candidate raises are all yours to run with your provider. The CRM records what you filed and who looked at it.

Where an agency supplies through a managed service provider or a vendor management system, the screening requirement usually arrives from the programme rather than from the end client, and the evidence of completion often has to be uploaded somewhere else as well. That means the same result is needed in three places: your file, the client's file and the programme's portal.

Filing the result against the candidate record with the date, the package and the ordering user is what makes that possible without a search through email. It also means that when a programme audits your supply chain, the answer is a report rather than a week of reconstruction.

Programmes also change their requirements mid-contract, usually at short notice and always in writing to a mailbox rather than to the recruiters delivering. Holding the current requirement against the client means the change is made once, in one place, and every requisition opened afterwards inherits it. The alternative is a memo that half the desk reads and the other half hears about after the first rejected file.

Order in Sterling's own portal against your own account, as you do now. When the result returns, file it on the candidate record in Surhires: the package that was ordered, the completion date, the ordering user, the outcome you acted on, and the rescreening date if the assignment carries one. Attach the certificate or report itself where your retention policy allows you to hold it.

The product already does the document half of this well. Document capture and expiry reminders sit against the candidate record; the verification itself is a workflow you run, not a certification we hold. The gap the integration would close is ordering, not filing.

Screening outcomes should be visible to the people who act on them and to nobody else. Field-level permissions restrict who can open a filed result, access is logged with actor and timestamp, and retention windows mean documents are not held indefinitely because nobody decided when to remove them.

Disposition codes are a fixed list rather than free text, so if a decision is ever questioned the record reconstructs what happened. A rejection recorded as a coded disposition with a filed result behind it is defensible. A rejection recorded as a recruiter's note saying the check came back is not.