How assessment platforms integrate with Workday, Greenhouse, Lever, and iCIMS

The short answer

Enterprise assessment platform procurement consistently underweights ATS integration evaluation, and consistently produces operational pain in the first six months after platform deployment. The pattern is predictable: the assessment platform's vendor demonstrates integration capability through polished UI flows that look complete, the procurement decision proceeds based on this demonstration, and the operational integration turns out to require substantially more engineering work and ongoing maintenance than the demonstration suggested.

The four major enterprise ATSs — Workday, Greenhouse, Lever, and iCIMS — each have substantially different integration architectures, capabilities, and operational quirks. Workday's integration model is built around tenanted enterprise architecture with deep customisation requirements. Greenhouse has perhaps the cleanest modern integration architecture but with specific opinions about data flow direction. Lever's integration model balances flexibility and structure but requires careful handling of the candidate pipeline state. iCIMS has the broadest enterprise ATS deployment footprint with the longest integration history but also the most operational complexity.

Assessment platforms that integrate well with these ATSs have made specific engineering investments calibrated to each ATS's architecture. Assessment platforms that integrate poorly typically have generic integration approaches that produce friction at each ATS's specific quirks. The buyer's evaluation discipline is identifying which approach the candidate platform takes before procurement decisions, not after.

Why ATS integration is consistently underweighted in procurement

Three patterns produce the underweighting. Each reflects a different misunderstanding of what ATS integration actually involves.

Pattern 1: Treating ATS integration as a technical implementation detail. Many procurement processes treat integration as work that the assessment platform's vendor will handle through their professional services team after the platform is selected. The structural problem: this treats integration as commodity engineering work that any vendor can deliver, when actually the depth of integration capability varies dramatically across vendors. The vendor with strong integration capability delivers operational integration in weeks; the vendor with weak integration capability delivers technically-functional integration that requires ongoing engineering maintenance to keep operational.

Pattern 2: Underestimating the data model translation work required. Each ATS has its own data model — how it represents candidates, jobs, application stages, assessment results, hiring decisions. Assessment platforms have their own data models that don't always align with the ATS's model. The integration work involves not just connecting the systems but translating between data models in ways that preserve data fidelity and operational meaning. This translation work is invisible in vendor demonstrations but operationally substantial.

Pattern 3: Discovering integration limitations only during peak operational load. Like execution engines, ATS integrations often work adequately under modest load and reveal limitations under peak conditions — campus hiring drives, mid-cycle hiring spikes, certification windows. The integration that worked fine for 50 candidates per day may fail in subtle ways when 500 candidates per day flow through the same integration pathway. Discovering these limitations during active hiring is operationally expensive.

The honest framing: ATS integration determines whether the assessment platform is operationally usable as part of the enterprise hiring stack, or whether it produces operational friction that consumes engineering capacity to maintain. The evaluation discipline upfront is dramatically less expensive than retrospective discovery of integration limitations.

What ATS integration actually involves

Worth being explicit about what integration actually consists of, because the term gets used to describe substantially different work.

Authentication and identity management. The integration needs to handle authentication between the assessment platform and the ATS — single sign-on for recruiter access, identity federation for organisational users, role-based access control alignment between the systems. Strong integrations handle this through standards-based identity protocols (SAML, OIDC); weak integrations use proprietary authentication that creates maintenance overhead.

Job and requisition synchronisation. The ATS owns the source of truth for open positions and their attributes — title, level, requirements, hiring manager, location, status. The assessment platform needs to receive this data to configure assessments for specific positions. Strong integrations handle bidirectional synchronisation with explicit conflict resolution; weak integrations push data in one direction and accumulate drift over time.

Candidate data synchronisation. Candidates enter through the ATS and need to be associated with assessment workflows. The integration needs to handle candidate creation, updates, association with specific jobs, and lifecycle management. Strong integrations maintain candidate state consistency across both systems; weak integrations produce candidate records that diverge between systems and require manual reconciliation.

Application stage and pipeline progression. As candidates move through hiring stages, the integration needs to handle stage transitions consistently — moving from screening to assessment to interview to offer. Each ATS has its own pipeline model, and the assessment platform needs to align with each. Strong integrations handle stage transitions with explicit validation; weak integrations let stage transitions happen out of order or with missing required data.

Assessment delivery and results return. The core integration loop: the ATS triggers an assessment for a candidate, the assessment platform delivers the assessment, the results return to the ATS for hiring decision-making. Strong integrations handle this loop reliably under load; weak integrations have race conditions, lost results, and timing issues that produce operational friction.

Reporting and analytics integration. Hiring metrics live across both systems. The integration needs to surface assessment data into ATS reporting and ATS data into assessment platform analytics. Strong integrations align reporting models; weak integrations require manual data extraction and reconciliation to produce hiring funnel reports.

