Assessment platforms that don't integrate tightly with your ATS create manual overhead at exactly the wrong moment, when a recruiter is managing 50+ active applications and needs status updates, scores, and rejection decisions to flow automatically. This reference document covers how Selection Lab integrations with Emply, Jobylon, and Salesforce work at a systems level. What triggers an invitation, what gets returned after a candidate completes an assessment, and how rejection outcomes map back to ATS statuses.

Three distinct events drive every integration.

1. Invitation trigger (incoming to Selection Lab). The ATS detects a pipeline stage change or webhook event and instructs Selection Lab to send an assessment invite to the candidate.
2. Completion callback (outgoing from Selection Lab). When a candidate finishes (or declines/expires), Selection Lab pushes result artifacts back to the ATS record.
3. Outcome/rejection mapping (decisioning layer). The ATS applies a configured rule to translate a Selection Lab result status into the correct ATS candidate status, including rejection messaging.

Understanding which layer a problem belongs to is the fastest way to isolate configuration errors. For the same pattern in Recruitee and SmartRecruiters, see ATS status mapping for assessment results.

Terminology used throughout this document

Emply assessment integration: invitation fields and trigger mechanism

Fields sent to Selection Lab on invite

When an Emply candidate moves to a pipeline stage configured to trigger a Selection Lab assessment, Emply sends a structured payload to the Selection Lab webhook endpoint. The fields that should be present in a correctly configured Emply integration are listed below. Fields marked [TBD] require verification against your specific Emply setup, since Emply's public help documentation does not publish the full payload schema.

What happens when optional fields are missing. If locale is absent, Selection Lab defaults to the language configured in the assessment profile. If phone is absent and the invite channel is set to WhatsApp, the invite fails silently unless a fallback channel (email) is configured. Verify fallback behavior with your Selection Lab account configuration.

Configuration steps for Emply invite triggers

The trigger mechanism for Emply integrations operates via a webhook or connector sync (exact mechanism [TBD], confirm whether your Emply instance uses webhook push or a polling-based connector). The configuration path is as follows.

1. In your Emply admin, navigate to the integration/connector settings for your assessment vendor.
2. Select the pipeline stage that should trigger an invite (e.g., "Assessment Stage").
3. Map that stage to the Selection Lab webhook endpoint and provide the API credentials (Bearer token or OAuth client credentials, depending on your Selection Lab tenant configuration).
4. Select the assessment profile to assign to candidates entering that stage. If your vacancy-to-profile mapping is dynamic, confirm whether Emply passes the requisition_id so Selection Lab can resolve the correct profile automatically.
5. Confirm consent workflow settings. If Emply collects candidate consent to share data with third-party processors before the application reaches the assessment stage, pass the consent flag in the payload. If not, Selection Lab initiates its own consent request before sharing results back.

Auth failure mode. If the API credential is expired or misconfigured, Emply will receive an HTTP 4xx response. Depending on your connector configuration, this may silently drop the invite or queue it for retry. Check your integration logs in both Emply and the Selection Lab admin panel to confirm delivery.

Retry behavior for failed deliveries is [TBD], confirm retry count, backoff interval, and dead-letter behavior with your Selection Lab integration engineer.

Emply integration: what gets returned after assessment completion

Once a candidate completes (or exits) the Selection Lab assessment, Selection Lab sends a completion callback to Emply. The callback payload contains the following artifact types.

Completion status values

Score and report fields

Consent and privacy logic

Selection Lab's privacy model requires that results are shown to the candidate first. Consent is then requested a second time before results are shared back to the ATS. This means that if a candidate completes the assessment but has not yet given post-assessment consent to share results, the report_url and component_scores fields in the callback payload may be withheld or returned as null until consent is recorded. Personal data is stored in Frankfurt in compliance with EU data residency requirements.

The exact Emply implementation of this consent gate (whether it blocks the callback entirely or sends a partial payload with a consent_pending flag) is [TBD], confirm with your Selection Lab account manager.

Emply status mapping and rejection handling

Decision outcome mapping table

