Before chasing the candidate, check the handoff
A candidate submission workflow should move a screened candidate into a reviewed client submission, with a named owner and a visible next action at every step. When CV formatting, screening notes or approval sit in separate queues, that handoff can stall before the client sees the candidate. Connected ATS and CRM workflows can prepare the pack, flag blockers and route follow-ups while the recruiter controls what is sent.
That does not mean every silent candidate is waiting on your agency. People change priorities, accept other roles or decide not to continue. But before recording another case of candidate ghosting, check whether your own team completed the action the candidate was expecting.
The useful question is specific: after screening, where did this candidate stop moving, and who was responsible for the next step?
Screening complete is not the same as submitted
Consider a familiar situation. The recruiter has finished a promising screening call. The candidate is interested. The CV needs the agency's formatting, the call notes are in another application, and the account manager has not yet reviewed the summary.
Everyone has done part of the work. Nobody can yet tell the candidate that their profile has reached the client.
That distinction exists inside recruitment systems too. Bullhorn's documented workflow separates an internal submission for the job owner's review from a client submission after that review. An internal “Submitted” status should therefore not be read as proof that the client has received the profile. Bullhorn hiring workflow.
Start with a shared definition of each stage. Your desk should be able to distinguish a completed screen, a prepared pack, an approved pack, a recorded send and a client response. A single “in progress” label hides too much.
Five places the candidate handoff can fail
1. The CV waits for presentation work
The source CV is available, but a client-ready version still needs formatting, redaction or an agreed template. If that task has no owner or due time, the candidate can sit in a queue nobody sees.
Automate repeatable layout work using the approved source version. Preserve factual content, retain a link to the original and flag missing sections. Formatting must not become an opportunity to invent skills, change dates or strengthen a candidate's claims.
If the underlying record is incomplete or duplicated, fix that first. Our candidate CV-to-ATS guide covers matching the person and protecting existing data before updates.
2. The screening notes never reach the submission pack
A recruiter can have a useful conversation while the evidence remains in a meeting tool or private notes. The person preparing the submission may see a CV without the role-specific context.
Bring the agreed screening fields into the candidate-and-vacancy record: relevant experience, confirmed expectations, availability and unresolved questions. Separate candidate statements from recruiter assessment. A missing value should produce a visible question, not an inferred answer.
See our meeting-notes-to-ATS playbook for the capture, matching and review steps behind this handoff.
3. “Ready” has no clear owner
The delivery recruiter believes the account manager will send the profile. The account manager is waiting for a final summary. Both are working from reasonable assumptions, but the next action is unassigned.
Assign a specific submission owner when screening completes. Give that person a due time and a deputy or escalation route. A notification to a shared channel can support the handoff, but it should not be the only record of responsibility.
4. Missing information is discovered at the last moment
The pack looks complete until someone notices an unresolved rate, the wrong CV version or an unconfirmed working arrangement. Rebuilding it creates another round of waiting.
Run a readiness check before review. Define mandatory information for the particular desk and client, with a reason for each requirement. Do not turn every optional detail into a blocker. A deliberate exception should record who approved it and what the client will be told.
5. The submission is recorded, but the follow-up is absent
Creating an internal record, handing a message to a mail provider and receiving a client response are different events. A status change alone cannot establish all three.
Record the approved recipient, submitted version, sending method, timestamp and available provider or portal reference. Then assign the client follow-up and the next candidate update. If the send fails or its outcome is uncertain, show that state instead of marking the handoff complete.
A connected candidate submission workflow
The following is a proposed operating model. Stage names and deadlines should be agreed for your agency rather than copied into every desk unchanged.
Step 1: Open a candidate-and-vacancy handoff
Trigger the workflow when a recruiter records screening as complete for a specific candidate and job. Link the correct candidate ID, vacancy ID and client context. Do not use the candidate's name as the integration key, or assume a person being screened for two jobs has only one submission in progress.
Create a work item with an owner, due time, screening reference and source-document version. Repeated delivery of the same source event should resolve to that item rather than create another task.
Step 2: Assemble and check the submission pack
Collect the agreed CV, screening summary and role-specific details. Generate the presentation format where that is supported and authorised. Keep source links so the reviewer can check the evidence.
If a required item is missing, move the handoff to Blocked, attach a reason and route a specific task. “Confirm availability with the candidate” is actionable. “Data incomplete” usually is not.
Step 3: Route the pack for recruiter review
Move complete packs to Ready for review, with the named reviewer and due time. Show the proposed recipient and exact documents alongside the summary.
The recruiter checks factual accuracy, current candidate interest, the relevant authority to share the profile, client requirements and any unresolved caveats. Readiness checks can support that decision; they should not silently approve it.
Step 4: Send the approved version and reconcile the result
Bind approval to the candidate, vacancy, recipient and pack version. Revalidate if material details change before sending, including a withdrawn candidate or a closed vacancy.
Use the agreed delivery channel. Store the result at the level the channel can actually confirm. An accepted email-send request is not evidence that the client opened the message. A portal reference may establish a submitted transaction without establishing client review.
If a request times out, investigate whether it succeeded before repeating an external send. A retry must not become an accidental duplicate candidate submission.
Step 5: Create the next two actions
After a recorded send, assign both the client follow-up and the candidate update. Their timing can differ. A client who has not replied does not remove the agency's responsibility to keep its own candidate communication promise.
Stop or change reminders when feedback arrives, the vacancy closes or the candidate withdraws. Avoid sequences that continue chasing people after the underlying situation has changed.
The minimum information each handoff needs
These are suggested workflow fields, not claims about standard fields in every ATS:
- Identity: agency account, candidate ID, vacancy ID and source event ID.
- Pack: CV version, screening-note reference and generated document version.
- Readiness: required-field check results, candidate-interest check and sharing-authority reference under the agency's policy.
- Responsibility: submission owner, reviewer, deputy and next-action due time.
- Review: approved version, reviewer identity and approval time.
- Delivery: intended client contact, channel, send status, attempt reference and recorded send time.
- Exceptions: blocker reason, responsible person, opened time and resolution.
- Follow-up: client feedback due time, next candidate update and stop conditions.
Map these to supported ATS fields, linked tasks or an agreed operational ledger. Copy only the information required for the next step. Keep internal commercial notes and unrelated candidate details out of the client-facing pack.
Three exception cases to design before launch
The notes are ready, but availability is uncertain
Prepare the pack and hold it for the responsible recruiter to resolve the question. Keep the uncertainty visible. Do not silently substitute a date from an older application or infer availability from a CV.
If the client can accept a submission with that caveat, require the agreed reviewer to approve the exception and the wording. Otherwise, the pack remains blocked.
The CV changes after approval
Keep the approved version identifiable. Compare the new document with the pack, and return material changes for review. Do not send a new attachment under an approval that referred to the previous one.
Where a correction needs to reach a client after submission, treat it as an intentional revision with an owner. Do not let a background resync resend the whole profile without review.
The send succeeds, but the ATS update fails
Save the delivery reference and retry the internal status update separately. The recovery action is to repair the record, not send the candidate again.
If the send itself has an unknown outcome, reconcile against the provider or portal where supported. If it cannot be resolved reliably, escalate the item for investigation and keep it out of the “confirmed sent” count.
What must be checked in the integration
Confirm which source event can start the workflow and whether each connected application permits the necessary reads, document access, task creation and updates. Webhooks need the provider's documented verification method, durable queuing and duplicate protection. Polling needs a checkpoint and reconciliation process.
Use the narrowest practical permissions, securely stored credentials and a documented rotation or reauthorisation process. Apply bounded retries for transient failures and rate limits. Invalid mappings, revoked access and uncertain recipients require intervention rather than endless retries.
Bullhorn provides one documented example: its API guide creates a JobSubmission and updates its status. That establishes an ATS record operation, not a universal client-send mechanism. Verify the separate delivery path and its evidence during scoping. Bullhorn job-submission API guide.
For Bullhorn specifically, authentication uses OAuth followed by a REST login that returns the session token and API base URL. Available fields and operations must be checked against the account's permissions and metadata. Bullhorn authentication guide and REST API reference.
Begin with native ATS features if they already satisfy the agreed workflow. A custom connection earns its place when documents, notes, review or delivery cross systems and need controls that the current setup does not provide. No named integration here is presented as an already-delivered TalentBraid implementation.
A hypothetical handoff on a busy desk
At 10:00, a recruiter completes a screening call and recommends a candidate for a vacancy. The workflow creates the handoff under that candidate-and-job pair and assigns the account manager as submission owner.
At 10:05, it finds the CV and notes but flags an unresolved rate expectation. It creates a clarification task for the recruiter. The account manager can see why the pack is blocked rather than assuming the recruiter has not started it.
After clarification, the pack enters review. The account manager checks and approves the exact version. The delivery channel records an accepted send, and the workflow saves that reference before updating the ATS and scheduling follow-ups.
If the candidate withdraws before dispatch, the send is stopped. If the channel reports a failure, the owner receives an exception instead of a false success status.
The times illustrate the sequence, not a service promise or measured result. The improvement is that each transition has a condition, an owner and a recovery path.
Measure the waiting between stages
Define screening-to-submission time as the elapsed time from recorded screening completion to the agreed evidence of client submission. Keep it separate from job-intake-to-first-submission time, which includes sourcing and other work outside this article's scope.
Track both the median and the slowest portion of completed handoffs, such as the 90th percentile. Also report open handoff age so unfinished cases do not disappear from the picture. Agree whether elapsed time means calendar hours or business hours and which time zone applies.
Break the delay into preparation, blocked, review and dispatch time. Record candidate-dependent waits separately from internal waits, while retaining the total elapsed time. Add the proportion of handoffs without an owner, repeat-work rate, unresolved delivery outcomes and overdue candidate updates.
Track withdrawals and non-response alongside those measures, but do not label every loss as caused by delay. A before-and-after comparison can identify patterns; it does not prove that automation caused a change in candidate behaviour or placements.
Our guide to recruitment reporting beyond the ATS explains why operational reporting needs consistent definitions as well as connected records.
Keep candidate information under control
For EU-facing work, identify the lawful basis, purpose and relevant sharing conditions before passing candidate data between systems or to a client. Permission to represent a candidate for a particular opportunity is an operational check; it should not be confused with a complete legal-basis assessment.
Minimise the data in generated packs, logs and notifications. Restrict access, agree retention and deletion across source tools, queues and destinations, identify controller and processor roles, and assess subprocessors and international transfers. Put the relevant DPA in place. See the EDPB guidance on controllers, processors and contracts. GDPR sets requirements for purpose limitation, minimisation, security and processor arrangements. EDPB data-protection basics.
TalentBraid supports GDPR-compliant workflow implementations. Scope and configuration still need engagement-specific checks. Review the TalentBraid data-protection overview when defining the workflow. If additional AI processing is proposed, agree its purpose, payload, retention and processing region before enabling it.
Start with the handoff you can name
Review a small sample of recent screened candidates. For each one, identify when screening ended, what remained to be done, who owned it and when the approved profile was sent. Include cases still waiting and candidates who withdrew. The repeated blocker is a better starting point than a broad instruction to automate recruitment.
TalentBraid builds and manages the automation layer for recruitment agencies. Dedicated engineers scope, implement and validate workflows, then monitor exceptions and maintain the agreed connections after launch. Each engagement has a dedicated technical point of contact through an account manager or engineer according to scope.
If your ATS, CRM or another application provides usable API access, webhooks or an approved integration interface, TalentBraid can assess a custom connection. Final compatibility depends on the required endpoints, authentication, permissions, rate limits, supplier terms and expected volume. Third-party software and usage fees are scoped separately.
Book a call with us through TalentBraid, or email [support@talentbraid.com](mailto:support@talentbraid.com). Send the app names, the manual handoff that stalls, the desired outcome, expected volume and any available integration documentation. We will assess feasibility and a maintainable design before you commit.