Applicant Tracking Systems

Applicant Tracking System (ATS) and Customer Relationship Management (CRM) Integration Guide

Integration Overview

Contingent work businesses depend on a variety of workflow processes beyond those that Wingspan performs. Examples include:

  • Recruiting: Finding contingent workers
  • Customer Relationships: Establishing and managing client relationships
  • Assignment Management: Day-to-day management of client deliverables
  • Financials and Reporting: Accounting for the business' operations

As a result of Wingspan's role in the technology stack, it needs to receive inputs from the systems that manage these processes to be effective. For example, when a candidate is hired in an Applicant Tracking System (ATS), this should lead to the candidate going through the Wingspan Onboarding process to add them to the contingent worker pool.

Through Wingspan's powerful Data Exchange capabilities, integrations are possible to any external system that can export or import data programmatically. These integrations allow for the automation of processes that are triggered by external systems, and also for Wingspan to pass data back to external systems.

Challenges Identified

System Fragmentation: Contingent work businesses need purpose-built tooling in order to operate their businesses, including systems like Wingspan and in addition to other systems like ATS and CRM. When these components of the stack are not connected, it creates expensive and error-prone manual processes.

Data Transformations: Each system in the stack has its unique way of working. From specific workflow steps, to how data is collected and stored, there is variation in implementation based on specific use-case and other preferences. Integrations between systems must be powerful enough to bring systems together and flexible enough to accommodate differences in implementation. Deep integrations without flexibility result in poor integrations that become a drag for businesses.

Reliability and Audibility: Integrations that connect two systems are often subject to reliability issues because the execution of the integration falls between two different systems.. When mission critical integrations fail, those failures can be difficult to identify, debug, and resolve. And as companies' technical landscapes evolve, integrations need to be adjusted or enhanced. For all of these reasons, integrations must be transparent and auditable so that they can be monitored and maintained.

Wingspan Data Exchange

Wingspan takes a new approach for offering integrations into complex ecosystems: Wingspan's Data Exchange is engineered to aggregate data types from different upstream systems. The data undergoes a rigorous process of formatting, standardization, and transformation, ensuring data uniformity. Once processed, the data is integrated into Wingspan's Data Warehouse, laying a robust foundation for advanced analytics and functions.

For the inbound direction, Wingspan's API layer operationalizes this data into key objects, e.g. Contractors, Payables (Contractor Payments), Invoices (Client Bills), etc.

The Data Exchange also works in the opposite direction, allowing Wingspan data to be pushed back into upstream systems (e.g., updates to Customer Relationship Records) or into downstream systems for further processing (Reporting or Accounting Systems).

Integration Process

Connecting an Inbound Datasource

Wingspan offers hundreds of out-of-the-box integrations with external systems through its native connector infrastructure built on top of Airbyte and Zapier. This allows for one click integration into supported systems. Our most common integrations include:

  • Bullhorn
  • Quickbooks Online
  • Recruiter Flow
  • Salesforce
  • Zoho CRM & Recruit

For systems where Wingspan does not have a native integration, the Wingspan Data Exchange offers a framework for quickly building a custom connector to any external system that can support pragmatic Read / Write capabilities.

Once the connection is complete, the data comes over to Wingspan's Data Warehouse as a mirror copy of what's in the source system. It's this mirror copy that can be then audited for consistency on a regular basis programmatically, and as necessary manually to debug issues with the data sync.

ATS Example

If we were mapping data from an ATS (like Bullhorn), we would generally sync the data from the Candidate Entity -- this contains information like:

  • Email Address: Where Wingspan would send the onboarding invitation
  • Candidate Information: Personal information about the candidate that can be pre-populated
  • Custom Fields: Data stored in the ATS that impact the contingent worker in Wingspan
  • Candidate Status: Current candidate status to initiate Wingspan workflow steps

Because of the flexibility of the Data Exchange framework, any other entities can also be brought in as needed (e.g., Placements).

Mapping Data Elements

Once the data lands in the Wingspan Data Warehouse, it is mapped to Wingspan Fields on top of the Bulk Operations APIs, with triggers depending on the contents of the data. The triggers active actions, which transform the data elements based on the configured mapping, and the actions push the data into the Wingspan API.

ATS Example

Continuing from the ATS example above, the data is pushed into the Data Warehouse is then mapped into new Contractor Batch Items.

These items are pushed into the Wingspan API, the batch is processed, and the contractor records are created in the Wingspan Platform.

This initiates the flow of inviting contractors to the Wingspan platform -- once they complete their eligibility requirements, they're ready to work and get paid.

Returning Data to the ATS or CRM

The ATS or CRM system may then be used to manage the work of the individual (e.g., the projects or assignments they are on). Therefore, it's important that statuses in Wingspan are pushed back upstream to those systems, so they know when the new candidate, now on-boarded contractor, is ready to accept work.

In this case, the Data Exchange process works in reverse: the data to be pushed is staged in the Wingspan Data Warehouse, a mapping from the Wingspan data fields to the target destination API or programmatic feed-format is created, and the data is synced back.

Wingspan uses a variety of different tools for this "reverse-ETL" process, depending on the capabilities of the destination system.

Integration Timeline

The integration timeline of an external data source and destination can vary depending on the availability of out-of-the-box connectors, whether the integration is unidirectional or bidirectional, and on the complexity of the mappings involved. In general, the full processes can take between 1-3 weeks including configuration and testing.

MilestoneDescriptionTiming
ScopingCreate a requirement doc for the integration.1-2 Days
Configure the Data ConnectorsSet up the inbound and outbound data connectors as needed. Time varies depending on the availability of an out-of-the-box connector.1-2 Weeks
Create the MappingsMap the newly connected data to Wingspan API Data Elements1-2 Days
TestingPerform User Acceptance Testing on the new integration to ensure it conforms with the requirements.< 1 Week