Recruitment and Job Board Connector

The copy-paste tax on hiring

Zoho Recruit holds the job opening, the pipeline and the candidate database. The applicants, however, arrive from somewhere else — regional job boards, a university careers portal, a government employment exchange, a professional association listing, a recruitment agency's feed, a WhatsApp or email inbox.

So a recruiter opens a job in Recruit, then retypes the title, description, location, salary band and requirements into each board's posting form, one at a time. Applications come back as email attachments or board-portal notifications. Each CV is downloaded, opened, and its contents keyed into a new candidate record — name, phone, email, current employer, notice period, expected salary — before it can be screened. A week later the same opening needs its posting refreshed on three boards and expired on a fourth, and nobody is quite sure where it is still live.

The cost is not only time. Duplicate candidate records accumulate because the same person applied through two boards under two email addresses. Source attribution is unreliable, so nobody can say which board actually produces hires. And the delay between application and first contact is measured in days, which loses candidates in a competitive market.

ECOSIRE builds the connector layer that removes that retyping in both directions.

What ECOSIRE builds

Outbound publishing from Zoho Recruit

We build a publishing engine driven from the Job Opening record in Zoho Recruit. When an opening reaches the status you nominate, a Deluge workflow assembles a board-specific payload from the Recruit fields — title, department, location, employment type, experience band, salary range, description and requirements — applies per-board formatting rules such as character limits, plain-text versus HTML bodies, and the board's own category and location taxonomies, then submits it through that board's published API, XML or JSON feed, or its accepted email-submission channel.

Each board gets its own adapter with its own field mapping and its own credentials, so adding a board later means adding an adapter rather than rebuilding the engine. A posting register on the opening records where it went live, the external posting reference, the publish timestamp, the expiry date and the current status. Updates to the opening republish or patch the live posting; closing or filling the opening expires it everywhere, so a filled role stops attracting applications.

Where a board offers no machine interface at all, we say so at scoping and build a prepared-payload view instead: the copy is generated and formatted correctly, and the recruiter pastes once rather than composing from scratch. We do not claim an integration that the board does not permit.

Inbound applicant capture

Applications are collected from every channel you use: board API or webhook callbacks where offered, a monitored applications mailbox parsed for CV attachments and structured board notification emails, a scheduled feed pull, and your own careers page form. Each inbound item is stored with its raw source — original email, original attachment, board reference — before parsing, so nothing is lost to a parsing error.

Resume parsing into candidate records

Parsed CVs create or update Zoho Recruit Candidate records using Recruit's own resume-parsing capability, extended with Deluge post-processing for the fields your team actually screens on: contact details, current and previous employers with dates, total and relevant experience, education and certifications, skills matched against your own skill taxonomy, current and expected salary, notice period, location and willingness to relocate, work authorisation and languages. Attachments are stored on the candidate record in their original form.

Parsed values that fall below a confidence threshold are flagged for review rather than written silently, and the source CV is shown side by side so a recruiter corrects a field in seconds instead of re-keying the record.

De-duplication and source attribution

Before a new candidate is created, the engine checks existing records on email, normalised phone number, and a name plus employer or date-of-birth combination, then either merges into the existing candidate as a new application or creates a fresh record. Where a duplicate is genuinely ambiguous, it goes to a review queue instead of being merged automatically.

Every application carries its true source — which board, which campaign, which referrer — through to the Recruit Candidate and the associated Job Opening, so board-level reporting on applications, shortlists, interviews and hires becomes real rather than estimated.

Workflow, screening and communication

New applicants are associated with the correct Job Opening, placed at the right pipeline stage, and assigned to the owning recruiter or hiring manager by your routing rules. Knock-out screening questions can auto-reject or auto-shortlist against explicit criteria you define — location, work authorisation, minimum experience, mandatory certification — with the rule recorded on the record so any decision is explainable.

Acknowledgement emails go out on receipt, and status-change communications fire from Recruit templates through Zoho Flow, so candidates are not left silent. Where you use Zoho People, we build the hire handoff: an accepted offer creates the employee record and pre-boarding tasks without re-entry.

Monitoring

A dashboard shows live postings by board with expiry dates, applications received per board and per opening, parse success and review rates, duplicate merge counts, and time from application to first recruiter action. Flow alerts fire on adapter failures, expiring credentials, a posting that failed to publish, and a mailbox backlog that is not being processed.

Who this is for

In-house talent teams hiring at volume in markets where the dominant boards are regional rather than global; staffing and recruitment agencies managing many concurrent openings across several boards; manufacturing, healthcare, hospitality and BPO employers with continuous frontline hiring; and any Zoho Recruit user whose recruiters currently retype the same opening into several portals and re-key CVs by hand.

How delivery works

1. Scoping call. We list the boards and channels you post to, confirm what machine interface each one offers and what its terms permit, review your Recruit field set, pipeline stages, screening criteria and Zoho editions, and take sample CVs in the formats you actually receive.

2. Fixed quote. A written scope naming each board adapter, the inbound channels, the parsing field set, de-duplication rules and the workflow automations, with a fixed price and delivery date. Nothing begins until you approve.

3. Build. We develop the publishing engine, per-board adapters, inbound collectors, parsing post-processor, de-duplication logic and Flow automations, testing against your sample CVs and board sandbox or test accounts where available.

4. Install in test. Deployed into a test Recruit environment; we publish real openings to board test endpoints, run a batch of real CVs through parsing, and tune field mappings, confidence thresholds and de-duplication rules with your recruiters until the output is accepted.

5. Production. Installed in your live Zoho org with board credentials configured, then the first live openings published and the first days of applications monitored alongside your team.

6. Support. A defined support window covering defect fixes, board field-mapping changes and parsing adjustments, extendable as you add boards.

Typical lead time is one working week from approved quote, driven mainly by how many board adapters are in scope and how each board exposes its interface.