Adding assessments to an existing RecruitNow or OTYS workflow is straightforward in principle. In practice, the most common outcome for teams who rush the setup is a flood of duplicate assessment invitations reaching the same candidate two, three, or even four times. This guide gives you a practical runbook to configure the integration correctly from the start, choose the right connection method, test before you go live, and fix duplicate-invite problems if they appear.
Who this is for: Recruitment operations managers, HR leads, and implementation owners working in RecruitNow or OTYS who need to add an assessment step without creating duplicate work.
Prerequisites: Active access to your ATS workflow configuration, contact with your assessment vendor's integration team, and at least three test candidate records you can use safely.
Expected time: 2–4 hours for planning and configuration; 1–2 days for testing.
Three connection types exist when adding assessments to an ATS workflow, and each carries a different level of duplicate-invite risk.
Native integration means the assessment vendor is pre-built into the ATS. OTYS, for example, lists native integrations with TMA, Drillster, and Selection Lab, allowing recruiters to automatically invite applicants directly from the ATS stage. The trigger lives inside the ATS workflow, and status write-back (completion, scores, report) returns to the same candidate record. Duplicate risk is lowest here because the integration is designed to be idempotent: sending the same trigger twice should not produce two invitations.
Connector/middleware (such as Zapier, Make, or a bespoke integration layer) sits between the ATS and assessment platform. Triggers can fire on stage changes, webhook events, or field updates. The duplicate risk rises because connectors often retry failed calls automatically, and it's your responsibility to configure idempotency keys or deduplication logic.
Custom API gives the most control but requires developer resource. Duplicate prevention must be built explicitly into the integration logic.
Use this quick decision framework before you proceed:
| Criterion | Native | Connector | Custom API |
|---|---|---|---|
| Trigger lives in ATS stage? | Yes | Configurable | Yes |
| Status write-back to ATS? | Built in | Manual mapping | Must be built |
| Duplicate prevention (idempotency)? | Vendor-managed | Must configure | Must build |
| Technical resource needed | Low | Medium | High |
| Typical timeline | Days | 1–3 weeks | 2–8 weeks |
Recommended default: Start with the native path if your assessment vendor supports it. The lower duplicate risk and faster setup outweigh any flexibility you gain from a custom approach.
Work through these in order. Do not skip to step five because you're confident in the configuration.
Map every workflow stage in your ATS. Document which specific stage triggers the assessment invitation and, critically, identify who or what moves candidates in and out of that stage. Both manual actions by recruiters and automated status updates from the assessment platform can re-trigger a stage entry.
Confirm a single source of truth for reports. Decide whether the completed assessment report will appear on the ATS candidate profile, an external portal, or both. Parallel reporting paths are a common root cause of double invitations: two systems each believe they own the trigger.
Enforce a single-shot trigger rule. The trigger must fire only on the first entry into the assessment stage. Status updates sent back from the assessment vendor (for example, "assessment completed") must not re-enter the candidate into the same stage and re-fire the invitation rule. Configure this explicitly, then document it.
Set unique identifiers for each invitation. The integration should map invitations to a unique combination of candidate ID, application ID, and job ID. This matters most when a candidate re-applies for a role or when duplicate profile records exist in the ATS, both of which are common in high-volume hiring.
Build a controlled test dataset. Use at least three test candidates: one clean new application, one duplicate profile scenario, and one case where you manually move a candidate forward and then back into the assessment stage. This last case is the most frequently skipped and the most likely cause of duplicate invitations post-launch.
Run a dry-run and record evidence. Log the number of invitations sent per candidate, the timestamps, and whether any status changes trigger a loop. Screenshot or export the logs before you move on.
Define go-live acceptance criteria. Only approve go-live when all three conditions are met: zero duplicate invitations across all test scenarios, the correct unique assessment URL is generated per candidate, and report write-back appears on the correct ATS profile.
Each scenario below follows the same structure: symptom, cause, fix, and how to verify.
Symptom: A candidate receives two invitations within seconds or minutes of each other, sometimes after a recruiter updates a field on their profile.
Cause: The assessment platform writes a status update (e.g., "invited") back to the ATS. That field update re-triggers the stage-entry rule, sending a second invitation.
Fix: Add a condition to the trigger rule: fire only when the candidate has not previously received an invitation for this job. Alternatively, create a locked intermediate status (e.g., "Assessment sent") that the trigger checks before dispatching.
Verify: Move a test candidate into the assessment stage, then simulate the write-back by manually updating the relevant ATS field. Confirm no second invitation is sent.
Symptom: A recruiter manually sends the assessment invitation at the same time as the automated workflow dispatches it.
Cause: The UI does not show the recruiter that automation has already triggered. Lag in page refresh compounds this.
Fix: Introduce an intermediate "Assessment pending" state that is set the moment the trigger fires. The manual send button should be disabled or hidden while this state is active.
Verify: Trigger the automated dispatch, then immediately attempt a manual send. Confirm only one invitation reaches the test candidate.
Symptom: The same person receives invitations addressed to two different profile records or email addresses.
Cause: A re-application (or an import from a job board) creates a second candidate profile. Both profiles progress through the assessment stage independently.
Fix: Deduplicate and merge candidate records before the assessment stage is reached. Configure the integration to map invitations to the application ID, not just the candidate email, so a single person with two profiles generates only one active invitation per job.
Verify: Create two profile records for the same test candidate and let both reach the assessment stage. Confirm only one invitation is sent.
Symptom: A candidate receives a duplicate invitation 5–30 minutes after the first, with no manual action taken by a recruiter.
Cause: The ATS sent a webhook to the assessment platform but did not receive an acknowledgement in time. It retried. If the assessment platform processed the first call successfully but responded too slowly, both calls created invitations.
Fix: Check the integration logs for retry behaviour. Confirm that the assessment vendor's API returns a 200 acknowledgement within the ATS's timeout window. If not, extend the timeout on the ATS side or implement idempotency keys so duplicate calls are rejected at the vendor end.
Verify: Review logs from the dry-run and confirm only one delivery per trigger event. Ask your assessment vendor whether their API endpoint is idempotent by default.
Symptom: Candidates from different pipeline paths (e.g., direct applicants and referred candidates) both receive invitations, but some receive two.
Cause: Two separate workflow rules both match candidates who enter the assessment stage. One rule may have been set up for a different hiring path and was never restricted to exclude the other.
Fix: Audit all active workflow rules. Ensure rule conditions are mutually exclusive: only one rule should match any given candidate/job combination at a time. Apply "source of application" or "pipeline path" filters to each rule.
Verify: Run one test candidate through each pipeline path and confirm exactly one invitation per candidate.
When a duplicate-invite issue reaches the point of escalation, the quality of information you provide determines how fast it gets resolved.
Gather the following before contacting anyone: the candidate ID and email (anonymised if needed), the job ID, the exact stage name, timestamps of each invitation sent, the number of invitations received by that candidate, any integration logs or webhook delivery records, and a note of any workflow setting changes made in the preceding 48 hours.
Layer 1 (ATS workflow owner): Contact this person first for any trigger rule or stage configuration issue. They can audit workflow rules, conditions, and status mappings.
Layer 2 (Assessment vendor integration support): Contact them for idempotency behaviour, API timeout settings, webhook delivery logs, and report write-back failures.
Layer 3 (IT or implementation partner): Involve this team for custom API or SSO issues, connector middleware configuration, and anything requiring code changes.
Define severity before you escalate so the right people respond at the right speed. Severity 1 applies when duplicate invitations are reaching multiple real candidates in a live environment. Severity 2 applies when duplicates are confined to test cohorts or isolated to a single edge case.
Run this checklist at the end of week one and again at the end of week two:
Platforms such as Selection Lab are designed to support exactly this kind of centralised, ATS-integrated assessment flow, with automated invitations triggering from the ATS stage, the complete report and individual scores visible directly in the ATS, and a documented go-live timeline of 2 to 10 weeks. Post-launch, the adoption support cadence includes bi-weekly check-ins for the first month and quarterly strategic reviews thereafter, which gives implementation teams a structured path to catch any edge-case issues before they affect real candidates.
Getting the integration right the first time is far less costly than repairing candidate trust after duplicate invitations have already landed. Follow the checklist, test the edge cases, and confirm idempotency before you move a single live candidate into the assessment stage.
Adding assessments to an existing RecruitNow or OTYS workflow is straightforward in principle. In practice, the most common outcome for teams who rush the setup is a flood of duplicate assessment invitations reaching the same candidate two, three, or even four times. This guide gives you a practical runbook to configure the integration correctly from the start, choose the right connection method, test before you go live, and fix duplicate-invite problems if they appear.
Who this is for: Recruitment operations managers, HR leads, and implementation owners working in RecruitNow or OTYS who need to add an assessment step without creating duplicate work.
Prerequisites: Active access to your ATS workflow configuration, contact with your assessment vendor's integration team, and at least three test candidate records you can use safely.
Expected time: 2–4 hours for planning and configuration; 1–2 days for testing.
Three connection types exist when adding assessments to an ATS workflow, and each carries a different level of duplicate-invite risk.
Native integration means the assessment vendor is pre-built into the ATS. OTYS, for example, lists native integrations with TMA, Drillster, and Selection Lab, allowing recruiters to automatically invite applicants directly from the ATS stage. The trigger lives inside the ATS workflow, and status write-back (completion, scores, report) returns to the same candidate record. Duplicate risk is lowest here because the integration is designed to be idempotent: sending the same trigger twice should not produce two invitations.
Connector/middleware (such as Zapier, Make, or a bespoke integration layer) sits between the ATS and assessment platform. Triggers can fire on stage changes, webhook events, or field updates. The duplicate risk rises because connectors often retry failed calls automatically, and it's your responsibility to configure idempotency keys or deduplication logic.
Custom API gives the most control but requires developer resource. Duplicate prevention must be built explicitly into the integration logic.
Use this quick decision framework before you proceed:
| Criterion | Native | Connector | Custom API |
|---|---|---|---|
| Trigger lives in ATS stage? | Yes | Configurable | Yes |
| Status write-back to ATS? | Built in | Manual mapping | Must be built |
| Duplicate prevention (idempotency)? | Vendor-managed | Must configure | Must build |
| Technical resource needed | Low | Medium | High |
| Typical timeline | Days | 1–3 weeks | 2–8 weeks |
Recommended default: Start with the native path if your assessment vendor supports it. The lower duplicate risk and faster setup outweigh any flexibility you gain from a custom approach.
Work through these in order. Do not skip to step five because you're confident in the configuration.
Map every workflow stage in your ATS. Document which specific stage triggers the assessment invitation and, critically, identify who or what moves candidates in and out of that stage. Both manual actions by recruiters and automated status updates from the assessment platform can re-trigger a stage entry.
Confirm a single source of truth for reports. Decide whether the completed assessment report will appear on the ATS candidate profile, an external portal, or both. Parallel reporting paths are a common root cause of double invitations: two systems each believe they own the trigger.
Enforce a single-shot trigger rule. The trigger must fire only on the first entry into the assessment stage. Status updates sent back from the assessment vendor (for example, "assessment completed") must not re-enter the candidate into the same stage and re-fire the invitation rule. Configure this explicitly, then document it.
Set unique identifiers for each invitation. The integration should map invitations to a unique combination of candidate ID, application ID, and job ID. This matters most when a candidate re-applies for a role or when duplicate profile records exist in the ATS, both of which are common in high-volume hiring.
Build a controlled test dataset. Use at least three test candidates: one clean new application, one duplicate profile scenario, and one case where you manually move a candidate forward and then back into the assessment stage. This last case is the most frequently skipped and the most likely cause of duplicate invitations post-launch.
Run a dry-run and record evidence. Log the number of invitations sent per candidate, the timestamps, and whether any status changes trigger a loop. Screenshot or export the logs before you move on.
Define go-live acceptance criteria. Only approve go-live when all three conditions are met: zero duplicate invitations across all test scenarios, the correct unique assessment URL is generated per candidate, and report write-back appears on the correct ATS profile.
Each scenario below follows the same structure: symptom, cause, fix, and how to verify.
Symptom: A candidate receives two invitations within seconds or minutes of each other, sometimes after a recruiter updates a field on their profile.
Cause: The assessment platform writes a status update (e.g., "invited") back to the ATS. That field update re-triggers the stage-entry rule, sending a second invitation.
Fix: Add a condition to the trigger rule: fire only when the candidate has not previously received an invitation for this job. Alternatively, create a locked intermediate status (e.g., "Assessment sent") that the trigger checks before dispatching.
Verify: Move a test candidate into the assessment stage, then simulate the write-back by manually updating the relevant ATS field. Confirm no second invitation is sent.
Symptom: A recruiter manually sends the assessment invitation at the same time as the automated workflow dispatches it.
Cause: The UI does not show the recruiter that automation has already triggered. Lag in page refresh compounds this.
Fix: Introduce an intermediate "Assessment pending" state that is set the moment the trigger fires. The manual send button should be disabled or hidden while this state is active.
Verify: Trigger the automated dispatch, then immediately attempt a manual send. Confirm only one invitation reaches the test candidate.
Symptom: The same person receives invitations addressed to two different profile records or email addresses.
Cause: A re-application (or an import from a job board) creates a second candidate profile. Both profiles progress through the assessment stage independently.
Fix: Deduplicate and merge candidate records before the assessment stage is reached. Configure the integration to map invitations to the application ID, not just the candidate email, so a single person with two profiles generates only one active invitation per job.
Verify: Create two profile records for the same test candidate and let both reach the assessment stage. Confirm only one invitation is sent.
Symptom: A candidate receives a duplicate invitation 5–30 minutes after the first, with no manual action taken by a recruiter.
Cause: The ATS sent a webhook to the assessment platform but did not receive an acknowledgement in time. It retried. If the assessment platform processed the first call successfully but responded too slowly, both calls created invitations.
Fix: Check the integration logs for retry behaviour. Confirm that the assessment vendor's API returns a 200 acknowledgement within the ATS's timeout window. If not, extend the timeout on the ATS side or implement idempotency keys so duplicate calls are rejected at the vendor end.
Verify: Review logs from the dry-run and confirm only one delivery per trigger event. Ask your assessment vendor whether their API endpoint is idempotent by default.
Symptom: Candidates from different pipeline paths (e.g., direct applicants and referred candidates) both receive invitations, but some receive two.
Cause: Two separate workflow rules both match candidates who enter the assessment stage. One rule may have been set up for a different hiring path and was never restricted to exclude the other.
Fix: Audit all active workflow rules. Ensure rule conditions are mutually exclusive: only one rule should match any given candidate/job combination at a time. Apply "source of application" or "pipeline path" filters to each rule.
Verify: Run one test candidate through each pipeline path and confirm exactly one invitation per candidate.
When a duplicate-invite issue reaches the point of escalation, the quality of information you provide determines how fast it gets resolved.
Gather the following before contacting anyone: the candidate ID and email (anonymised if needed), the job ID, the exact stage name, timestamps of each invitation sent, the number of invitations received by that candidate, any integration logs or webhook delivery records, and a note of any workflow setting changes made in the preceding 48 hours.
Layer 1 (ATS workflow owner): Contact this person first for any trigger rule or stage configuration issue. They can audit workflow rules, conditions, and status mappings.
Layer 2 (Assessment vendor integration support): Contact them for idempotency behaviour, API timeout settings, webhook delivery logs, and report write-back failures.
Layer 3 (IT or implementation partner): Involve this team for custom API or SSO issues, connector middleware configuration, and anything requiring code changes.
Define severity before you escalate so the right people respond at the right speed. Severity 1 applies when duplicate invitations are reaching multiple real candidates in a live environment. Severity 2 applies when duplicates are confined to test cohorts or isolated to a single edge case.
Run this checklist at the end of week one and again at the end of week two:
Platforms such as Selection Lab are designed to support exactly this kind of centralised, ATS-integrated assessment flow, with automated invitations triggering from the ATS stage, the complete report and individual scores visible directly in the ATS, and a documented go-live timeline of 2 to 10 weeks. Post-launch, the adoption support cadence includes bi-weekly check-ins for the first month and quarterly strategic reviews thereafter, which gives implementation teams a structured path to catch any edge-case issues before they affect real candidates.
Getting the integration right the first time is far less costly than repairing candidate trust after duplicate invitations have already landed. Follow the checklist, test the edge cases, and confirm idempotency before you move a single live candidate into the assessment stage.