The exact Emply stage/status string values are picklist-defined in your Emply configuration. The mapping must be set up in the Selection Lab integration settings to match those exact string values. A mismatch (e.g., "Rejected" vs. "rejected" vs. "REJECTED") will cause the callback to fail silently or return a 422 error.

Rejection messaging channels

On a rejection outcome, Selection Lab can trigger a rejection message to the candidate via two channels.

• Email, an automated email using the configured rejection template
• WhatsApp, a rejection message through Selection Lab's SmartChat flow, if the candidate was onboarded via WhatsApp intake and a phone number is present

The timing (immediate vs. delayed) and exact template variables are [TBD], confirm rejection message templates and channel priority logic with your Selection Lab account configuration.

Sample webhook payloads

Invite trigger payload (Emply to Selection Lab)

{
  "event": "assessment.invite",
  "application_id": "APP-00123",
  "candidate_id": "CAND-78901",
  "requisition_id": "REQ-456",
  "first_name": "Jane",
  "last_name": "Smith",
  "email": "[email protected]",
  "phone": "+31612345678",
  "locale": "nl",
  "consent_flag": true
}

Completion callback payload (Selection Lab to Emply)

{
  "event": "assessment.completed",
  "application_id": "APP-00123",
  "candidate_id": "CAND-78901",
  "completion_status": "completed",
  "match_score": 74,
  "component_scores": {
    "cognitive": 68,
    "personality": 81,
    "hard_skills": 72
  },
  "report_url": "https://app.selectionlab.com/reports/APP-00123",
  "report_available": true,
  "completed_at": "2026-08-30T09:14:22Z"
}

Note that field names and the presence of component_scores keys depend on your active assessment profile. The above is illustrative; confirm the exact schema with your Selection Lab integration spec sheet.

Troubleshooting Emply-specific issues

• Status enum mismatch. If Selection Lab returns a status value that doesn't match an Emply picklist option exactly, the update will fail. Export your Emply pipeline status list and verify each string against the mapping table in your Selection Lab admin.
• Missing application_id. Without the correlation key, Selection Lab cannot identify which Emply record to update. Check the connector config to confirm Emply is passing this field on every invite event.
• Consent-blocked result delivery. If a candidate completed the assessment but results aren't appearing in Emply, check whether post-assessment consent is pending. The Selection Lab admin panel shows consent status per candidate.
• Auth expiry. Rotate API credentials and update them in both the Emply connector and the Selection Lab integration settings simultaneously.

Jobylon assessment integration: pipeline actions and invite triggers

Jobylon's integration model for assessment partners is documented via its Pipeline Actions framework. According to Jobylon's support documentation (January 27, 2026), partner integrations are configured at the pipeline status level. Navigate to Pipeline Actions, create an action next to the status you want to automate, choose "Partner Integrations" as the action type, select your assessment vendor, and save. With that setup, an assessment test is automatically sent when a candidate moves to the selected status.

This means the Jobylon assessment integration is event-driven by status change, not by manual recruiter action. No separate webhook configuration is required on the recruiter side beyond the Pipeline Actions setup. The invite is dispatched as soon as the ATS records the status transition.

Selection Lab fits directly into this model. When a candidate enters the configured pipeline status, Selection Lab receives the invite event and delivers the assessment invitation. Recruiters can view the complete report and individual scores within the Jobylon candidate record once results are returned.

What Jobylon's public docs don't cover

The Jobylon support article on partner integrations does not publish the following.

• Granular invite payload schemas (which candidate fields are transmitted to the partner)
• Exact result/status field names returned from the partner
• Rejection messaging channel logic (email vs. WhatsApp vs. ATS-only)
• Score-threshold-based status movement configuration for the return path

These details are [TBD], request the Selection Lab + Jobylon integration spec from your Selection Lab account manager, or review the Jobylon admin under Settings > Integrations for field-level detail.

For the return path (results back into Jobylon), the same general completion callback pattern applies as described in the Emply section. Completion status, match score, component scores, and report URL are pushed back to the candidate record. Jobylon's pipeline can then be configured to move candidates automatically based on score thresholds using its native score-based automation feature.

