Skip to main content

​
Implementation Overview

Implementation Type: Kombo-based Integration
Note Format: Plain Text
Status: Production Ready

​
Configuration

​
Feature Summary

Kombo-based integration with selective implementation. Some features partially implemented or pending.

Streaming Operations

​
Stream Jobs

Status: Supported (Custom Implementation)
Method: _get_specific_ats_jobs_batch(limit, include_closed, cursor)Uses custom batch fetching via Crelate passthrough API to retrieve jobs with custom field values and pagination support.

​
Stream Applications

Status: Supported (Custom Implementation with Limitations)
Method: _stream_applications(updated_after, for_job_ids)Crelate’s updated_after parameter doesn’t work correctly in their API, so the implementation ignores it and uses a custom filtering strategy:
  1. Process applications in START stage (new applicants)
  2. Process applications already tracked in our system (to sync updates)
  3. Skip applications in later stages that we’ve never seen before
This ensures we capture new applications while avoiding duplicate processing of applications that moved through stages before we started tracking them.

​
Stream Candidates

Status: Supported (Custom Candidate-Only Boundary) Method: _stream_candidates(updated_after)Candidate streaming uses Kombo for normalized candidate data, then validates native Crelate RecordType metadata in batches through the passthrough API before ingestion. A contact is eligible when its RecordType is null or 0 (Crelate allows a contact to have no type), or when it has the candidate bit and no sales/client, lead, or employee bits. Contacts that are classified as a sales/client contact, lead, or employee are excluded, even when they also have the candidate bit. A non-zero type with no candidate bit (for example time-approver only) is also excluded. A row that omits RecordType entirely still fails the batch. Crelate candidate status and pool membership do not affect this boundary, so candidates from every pool remain eligible.Crelate’s list endpoint can omit contacts that Kombo still streams (typically deleted or stale IDs). When the returned IDs are a subset of the requested IDs, the rest of the batch continues. Each omitted ID is confirmed with GET /contacts/{id}: a 404 skips that contact, a 200 uses the confirmed row, and any other outcome fails the batch. Duplicate rows or unexpected extra IDs also fail the batch. Malformed metadata or an unavailable Crelate response after retries still fails the affected batch. The same boundary is applied when sync workers fetch candidates by ID for candidate, applicant, and tearsheet processing.

​
Move to Stage

Status: Supported (Inherited)
Method: _move_application_to_stage(application, stage)Moves applications between stages using Kombo’s unified API. Implementation inherited from BaseKomboAtsClient and functional for Crelate, though not extensively tested across all stage transitions.

​
Get Rejection Reasons

Status: Not SupportedMethod: get_disposition_reasons()The Crelate client returns an empty list of rejection reasons. Its inherited capability flag remains enabled for compatibility with existing routing.

​
Reject Application

Status: Not SupportedMethod: reject_application(application_id, reason_id)The current rejection method does not write to Crelate because it cannot yet resolve the native application ID required by the rejection endpoint. This no-op does not produce a thumbs rejection note.

​
Bulk Reject Applications

Status: Not SupportedMethod: bulk_reject_applications(application_ids, reason_id)Bulk application rejection is not implemented.

​
Create Application

Status: Supported (Inherited)
Method: _create_application_for_candidate(candidate, job)Creates new application records for candidates in Crelate via Kombo. Some Crelate-specific application fields may not be populated.

​
Get All Application Stages

Status: Supported (Inherited)
Method: _get_all_application_stages()Fetches all available application stages from Crelate through Kombo.
  • Get Job by ID (Supported - Custom Implementation)
  • Get Enhanced Job (Supported - Custom Implementation)
  • Batch Job Operations (Supported - Custom Implementation)
Strong job management implementation with custom field support.

​
Get Candidate by ID

Status: Supported (Inherited)
Method: _get_candidate_by_id(candidate_id)Retrieves candidate information from Crelate via Kombo.

​
Find Candidates by Details

Status: Supported (Inherited)
Method: _find_candidates_by_details(first_name, last_name, email, phone)Searches for candidates by name, email, or phone number through Kombo.

​
Get Resume

Status: Supported (Inherited)
Method: _get_resume_for_candidate_id(candidate_id)Retrieves candidate resume data through Kombo. Functionality inherited from BaseKomboAtsClient and expected to work with Crelate, though not extensively verified.

​
Candidate Status in Rules of Engagement

