The Zendesk Workday Integration
For an internal helpdesk a Zendesk Workday integration isn't a features project. It's about whether Zendesk knows who each employee is, who they report to, and whether they still work here.
What a Zendesk Workday integration is actually for
The setup is an internal Zendesk instance serving IT, HR, facilities or all three, where every requester is an employee. Workday is the system of record for those employees, which makes it the only place where the answer to "does this person still work here" is reliably correct.
Without a sync, somebody maintains the employee list by hand or by monthly CSV. That list is wrong within a fortnight and badly wrong within a quarter, because people join, leave, change team and change name faster than anyone updates a spreadsheet. So the goal here is narrow. Not features. Accurate people.
The fields worth syncing
What not to sync: compensation, performance ratings, home addresses, anything about health or leave reasons. A Zendesk user sidebar isn't an access-controlled HR record, and tickets get exported. Sync the minimum that changes a support decision, then stop.
Why identity accuracy beats feature depth
Every capability people ask for from an internal helpdesk turns out to rest on the employee record being right.
Routing. A ticket from someone with no department lands in the default queue and waits for a human to work out where it belonged.
Entitlement. Whether this person can request a laptop, a licence or an access change is an org chart question. Wrong org chart, wrong answer, and the agent can't tell.
Approvals. A stale manager field sends the approval to somebody who left in March. It still completes. It just means nothing.
Offboarding. The one with teeth. A leaver whose Zendesk profile is still active can email in and be treated as staff, and their old tickets still route as though they matter.
Reporting. Volume per department is exactly as trustworthy as the department field, which makes it a fiction if the sync is stale.
A helpdesk that does not know who is asking can't route, can't approve and can't report. Everything else is decoration on top of that.
Designing the sync
One direction only
Workday to Zendesk. Nothing in a support tool should ever write back to the HR system of record, no matter how convenient it seems when an agent spots a wrong phone number.
Two cadences, not one
Nightly is fine for attributes like department and title. Joiners and leavers deserve better, because a day of latency on a termination is a day of unwarranted access. Nightly for attributes plus an event-driven path for start and end dates is the pattern that holds up.
Match on employee ID
Store it in the Zendesk external ID field and match on it. Email is a fallback, not a key: people change names, companies change email conventions, domains get rebranded during acquisitions. Never match on display name.
Never hard delete
When somebody leaves, suspend the Zendesk user rather than deleting them. The history stays intact and attributable, and reporting can exclude them with a field. Deleting people to keep the list tidy destroys records you'll want in an audit.
Respect the rate limit
A full sync of a large organisation against the users API will meet the limit and then behave unpredictably. Sync deltas where you can, and use the batch job endpoints for the rest.
You may not want this integration at all
Worth saying plainly, because it saves some teams a project. There is no deep first-party Workday connector for Zendesk. What exists is middleware, identity provider provisioning, or your own service against both APIs.
And in most companies Workday already feeds the identity provider. If your IdP owns the joiner and leaver process, the approvals and the audit trail, provisioning Zendesk users from the IdP reaches the same outcome using machinery somebody already maintains. Adding a second, direct path to the same data is the reliable way to end up with two records per person and no agreement about which is right.
The duplicate identity problem
Four situations produce two Zendesk records for one human, and all four are common. A name change updates the email address, and without a stable external ID the sync creates a new user instead of updating the old one. A contractor converts to permanent employment, gets a new employee ID, and arrives as a stranger. Someone emails the helpdesk from a personal address before their work account exists on their first morning. And an alias or shared team mailbox creates a record nobody intended.
The result is the same each time: a person who can't see their own history, and an agent with no idea the same question was answered last week. Zendesk can merge users, but merges follow the record you keep, so preventing the split beats repairing it. A stable external ID from day one is the prevention.
Frequently asked questions
How do you sync Workday employees to Zendesk?
Through middleware or a scheduled job against both APIs. To sync Workday employees to Zendesk you map employee ID to the Zendesk external ID, which is what makes a Zendesk HR helpdesk integration reliable when people change names or departments.
Is there a native Workday integration for Zendesk?
Not a deep first-party one. Teams use middleware, provisioning through their identity provider, or a custom service calling both APIs.
Should we sync through our identity provider instead?
Usually yes, if the identity provider is already fed by Workday. It reuses an existing joiner and leaver process rather than creating a second one.
How often should employee data sync?
Nightly for attributes such as department and title. Event-driven for joiners and leavers, because a day of delay on a termination is a day of access nobody authorised.
What should the records match on?
The employee ID, stored in the Zendesk external ID field. Email is a fallback only, since it changes with names, policies and acquisitions.
What happens to tickets when someone leaves?
Suspend the user rather than deleting them. The history stays attached and reportable, and the person can no longer raise anything new.
One employee, two profiles, two ticket histories
Split identities are the root of most internal helpdesk duplicates. Ticket Merger spots repeat requests even when they arrive under different records.
Start free trial14-day free trial. No credit card required.