ATS application handoff: an acceptance test for recruitment campaigns

An ATS application handoff test should follow an invented applicant from the campaign destination to the correct vacancy and recruiter queue. Verify the fields, attachment handling, status and failure recovery, because a successful form submission does not by itself prove that the recruiting team received a usable application.

Key facts

• Vacancy export and applicant delivery are different integration directions.
• A confirmation page proves a candidate-facing response, not necessarily an ATS record.
• Test successful submissions and controlled failures with synthetic information.
• Keep credentials and real candidate data out of shared acceptance documents.

What does the handoff need to prove?

Write the expected business result before inspecting a vendor’s integration diagram. The applicant should reach the intended vacancy, retain the information the recruiter needs, appear in an agreed starting state and have an identifiable owner. Each part is independently testable.

Ask which system receives the form first and which system creates the ATS record. If a connector or third-party service sits between them, include it in the acceptance plan. A product directory can establish that an integration is offered, but it cannot establish how your chosen fields and workflow behave.

Adway publishes an ATS and CRM integration directory. Use it to begin a configuration discussion, then request a demonstration of the actual connection. Do not assume that listing an ATS means every field, attachment or status is supported in both directions.

Which test records should the team prepare?

Create an approved test vacancy and clearly invented applicant details. Use a test address controlled by the implementation team, rather than a real person’s address. Give each submission a distinct marker so the team can find it in system logs without guessing which record belongs to the test.

Prepare one complete application, one with optional information omitted, one with an approved attachment and one repeated submission. Add a controlled interruption if the supplier provides a safe way to simulate it. Do not deliberately disrupt a production connector to create a failure case.

Test case	Expected observation	Owner to confirm
Complete application	Correct vacancy and required fields	Recruitment operations
Optional field omitted	Usable record without invented data	ATS administrator
Attachment supplied	Correct file associated with the record	ATS administrator
Repeated submission	Agreed duplicate behaviour	Recruitment operations
Delivery interrupted	Visible error or recoverable queue item	Integration owner
Retry completed	One intended outcome without silent loss	Integration owner

Keep the expected behaviour explicit. Repeated submissions can represent a technical retry or a candidate intentionally updating information. Your acceptance decision should distinguish those cases instead of requiring one universal duplicate rule.

How should you verify the field mapping?

Build a mapping sheet with source field, destination field, permitted values, transformation and failure rule. For a screening answer, compare the candidate’s selected value with the ATS representation. For a location preference, check that an internal identifier still resolves to the correct readable location.

Test punctuation and legitimate name formats. Check whether longer answers are retained, truncated or rejected. A technically successful response can still hide information loss if nobody compares the submitted value with the stored value. Record any documented limits and ensure the form explains them before the applicant submits.

Review required fields carefully. If the ATS requires information that the form does not collect, agree how the workflow obtains it. An invented default is not a harmless workaround when recruiters interpret it as a candidate’s answer. Keep “not supplied” distinct from a negative answer wherever the systems allow it.

The candidate qualification rubric helps define which answers are necessary for a role decision. Avoid collecting extra information simply because the connector has a field available.

How do you test failure recovery without losing applications?

Ask the integration owner to demonstrate what operators see when delivery fails. Identify where the application waits, who receives an alert and how the team safely retries. A dashboard that only reports successful deliveries cannot explain what happened to a missing submission.

Record the identifiers that connect the form event, delivery attempt and ATS record. Those identifiers support investigation; they should not require copying full candidate records into general marketing reports. Agree access to the detailed evidence with the teams responsible for the systems.

In a hypothetical test, submission TEST-B is accepted by the form but delayed before ATS delivery. The team should be able to locate the waiting item, identify its target vacancy and observe the eventual result. If the retry creates two records, the test exposes duplicate handling. If it creates none and the original item disappears, the handoff has not passed.

This is an acceptance scenario, not evidence of a defect in a particular product. The same method can be used to compare several proposed configurations without assuming that their failure modes are identical.

What should recruiters check after technical delivery?

Ask a recruiter to find the test application using their normal working view. Administrator access can reveal records that never reach the team’s everyday queue. Confirm the vacancy, owner, status, screening answers and next action from that practical perspective.

Check whether notifications lead to the right record and whether the next person has permission to open it. A correct record with no responsible recruiter is operationally incomplete. Similarly, a notification that reaches a departed employee does not establish a usable handoff.

Define the response process separately from the integration. The recruiter follow-up workflow covers ownership and exceptions after delivery. Technical acceptance establishes that a record arrived; operational acceptance establishes that someone can act on it.

When should the team repeat the test?

Repeat relevant cases after changing the ATS, connector, application form, screening questions, vacancy mapping or recruiter routing. Keep the previous acceptance sheet so reviewers can compare behaviour and identify what changed. Include a test for a vacancy closed during the handoff if that timing is realistic for your process.

Do not treat the acceptance exercise as an attribution report. Pre-launch testing establishes the intended route. Ongoing reconciliation checks whether real campaign and ATS totals remain explainable over time. Those are related controls with different evidence and owners.

Before signing off, list any limitations, manual steps and unsupported fields. A clear limitation with an agreed workaround is more useful than a broad “all connected” label. To review Adway against a concrete vacancy and application route, Book a demo.

Sources

• Adway integrations, directory checked 2 November 2026.
• Test records, acceptance criteria and the delayed-delivery example are original recommendations. They do not certify any particular integration.

A submitted form becomes useful when the right recruiter can act on it.