One Feed, Not Six Tabs: Building an Integrated Recruitment Workflow by 2027

An integrated recruitment workflow is one where a candidate's record travels intact from application to offer without a human retyping it. Most Australian hiring teams do not have one. They have an ATS, an assessment platform, a reference checking tool, a scheduling tool and a reporting spreadsheet, and the integration layer between them is a recruiter with six browser tabs open and a good memory.

This article is about the architecture of that data layer: where records break between systems, what a single candidate record should hold, and how to sequence an integration so it finishes. It is not a product tour, and the approach works whichever ATS you are on.

The six-tab problem is a data problem

The tabs are the symptom. The cause is that each system owns a different slice of the same candidate and none of them agrees on who that candidate is.

Your ATS knows the application and the stage. The assessment tool knows a score under its own candidate ID. The reference tool knows what two referees said, usually keyed to an email address. Your calendar knows when the interview happened. Your reporting spreadsheet knows a number someone typed in last Friday. Five records, one person, no shared key.

Three costs follow, and they compound. Re-keying introduces errors, and an error in a candidate's email address is the one that quietly loses the candidate. Reporting becomes archaeology, because assembling a funnel means exporting from four systems and reconciling by name. And nobody can answer the basic question of where a candidate actually is right now without opening several tools and forming an opinion.

Where candidate data handoff actually breaks

Integration projects fail at predictable seams. These four cover most of it.

• ATS to assessment - Breaks when: the invitation is sent manually from the assessment tool, so the ATS never learns it was sent; Symptom: candidates sitting at "assessment pending" who were never invited
• Assessment back to ATS - Breaks when: the score returns as a PDF attachment rather than a field; Symptom: you cannot filter or report on scores, only read them one at a time
• ATS to reference checking - Breaks when: referee details live in a free-text note; Symptom: reference status is invisible until someone asks
• Everything to reporting - Breaks when: each system stamps its own timestamps with different definitions of a stage; Symptom: two dashboards giving two different times to hire, both defensible

The last one deserves attention because it is the most expensive and the least visible. If your ATS counts time to hire from requisition approval and your spreadsheet counts from first advertisement, the two numbers will never reconcile and the argument about which is right will outlive the integration project.

What one candidate record should hold

Before choosing any tooling, write down the record. A single candidate record that can carry a hire needs six things, and most teams discover they have been treating three of them as optional.

A stable identity

One ID that every system references, with email as a secondary key rather than the primary one. People change employers and email addresses mid-process, and any design that keys on an email address will eventually split one person into two records at the worst moment.

Source and consent

Where the candidate came from and what they agreed to, including how long you may keep their data. This belongs on the record itself, not in a separate privacy register nobody opens, because the record is what gets exported.

Stage, with one definition

The current stage and the timestamp it was entered, defined once across every system. This single decision resolves most reporting disputes before they start.

Evidence, as structured fields

Assessment scores, reference outcomes and interview ratings as fields rather than attachments. A PDF in a file store is a document, not data, and the distinction decides whether you can ever report on quality of hire.

Decision and reason

Who decided what, when, and the stated reason. Without this the record cannot answer a complaint and cannot teach you anything after the fact.

Communication history

Every message sent, visible to anyone picking the candidate up. Mostly this prevents two recruiters contacting the same person about different roles in the same week.

Sequencing an integration so it finishes

Integration projects stall because teams try to connect everything at once. Sequence it in four passes instead, and treat each one as shippable.

Pass one: agree the vocabulary. Before any connection is built, write down what each stage means and when a candidate enters it. This is a one-hour argument that saves a quarter of rework, and it is the single step most often skipped.

Pass two: make the ATS the system of record. Pick one system that holds the truth about stage and identity, and make every other tool defer to it. It does not greatly matter which one you choose. It matters enormously that you choose.

Pass three: connect the highest-volume seam first. For most providers that is the assessment handoff, because it runs on every candidate rather than only on finalists. Shipping the highest-volume seam first gives you a visible result while appetite still exists. Where a native connector covers the seam, use it: the JobAdder integration is one example of a prebuilt path that removes a re-keying step, and the time saved is the subject of our write-up on reducing time to hire with JobAdder.

Pass four: build reporting last. Reporting built before the vocabulary is agreed hardcodes the inconsistency into a dashboard, and then the dashboard becomes the thing nobody is allowed to change.

One decision to make early: for each seam, choose a native connector, a general integration platform, or a direct API build, and write down why. Connectors are fastest and least flexible. Integration platforms handle the awkward middle and add a subscription. Direct builds fit exactly and need an owner who is still employed in two years. The failure mode is not choosing wrongly, it is choosing by accident and discovering the constraint later.

What to ask a vendor before you believe the integration exists

"We integrate with that" covers everything from a certified two-way sync to a CSV export someone wrote once. Four questions separate them.

• Is it one-way or two-way, and which fields move in each direction?
• Is it real time or batched, and if batched, how often?
• What happens when it fails: silent drop, retry, or an alert to a named person?
• Who supports it when it breaks, your vendor or theirs?

The failure-handling question is the one that gets skipped and the one that matters at 4pm on a Friday. An integration that fails silently is worse than no integration, because the team trusts it. These questions belong in a shortlist process alongside the capability checklists in our rundown of enterprise recruitment software features, and if you are still choosing a stack, our recruitment tools compared for Australia sets out the trade-offs by team size.

Frequently Asked Questions

Do we need an integration platform or will native connectors do?

Native connectors are usually enough below roughly four systems, especially if your ATS is a major platform with a connector marketplace. Above that, or where you need conditional logic between systems, a platform earns its cost. Start with connectors and add a platform when you hit a seam they cannot cover.

Should the ATS or the HRIS be the system of record?

The ATS owns the candidate up to offer acceptance, and the HRIS owns the person from that point. Define the handover precisely at that boundary. Problems come from leaving it vague, not from where you draw it.

How long does this take?

One seam is typically days of configuration where a connector exists, and weeks where it does not. The vocabulary work in pass one is the long pole, because it needs agreement from people who do not attend integration meetings.

What about data we hold in spreadsheets?

Treat each spreadsheet as a system that needs the same decisions: who owns it, what it is the truth about, and when it will be retired. Most survive because they fill a genuine gap, so find the gap before deleting the file.

Does this change our privacy obligations?

It changes where personal information lives and who can reach it, so the assessment needs redoing rather than inheriting. Map which systems hold what, where it is hosted, and how retention rules apply once a record spans several tools.

An Integrated Recruitment Workflow Starts With the Record

The temptation is to start with connectors, because connectors are visible and vocabulary is not. Teams that start there spend a year moving data nobody agrees on. Write down the six fields, name one system of record, connect the busiest seam, and leave reporting until the definitions hold. Done in that order the six tabs close one at a time, and each one stays closed.