Confirm exactly which client, role and profile a candidate has authorized, then distinguish permission to send from evidence that the submission arrived.
A recruiter has a strong candidate and a client deadline. The candidate replied “sounds good” yesterday, but the role now has a different location and pay range. Is the profile ready to submit—or did the team only confirm interest in the earlier opportunity?
A candidate submission permission workflow makes that decision explicit. Often discussed as a right-to-represent or RTR step, it belongs between candidate review and engagement, before placement and onboarding. The operating goal is a traceable chain from the opportunity explained to the candidate, through their response, to the package actually received by the client.
This guide proposes an operating process, not a representation contract or a universal legal consent rule. Use the applicable client agreement, agency policy and qualified privacy or legal review to establish the terms your process must implement.
Define what the candidate is authorizing
Start with one candidate, one identified client and one specific opening. Use the approved staffing job order intake record to confirm the requisition, role, work arrangement and submission instructions. A recruiter should not ask the candidate to approve an opportunity the agency cannot describe consistently.
Before requesting a response, explain the client and role, relevant pay basis or range, location, schedule, engagement type and the information proposed for sharing. Identify the profile or CV version. If a detail is unresolved, say so and obtain clarification rather than filling it in after the candidate agrees.
Real policies illustrate why scope matters. WE Talent’s work-seeker terms, section 4.1, state that it will not pass a CV to a client without permission. J&R Ross Agency’s representation form limits its authorization to disclosed clients and specifically discussed openings. These are examples of those organizations’ terms, not requirements that apply to every agency.
Keep three decisions separate: permission to present the candidate, any agreed representation or exclusivity terms, and the organization’s basis and rules for processing personal information. One “consent” checkbox should not silently decide all three. Route unclear wording or legal effect to the responsible reviewer.
Build a permission-to-receipt record
The recruiter owns the candidate discussion and evidence. The account manager confirms the client’s current submission instructions. A designated release owner checks the package before sending; in a small team that can be the recruiter, but the check still needs an explicit record.
Adapt the following specification in your approved staffing system. Link to restricted candidate documents instead of copying them into a widely shared tracker.
| Record group | What to capture | Progression check |
|---|---|---|
| Opportunity | Candidate reference, agency, client, requisition, role, brief version and relevant terms discussed | Recruiter and account manager confirm the same current opportunity |
| Proposed package | CV/profile version, attachments, intended recipient or portal and excluded information | Candidate-facing explanation matches what is proposed for sharing |
| Permission evidence | Original response or approved form, request version, response time and any conditions | Response clearly covers this client, role and package; ambiguities resolved |
| Release decision | Reviewer, check time, approved package version and open exceptions | No unresolved change, withdrawal or conflicting representation issue |
| Send attempt | Sender, channel, attempt time and package reference | Actual action recorded, not inferred from an approval label |
| Receipt and closure | Client/portal acknowledgement, reference, observed outcome and candidate update | Accepted receipt confirmed, or uncertainty assigned to an owner |
Retain original evidence under the organization’s access and retention rules. Record the source timestamp and time zone when reconstructing events; a recruiter’s later summary should not replace the candidate’s actual response.
Run the release check before the profile leaves
Match the response to the current proposal
Read the response in context. “Yes” can be clear when it answers a specific permission request; “interesting” may only express interest. Ask a focused follow-up when the intended action is ambiguous. Do not treat silence, a public CV or registration in a talent pool as sufficient evidence under this proposed role-specific process.
If the candidate adds a condition—such as approving the profile only after a revised CV is supplied—keep the submission unreleased until that condition is resolved. Record what remains outstanding and who will follow up. The client’s deadline does not answer the candidate’s question.
Check the package and channel
Compare the final profile and attachments with the version covered by the response. Verify the client, requisition and recipient again at release. Remove accidental attachments and unrelated information; do not assume the candidate’s permission covers every file stored in their record.
Check the actual client instructions before sending. A message to a hiring manager may not constitute a valid submission through the required portal. Candidate permission establishes neither that the agency used the accepted channel nor that the client received the package.
Close the loop with an observed outcome
Record the send attempt and then check the available acknowledgement. Use the portal reference or other evidence accepted by the client process. Distinguish “queued,” “attempted,” “received” and “rejected”; avoid a single “submitted” label that means different things to recruiting and account management.
If a portal times out after the send action, inspect its existing record or ask the authorized client contact to confirm receipt before trying again. Keep the original attempt details. A second send is not a reliable way to discover whether the first one succeeded, and it can create a duplicate or conflicting history.
Make exceptions change the next action
| Event | Immediate operating action | Evidence needed to continue or close |
|---|---|---|
| No clear response | Keep unreleased; recruiter asks a specific follow-up | Clear response to the identified proposal, not a reconstructed approval |
| Role or material terms change | Pause release and explain the difference to the candidate | Updated proposal and response covering the revised scope |
| Candidate withdraws before sending | Stop the pending release and check any queued sending path | Observed queue/action outcome; do not assume a status update canceled a message |
| Withdrawal arrives after sending | Record chronology and route the candidate’s request to the responsible recruiter and client contact | Authorized follow-up and client response; do not promise automatic recall or deletion |
| Another agency may already have submitted | Hold this release while the account manager checks the applicable process | Relevant facts and governing terms; escalate a genuine dispute separately |
| Receipt is uncertain | Reconcile the existing attempt before another transmission | Confirmed existing receipt, confirmed failure or an explicitly unresolved exception |
These are recommended operating states, not claims about built-in software enforcement. If a queued message cannot be stopped with the controls actually available, escalate promptly and record what happened. Do not backdate permission to make an already-sent profile look authorized.
If two suppliers are making competing claims, use the separate duplicate candidate submission process. This permission record supplies evidence to that review; it does not establish fee entitlement or decide which supplier wins.
Work through a changed-location submission
Illustrative scenario: a recruiter briefs a candidate on requisition R-42, a daytime role at Site North, and receives clear permission to share CV version 3. Before release, the client changes the location to Site West and revises the pay range.
The recruiter retains the earlier permission but does not apply it to the changed brief. They record version 2 of the opportunity, explain the differences and ask for a response. The candidate requests a revised CV and then approves that version for R-42. The release check links the new response, current brief and CV version 4.
The portal returns a timeout after the send attempt. The account manager checks the existing portal record and finds a receipt tied to R-42 and the candidate. They record that reference rather than resubmitting. The candidate receives an accurate update: the package was received, but no interview or offer has been promised.
The completed chain answers four different questions: what was explained, what was authorized, what was sent and what arrived. A single signed form would not, by itself, answer all four.
Where Workhint fits
Workhint’s Workflow Engine describes configurable request steps, role-based approval routing and requirements for details, files or notes before progression. These building blocks are relevant to gathering permission evidence and assigning a release review.
The Staffing Managers solution describes worker profiles, documents, approval status and manager review. That provides a relevant staffing context for linking the candidate and opportunity records.
The permission-to-receipt process here is a proposed design to validate, not a claim that Workhint supplies a native RTR contract, electronic-signature service, email recall or external portal integration. Identify which steps the configured system can support and which need a named manual owner. In particular, verify how actual sending and receipt evidence will be recorded before treating an internal approval as a completed client submission.
FAQ
Is permission to submit the same as accepting a job?
No. Keep authorization to present a profile separate from any offer, engagement or employment decision. Record the action the candidate actually agreed to rather than extending it to a later stage.
Does every candidate need the same right-to-represent form?
Do not assume one form fits every client or jurisdiction. Establish the applicable terms and review requirements first. The workflow needs reliable evidence of the required authorization; this guide does not prescribe a universal signature method or exclusivity clause.
Can an earlier permission cover another role at the same client?
Under the role-specific process proposed here, ask again for the new opportunity. Check the actual terms rather than assuming client-wide coverage. Preserve the earlier record without using it as proof of a response the candidate never gave.
When is the submission complete?
For this operating process, only after the accepted receipt is evidenced and the candidate update is recorded, or an exception has an explicit disposition. Approval, a queued message and a send attempt are intermediate events, not interchangeable completion evidence.
Leave a Reply