Salesforce assessment integration: object mapping and status constraints

Salesforce's data model for recruiting (whether native Salesforce Recruiting or a managed package like Salesforce for Recruiting) uses strongly typed picklist fields on objects such as Application, Assessment, or custom staging objects. This imposes stricter constraints on result mapping than Emply or Jobylon.

How completion artifacts map to Salesforce objects

Selection Lab's Salesforce integration pushes completion artifacts to a designated object (typically a custom Assessment__c or equivalent object, or an existing Application/Candidate Stage object, depending on your Salesforce org configuration). The fields populated are conceptually the same as in the Emply return payload. Completion status, scores, report URL, and timestamp. However, the exact API field names and object targets depend on your Salesforce org schema.

Key constraint. Any status field mapped from a Selection Lab completion status must correspond to an active picklist value in your Salesforce org. If completed_with_low_score is not a valid picklist entry in your Application_Status__c field, the update will fail with a Salesforce validation error.

Rejection mapping as a translation layer

For Salesforce, rejection mapping is a two-step translation.

1. Selection Lab outputs a canonical completion status (e.g., completed, declined, expired) plus a pass/fail determination based on score thresholds.
2. The integration layer (either a Salesforce Flow, Apex trigger, or the Selection Lab connector) translates that canonical status into the Salesforce picklist value configured for rejection (e.g., "Rejected - Assessment", "No Longer in Consideration").

If your org uses Salesforce Experience Cloud and candidates access assessments through a portal, external user permissions for the relevant objects must be configured to allow status reads and report URL access. This is a common source of "results not visible" tickets in Salesforce-integrated deployments.

For candidate rejection status mapping with automatically triggered invitations in Salesforce, the pattern mirrors the Emply approach. A configured threshold fires the rejection status update, and the messaging channel (email, WhatsApp) is driven by candidate contact data and Selection Lab template configuration.

Cross-ATS decision matrix: mapping outcomes consistently

Regardless of which ATS you're using, the mapping logic should normalize Selection Lab's canonical statuses before writing to ATS-specific enums. The following matrix applies across Emply, Jobylon, and Salesforce.

The principle behind this matrix is normalize first, then map. Your ATS-specific picklist values should never be hardcoded directly in the integration callback logic. Maintain a mapping table in your integration configuration layer that translates Selection Lab's canonical statuses to your ATS strings. That way, if Emply renames a pipeline status, you update the mapping table once rather than changing the integration logic.

Setup checklist and troubleshooting

Pre-flight checklist

• Correlation keys confirmed, application_id and candidate_id are present in every invite payload
• Assessment profile selected and mapped to the correct requisition/job type
• Webhook endpoint registered and auth credentials active (test with a ping/health check call)
• Consent workflow confirmed, determine whether pre-collection by Emply is sufficient or whether Selection Lab's post-assessment consent gate applies
• ATS picklist values exported and verified against Selection Lab's status mapping table
• Rejection messaging templates reviewed and approved (channel, timing, variables)
• Fallback channel configured for candidates without a phone number (WhatsApp flow requires E.164 phone)

Invite troubleshooting

Completion/result troubleshooting

Operational monitoring

Configure logging at three points. (1) The ATS connector/webhook dispatch log to confirm invite events fired, (2) the Selection Lab admin event log to confirm invites were received and delivered, and (3) the ATS update log to confirm completion callbacks were applied. For Salesforce, Apex debug logs or Platform Event logs give the most granular visibility.

Reconciliation. Run a weekly report comparing candidates in the "Assessment Stage" status with candidates who have a completed Selection Lab result. Any gap indicates an invite delivery failure or a consent-blocked result. Most ATS platforms support this as a simple pipeline filter; Selection Lab's reporting panel provides a matching export.

For persistent delivery failures, request an audit trail export from Selection Lab that includes event timestamps, HTTP response codes, and any retry attempts. This is the fastest path to diagnosing whether a failure is on the ATS connector side or within Selection Lab's delivery pipeline. Want to see the integration with your ATS? Book a demo.

Frequently asked questions