Audit trail and compliance. Regulated industries require comprehensive audit trails across the hiring stack. The integration needs to maintain audit data consistency across both systems. Strong integrations produce audit trails that hold up under compliance review; weak integrations have audit gaps that surface during regulatory audit.

Webhooks and event-driven workflows. Modern integrations use webhook patterns for real-time event notification — candidate state changes, assessment completion, hiring decisions. Strong integrations use webhook patterns reliably with retry logic and idempotency; weak integrations rely on polling that produces latency and reliability issues.

The depth of integration across these dimensions varies dramatically between assessment platforms. Vendor demonstrations typically cover the visible dimensions (delivery and results return, basic candidate synchronisation) but rarely reveal the deeper dimensions (audit trail consistency, peak-load behaviour, edge case handling).

How Workday integration actually works

Workday is the dominant enterprise HCM platform for large organisations, with its own opinionated integration architecture.

The integration patterns that matter:

Workday Web Services (WWS) and Workday Studio. Workday's primary integration interface is its REST-based Web Services. Modern Workday integrations use REST endpoints for most operations, though some legacy integrations still use SOAP. The assessment platform needs to handle WWS authentication and endpoint patterns.

Tenanted integration architecture. Each Workday customer has their own tenant with specific configuration, customisations, and data model variations. The assessment platform's Workday integration cannot be a single generic implementation — it needs to handle tenant-specific configuration variations. Strong assessment platforms have configurable integration capabilities that adapt to each customer's Workday tenant; weak platforms have generic integrations that work for some customers and break for others.

Workday Recruiting object model. Workday Recruiting has specific objects for candidates, applications, requisitions, hiring teams, and stages. The integration needs to handle these objects with their Workday-specific attribute names, relationships, and behaviour. Strong integrations align with Workday's object model semantics; weak integrations make assumptions that don't match Workday's actual behaviour.

Bidirectional sync requirements. Workday customers typically expect bidirectional synchronisation — candidate data flowing both directions, requisition updates synchronising both ways, status changes maintaining consistency. The integration needs to handle bidirectional sync with conflict resolution. Strong integrations have explicit conflict resolution rules; weak integrations produce data inconsistencies that accumulate over time.

Tenant URL patterns and environment management. Workday customers have tenant-specific URLs and typically multiple environments (production, implementation, test). The integration needs to handle these environment patterns cleanly. Strong integrations support environment configuration explicitly; weak integrations hardcode assumptions that break in non-production environments.

Authentication via Integration System Users (ISUs). Workday integrations typically authenticate through dedicated Integration System Users with specific permissions configured by the customer. The integration setup involves coordinating with the customer's Workday administrators to configure these users with appropriate permissions. Strong integrations document this setup clearly; weak integrations leave it to vendor-customer back-and-forth that delays deployment.

Customer-specific report and data export usage. Some Workday integration patterns use Workday's report and data export capabilities for bulk data operations. The integration may need to coordinate with custom reports the customer has built in their tenant. Strong integrations handle custom report integration cleanly; weak integrations require ongoing customer-side maintenance to keep operational.

The Workday integration is operationally heavier than other ATS integrations because of the tenanted architecture and customisation patterns. Assessment platforms that handle this well have made specific Workday-focused engineering investment; platforms that handle it weakly have generic enterprise integration that fits Workday awkwardly.

How Greenhouse integration actually works

Greenhouse is the modern enterprise ATS that has perhaps the cleanest integration architecture of the four. The integration patterns are well-documented, modern, and reflect contemporary API design.

The integration patterns that matter:

Harvest API and Job Board API. Greenhouse exposes two primary APIs — Harvest for the recruiter and ATS data, Job Board for candidate-facing functionality. Most assessment platform integrations use Harvest API for the integration loop. Strong integrations handle Harvest API endpoints comprehensively; weak integrations support only a subset that leaves operational gaps.

Webhook-driven event model. Greenhouse uses webhook patterns for event notification — candidate stage changes, application updates, status transitions. Strong assessment platform integrations subscribe to relevant webhooks and process events idempotently; weak integrations either don't use webhooks (relying on polling) or process webhooks without proper idempotency that produces duplicate operations.

Candidate and application data model. Greenhouse has a clean candidate-application data model that distinguishes between the candidate entity (the person) and the application entity (their submission for a specific role). The integration needs to handle this distinction consistently. Strong integrations preserve the model; weak integrations conflate candidate and application that produces data integrity issues.

Stage configuration and custom fields. Greenhouse customers configure their own pipeline stages and custom fields. The integration needs to respect customer-specific configuration. Strong integrations adapt to custom field configurations; weak integrations make assumptions about field names that break for customers with custom configurations.