Status: Supported for Workforce Field: Crelate Candidate StatusWorkforce candidate synchronization retrieves each contact’s native Crelate status and stores it as a single-select candidate attribute. The live Crelate status names are available in Admin → Rules of Engagement → Create Filter, where an admin can choose Include or Exclude and select the desired values.No status filter or status selection is created automatically. The existing Require filters setting determines whether recruiters must retain the organization’s filter or may edit it as a default. A contact’s Crelate status does not affect candidate ingestion or pool availability. Contacts with no Crelate status do not match a selected status exclusion.When Workforce configures Crelate Candidate Status with the Exclude operator, matching active applications move to Outreach ineligible so pending outreach stops. Terminal outcomes and applications already blocked for consent are preserved. If the candidate’s status or the organization filter later changes, only applications parked by this Crelate rule can return to outreach, and only after the normal outreach eligibility checks pass.

​
Add Note to Application

Status: Supported (Custom Implementation)
Method: _add_note_to_application(application, note, note_action_type)Adds plain text notes to applications using Crelate’s passthrough API.

​
Add Note to Candidate

Status: Supported (Custom Implementation)
Method: _add_note_to_candidate(candidate, note, note_action_type)Adds plain text notes to candidate records using Crelate’s passthrough API.

​
Add Attachment to Application

Status: Not Implemented
Method: Inherits NotImplementedError from BaseKomboAtsClientFile attachment functionality for applications is not yet implemented. Attachments cannot be uploaded to applications in Crelate through this integration.

​
Add Attachment to Candidate

Status: Not Implemented
Method: Inherits NotImplementedError from BaseKomboAtsClientFile attachment functionality for candidates is not yet implemented. Attachments cannot be uploaded to candidates in Crelate through this integration.

​
Application Custom Fields

Status: Not Supported (Crelate API Limitation)
Methods: Inherits NotImplementedError from BaseKomboAtsClientCrelate’s API does not support application-level custom fields in a way that’s accessible through Kombo. Attempts to query application custom field schemas return errors from Crelate’s API. This is a limitation of Crelate’s system architecture, not our implementation.

​
Candidate Custom Fields

Status: Supported (Custom Implementation)
Methods:
  • _get_candidate_custom_fields() - Retrieves custom field definitions
  • _update_candidate_custom_fields(candidate, updates) - Updates custom field values
Full support for getting and updating candidate custom fields through Crelate’s passthrough API.

​
Job Custom Fields

Status: Supported (Custom Implementation)
Methods:
  • _get_job_custom_fields() - Retrieves custom field definitions
  • _get_job_custom_field_values(job_id) - Gets custom field values
  • _update_job_custom_fields(job, updates) - Updates custom field values
Comprehensive job custom field support using Crelate’s passthrough API.

​
Implementation Notes

​
Field Naming Convention

Crelate uses capital 'Id' instead of lowercase 'id' for remote IDs. The client sets remote_id_field_name = "Id" to handle this.

​
Custom Job Fetching

Uses _get_specific_ats_jobs_batch() to fetch jobs via Crelate’s passthrough API with enhanced data including:
  • Custom field values
  • Job-specific metadata
  • Pagination support

​
Note Implementation

Custom implementation for adding notes to both applications and candidates using Crelate’s passthrough API.

​
Implementation Progress

Current implementation highlights:
  • Job management is well supported.
  • Candidate streaming and candidate custom fields are supported.
  • Attachments and application custom fields remain unavailable.

​
Implementation Notes

​
Application Streaming Workaround

Crelate’s API has a bug where the updated_after parameter doesn’t work correctly. Our implementation works around this by fetching all applications and using intelligent filtering to avoid duplicates while capturing new applicants.

​
Field Naming Convention

Crelate uses capital 'Id' instead of lowercase 'id' for remote IDs. The client sets remote_id_field_name = "Id" to handle this consistently.

​
Custom Job Fetching

Uses _get_specific_ats_jobs_batch() to fetch jobs via Crelate’s passthrough API with enhanced data including custom field values and pagination support.

​
Known Limitations

The following features are not yet available for Crelate:
  • File Attachments: Cannot upload files to applications or candidates.
  • Application Custom Fields: Crelate’s API doesn’t support this feature.
  • Implementation: server/ats/crelate/crelate_ats_client.py
  • Models: server/ats/crelate/crelate_models.py
  • Checklist: server/ats/crelate/COMPLETE_CRELATE_IMPLEMENTATION_CHECKLIST.md
  • Field Mappings: server/ats/field_type_mapper.py (CRELATE_FIELD_MAPPINGS)
  • Base Class: server/ats/base_kombo_ats_client.py

​
See Also