LaborChex Replaces a Blocked Oracle Recruiting Cloud API Integration with Files.com SFTP

LaborChex has run employment background screening since 1991. It is a consumer reporting agency: employers send it applicant data, it runs criminal history searches, verifications, driving records, and drug testing, and it returns a screening report the employer can hire on.

The company's pitch to employers is integration. Its platform embeds with a client's HR and applicant tracking software so a screening order can be placed in one step, without re-keying candidates into a second system. That pitch puts LaborChex permanently between two systems it does not own: the client's hiring system on one side, and the screening platform its reports are produced on, on the other. Every order that crosses that gap is a file of candidate PII: names, Social Security numbers, dates of birth.

When a long-standing hospital client implemented Oracle HRIS and required an integrated screening data flow over SFTP, LaborChex's planned JSON API integration into Oracle Recruiting Cloud stalled because it could not obtain sandbox access. Files.com became a reusable SFTP integration layer LaborChex could control, removing manual handling without requiring custom development for each client.

Screening Orders Moved by Encrypted Email and by Hand

For clients without a direct integration, that gap was crossed by encrypted email. The client exported candidate batches as CSV files and mailed them. Someone at LaborChex received each batch and transferred it by hand into the screening system. The handling was manual on both sides, for every batch, from every client on that path.

The cost landed on the worst possible data and the most critical flow. The files being handled by hand carried the most sensitive information LaborChex touches, and an order file that does not arrive is a background check that does not get processed. Candidate PII sat in inboxes on both sides while it waited for a person to move it. As integration volume grew, LaborChex had outgrown one-off workarounds built on email and manual handling. Email was simply where the problem showed.

A No-Manual Mandate and a Blocked API

The problem stopped being survivable when the hospital client implemented Oracle HRIS and required an integrated screening data flow, submitted over SFTP. Manual handling was off the table entirely.

“They just want the end result: no more manual.”

LaborChex started down the modern route and began building a JSON API integration into the client's Oracle Recruiting Cloud instance. The approach required access to the Oracle Recruiting Cloud module sandbox, and LaborChex could not obtain it. That is the structural trap of API integration for a screening firm: the integration exists only if the HRIS vendor grants the access to build it, and LaborChex controls neither the client's hiring system nor the grant.

Whatever replaced email had to sit between two systems LaborChex does not control, without custom development per client. It had to speak SFTP, because the client required it. It had to keep each client's data apart from every other client's, get order data into the screening system within the hour of its arrival, which was the bar LaborChex set for itself, and expire candidate PII on a schedule rather than trusting someone to clean it up. And it had to be repeatable, because the next client integration could not be a new engineering project.

LaborChex selected Files.com to provide that controlled integration layer.

One Folder and One Credential per Client

Files.com became the integration layer between the client's hiring system and LaborChex's screening platform: a layer LaborChex controls end to end, no matter what either endpoint does or does not offer.

The client's Oracle HRIS writes CSV order files, each carrying one or more candidates, over SFTP into a client-specific folder on LaborChex's Files.com site. Each counterparty gets its own credential, scoped to its own folder. The client's system has a dedicated SFTP user that can post order files and nothing else. The screening platform connects with its own account to collect them and manage the flow. Neither touches any other client's data, which is what makes a single intake site safe to share across every client LaborChex adds.

The screening platform polls the folder on a schedule and creates a background check order from each file it finds, putting order data in the system within the hour of arrival. Using Files.com Automations, each file is moved into a processed archive the moment the screening platform downloads it, so nothing is ever picked up twice.

That archive is the only copy of candidate PII living outside the screening system, so LaborChex put a Files.com retention policy on it. Archived files purge automatically after a set window, deliberately shorter than the company's internal log retention because the copy carries PII, with enough of a floor left for troubleshooting.

No More Manual, Within the Hour

With the Files.com workflow in production, LaborChex replaced an exception process built around encrypted email and manual handling with a repeatable integration pattern.

• Candidate data leaves the client's hiring system and arrives in the screening platform with nobody touching it. Orders are created within the hour a file lands.
• The client's mandate was met exactly as stated: no manual handling, over the protocol it required, and a long-standing relationship held through the client's HRIS change.
• Candidate PII no longer travels by email or waits in an inbox. The one copy outside the screening system sits behind a scoped credential and deletes itself on policy.

The compounding result is larger than the first integration. Nothing in the design is specific to this client. Holmes described the same structure as the template for any further client running a similar integration: a client-specific folder, a posting credential, the same automation and retention behavior. Adding the next one takes no new development and no waiting on an HRIS vendor's API program.

The Integration Layer Is Now Theirs

LaborChex never got the Oracle sandbox. It stopped needing it. What it built instead is a repeatable way to connect any employer's hiring system to its screening operation, whether or not a direct integration is on offer.