Take-home test and assessment workflow. Greenhouse has explicit take-home test and test workflow concepts that assessment platforms integrate into. Strong integrations use these explicit workflow concepts; weak integrations use generic interview stages that don't surface assessment-specific operational features.

Job stages and interview kit integration. Greenhouse's interview kit concept supports structured interview configuration. Strong assessment platform integrations align with interview kit patterns; weak integrations create parallel workflow structures that don't coexist cleanly with native Greenhouse features.

Permissions and role management. Greenhouse has fine-grained permission models. The integration needs to respect customer-specific permissions configurations. Strong integrations handle permission contexts; weak integrations operate with broad permissions that produce security and operational issues.

API rate limits and batch operations. Greenhouse's Harvest API has rate limits that affect integration architecture. Strong integrations respect rate limits with appropriate throttling and batch operations; weak integrations hit rate limits that produce intermittent failures during peak periods.

Greenhouse integrations are typically the cleanest to implement because of the modern API architecture. The differentiation between strong and weak assessment platform integrations is less about handling Greenhouse complexity (which is lower than Workday) and more about how comprehensively the integration uses Greenhouse's capabilities.

How Lever integration actually works

Lever is the enterprise ATS that occupies the middle ground between Greenhouse's modern simplicity and Workday's enterprise complexity. Lever's integration architecture reflects this positioning.

The integration patterns that matter:

Lever API v1 and webhook patterns. Lever exposes a REST API that's modern but with specific opinions about data flow. The API and webhook patterns together support most integration scenarios. Strong integrations handle both API operations and webhook events; weak integrations rely on API polling that produces latency.

Posting and opportunity model. Lever has a posting-opportunity model that distinguishes between job postings (the public-facing role) and opportunities (specific candidate consideration for a posting). The integration needs to handle both objects appropriately. Strong integrations preserve this distinction; weak integrations conflate them in ways that produce operational confusion.

Pipeline state model. Lever has an explicit pipeline state model with stages, archive states, and snooze states. The integration needs to handle state transitions cleanly. Strong integrations align with Lever's pipeline model; weak integrations create parallel state tracking that diverges from Lever's source of truth.

Stage form configuration. Lever supports custom stage forms for capturing specific data at each pipeline stage. Strong integrations support stage form configuration in assessment-related stages; weak integrations bypass stage forms in ways that lose operational data.

Candidate notes and feedback integration. Lever's candidate notes and feedback infrastructure is central to its hiring workflow. Strong assessment platform integrations surface assessment results into Lever's feedback infrastructure; weak integrations leave assessment results in the assessment platform that recruiters need to context-switch to find.

Calendar and interview scheduling integration. Lever has integrated interview scheduling that the assessment platform may need to coordinate with for interview-style assessments. Strong integrations handle this coordination; weak integrations create parallel scheduling that produces double-booking and confusion.

API rate limits and operational patterns. Lever's API rate limits are different from Greenhouse's, and the integration architecture needs to respect them. Strong integrations handle Lever-specific rate limits; weak integrations apply generic rate limit handling that doesn't match Lever's actual constraints.

Lever integration depth varies meaningfully across assessment platforms. Some platforms have invested specifically in Lever integration and produce smooth operational experience; others have generic integration that works adequately but produces friction at Lever-specific patterns.

How iCIMS integration actually works

iCIMS has the broadest enterprise ATS deployment footprint with the longest integration history. The integration architecture reflects this — comprehensive but operationally complex, with multiple integration patterns reflecting different generations of integration architecture.

The integration patterns that matter:

iCIMS UNIFi platform and REST APIs. iCIMS has invested in modern REST APIs through their UNIFi platform. Modern integrations use these REST endpoints. Some legacy iCIMS integrations still use older SOAP-based interfaces. Strong assessment platform integrations use modern REST patterns; weak integrations may use legacy patterns that work but are operationally heavy.

Multi-tenant deployment patterns. Like Workday, iCIMS customers have tenant-specific configurations. The integration needs to handle tenant-specific patterns. Strong integrations have configurable tenant support; weak integrations make generic assumptions.

Candidate and application data model. iCIMS has a comprehensive candidate-application data model with specific behaviours around merging duplicate candidates, application source tracking, and pipeline state. Strong integrations handle these patterns; weak integrations produce duplicate candidates or lose source attribution.

Workflow and approval integration. iCIMS supports custom workflows with approval steps. The integration needs to respect customer workflow configurations. Strong integrations align with custom workflows; weak integrations create parallel workflow paths that confuse recruiters.

Multi-environment and deployment lifecycle. iCIMS customers typically have production and staging environments with specific deployment patterns. The integration needs to support these patterns cleanly. Strong integrations handle multi-environment deployment; weak integrations hardcode production assumptions.

Permissions and role-based access. iCIMS has fine-grained permission models. The integration needs to respect customer permission configurations. Strong integrations handle permission contexts; weak integrations operate with permissions that produce security issues.

