Greenhouse Workday integration

What a Greenhouse to Workday integration actually does

Greenhouse runs your hiring: the job, the candidate pipeline, the scorecards, the offer, the moment someone is marked hired. Workday runs your workforce: headcount and position management, the supervisory organization the person joins, their compensation, and the Hire business process that turns a candidate into a paid, provisioned employee.

Between those two systems sits a handoff that most teams still do by hand. A recruiter marks a candidate hired in Greenhouse, then someone re-types the name, start date, offer details, and organization into Workday to kick off onboarding - and separately, someone copies approved requisitions out of Workday into Greenhouse so recruiters have something to source against. A Greenhouse to Workday integration closes both directions: requisitions flow one way, hires flow back, and the two systems agree on who is being hired against which req.

What data moves

Greenhouse object / event	Becomes in Workday	Notes
Job (from a Workday requisition)	Job requisition	Workday originates the req; Greenhouse job carries the requisition ID as the join key
Candidate + application	Pre-Hire / Candidate	Created only at hire; deduplicated against existing and former workers for rehires
Offer (comp, start date, title)	Hire business process inputs	Compensation maps to Workday grade / plan; start date becomes the hire effective date
Department / office	Supervisory organization + location	Rarely a 1:1 map; agreed once and encoded
Job / opening	Position	Under Position Management the hire needs a valid open position, not just a sup org
Hired event (webhook)	Initiate Hire / Pre-Hire	Triggers the Workday business process; still routes through your approvals
Workday worker / pre-hire ID	Written back to Greenhouse	The durable link that keeps re-runs idempotent

The exact requisition, organization, position, and compensation mappings are agreed once with your HR and recruiting teams and encoded in the pipeline. After that, nobody re-keys a new hire.

The details that break naive syncs

A point-to-point script or a generic connector gets a hire from Greenhouse into Workday on a good day and leaves the expensive edge cases to your talent team:

• There is no shared ID. A Greenhouse candidate and a Workday worker have nothing in common until you create the link. The integration has to start the Workday Pre-Hire, capture the returned worker ID, and write it back to Greenhouse - otherwise a retry cheerfully creates a second worker.
• Effective dating. Every Workday transaction is effective-dated. The hire date is the start date on the offer, not the timestamp the sync fired. Get this wrong and payroll, benefits eligibility, and reporting all inherit the wrong date.
• Staffing model. Position Management and Job Management behave differently. Under Position Management a hire needs an open, valid position ID, so the Greenhouse job has to resolve to the right Workday position, not just a supervisory organization.
• Organization mapping. A Greenhouse department or office does not correspond one-to-one to a Workday supervisory organization, cost center, or location. That mapping is a decision, made once, not something a plugin guesses per hire.
• Rehires and duplicates. A returning employee is a rehire in Workday, not a fresh pre-hire. The pipeline has to check for existing and former workers before it creates anyone.
• Partial failure. The Workday Hire is a business process that can validate, route for approval, and sit in progress. Firing the event is not the same as a completed hire, so the pipeline has to track state, surface Workday validation errors, and never assume success from a 200 response.
• Rate limits. The Greenhouse Harvest API and Workday’s web services both throttle. A pipeline paginates, backs off, and retries; a naive loop hits a limit mid-batch and leaves half a day of hires stranded.

How we build and run it

We treat this as a pipeline, not a batch job. Approved Workday requisitions are pulled and pushed into Greenhouse as jobs carrying the requisition ID. Greenhouse hired events arrive by webhook, are validated, matched against existing Workday workers, transformed into your agreed organization, position, and compensation mapping, and used to initiate the Workday Hire or Pre-Hire through Workday’s web services. The returned worker ID is written straight back onto the Greenhouse application.

The pipeline is idempotent: every candidate and requisition carries a stable identifier, and the Workday ID write-back means a retry or a re-run never creates a duplicate worker or a duplicate req. It runs on cloud-native, fully EU-hosted AWS infrastructure, so candidate and employee data never leaves the EU - which keeps your DPA / AVV and your GDPR obligations clean for what is unavoidably sensitive personal data.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Greenhouse Harvest API changes and Workday tenant or WSDL version updates are our responsibility under contract, with a named owner and an SLA. Onboarding stops depending on someone remembering to re-type a new hire.

When this integration is worth building

If you hire a handful of people a month into a single supervisory organization, a recruiter re-keying each one into Workday is genuinely fine, and we will tell you so. The integration earns its place when hiring volume climbs, when you run multiple entities, positions, and cost centers that make the organization mapping non-trivial, when rehires and effective-dating are getting miscoded, or when new hires regularly fail to appear in Workday on their start date because a manual handoff slipped. At that point a managed pipeline that owns the matching, the effective dates, and the write-back pays for itself in hires that just work.