Reporting integration through iCIMS Insights. iCIMS Insights is the reporting infrastructure that customers use for hiring analytics. Strong assessment platform integrations surface data into Insights; weak integrations produce reporting fragmentation.

Historical integration patterns and backwards compatibility. Because iCIMS has the longest enterprise deployment history, customers may have integrations built across multiple generations of iCIMS architecture. Strong assessment platform integrations handle backwards compatibility; weak integrations require customers to update their integration architecture before deployment.

iCIMS integration depth is the most variable across assessment platforms. The ATS's deployment history and architectural complexity mean that integrates with iCIMS can mean substantially different things for different vendors. Verification is particularly important for iCIMS integrations.

How to actually evaluate ATS integration during platform selection

A framework worth working through:

1. Document your specific ATS configuration and integration requirements before vendor evaluation. Each enterprise ATS deployment is unique. Document your specific tenant configuration, custom workflows, permission models, integration patterns, and operational requirements. Vendor evaluation against generic ATS capability doesn't reveal whether the vendor handles your specific configuration.

2. Verify integration depth across the dimensions covered above. Don't accept we integrate with [ATS name] as sufficient answer. Verify authentication patterns, data model handling, pipeline state management, webhook usage, audit trail consistency, and peak-load behaviour specifically. The depth varies dramatically across vendors.

3. Engage in customer reference conversations focused on integration operational experience. Standard vendor references discuss overall platform satisfaction. Integration-focused references discuss what the integration actually does in production, how it handles edge cases, what operational maintenance is required, and what surprises emerged during deployment.

4. Test the integration with your actual ATS configuration during evaluation. Some assessment vendors support hands-on integration testing during procurement evaluation. This produces dramatically more accurate signal than vendor demonstrations on the vendor's own test instances. If hands-on testing isn't available, the vendor's integration may be less mature than they claim.

5. Verify the integration documentation depth. Strong integrations have comprehensive customer-facing documentation — setup guides, troubleshooting documentation, edge case coverage, operational best practices. Weak integrations have thin documentation that leaves operational gaps for customer engineering teams to fill.

6. Assess the integration roadmap and ongoing investment. ATS platforms evolve. Strong assessment vendors have specific roadmaps for integration evolution as the ATSs change. Weak vendors stop investing in integrations after initial implementation, letting them degrade as the ATSs evolve.

7. Verify the support model for integration issues. When integration issues emerge in production, who handles them? Strong vendors have dedicated integration support with clear SLAs. Weak vendors treat integration issues as general support cases that take weeks to resolve.

8. Calibrate the evaluation across the multi-ATS landscape. Many enterprise organisations use multiple ATSs — different business units, different geographies, different legacy deployments. Strong assessment platforms handle multiple ATS integrations cleanly; weak platforms force standardisation on one ATS that may not match organisational reality.

Where Skolarli's infrastructure fits this evaluation discipline

Skolarli's coding assessment infrastructure and hiring platform integrate with major enterprise ATSs through dedicated integration architecture. Specifically:

1. Workday integration: Configurable integration that adapts to tenant-specific Workday configurations, with bidirectional sync and standard Workday Web Services patterns.
2. Greenhouse integration: Uses Greenhouse's Harvest API and webhook patterns for clean modern integration that aligns with Greenhouse's data model and workflow concepts.
3. Lever integration: Aligned with Lever's posting-opportunity model and pipeline state architecture, with explicit handling of Lever's stage forms and feedback infrastructure.
4. iCIMS integration: Uses iCIMS's modern UNIFi REST architecture with tenant configuration support and permission alignment.

Beyond these four enterprise ATSs, Skolarli supports integration with the broader ATS landscape through 31+ integrations across HRIS systems, identity providers, communication platforms, and other hiring stack components.

The integration depth across each ATS reflects deliberate engineering investment in handling each ATS's specific architecture rather than generic enterprise integration patterns. For organisations evaluating Skolarli's integration capability against their specific ATS configuration, hands-on integration testing during evaluation is available.

For hiring teams evaluating any assessment platform's ATS integration capability, the evaluation discipline above applies regardless of vendor. The vendors with strong integration capability can support detailed integration verification; the vendors with weak integration capability resist detailed verification.

About this piece

This post is part of the Engineering Hiring at Scale series — an analytical series from Skolarli Akademy Research covering the technical and operational disciplines for engineering hiring at scale in the AI era.

Skolarli Akademy Research is the editorial arm of Skolarli Edulabs Pvt. Ltd., publishing analysis on learning, hiring, and assessment infrastructure. Findings are reviewed by Skolarli's founders and product leaders before publication.

Reviewed by Jayalekshmy Nair, Co-founder & CEO, Skolarli.