Workday Integration Consultant | Post-Go-Live Repair & Recovery

Does This Sound Familiar?

Go-Live was supposed to be the finish line.

When an implementation partner exits, your team inherits a system they didn't build and can't reliably predict. The friction gets absorbed into the routine: manual corrections, recurring errors, workarounds that slowly became standard procedure. None of it shows up on a budget line. You're paying for it anyway, in salaried hours, every week.

"We're still doing this manually?"

A benefits administrator or registrar spending hours (sometimes a whole day every week) correcting data an integration was supposed to get right the first time.

Break-fixes that don't hold

A fix works this run and fails the next. Nobody can say why, so the same error comes back on the same feed month after month and gets logged as "known."

Nothing you can actually read

Maybe your partner left a design document that explains nothing useful. Maybe they left nothing at all. Either way, every troubleshooting session starts from zero, and everything anyone knows lives in one person's head.

"Not critical for Go-Live"

Some integrations got deferred to get you live. A year later they're still unbuilt, and data is still being pulled from the legacy systems Workday was bought to replace.

A backlog that keeps growing

New vendor integrations, benefits carrier feeds, and reporting requests sitting in a queue nobody has touched in months, because the team is busy putting out fires.

"Maybe Workday was the wrong call"

When the busywork outlives the implementation, the functional team starts developing superstitions about what Workday can and can't do. A rift of suspicion opens between the people who configure the system and the people who build its integrations, and eventually someone starts pricing a replacement. Usually the platform was never the problem.

Nobody went into HR to re-key leave records every Friday. That kind of busywork is demeaning, and it's avoidable. If two or three of these describe your month, the problem is almost certainly in the build, not in your people, and builds can be fixed. Let's spend 30 minutes on yours.

Who I Work With

Organizations still recovering from Go-Live

Large system integrators are built for enterprise-scale rollouts. When the implementation closes and that team moves on, small-to-midsize organizations (universities, healthcare and insurance providers, government agencies, growing companies) are left with integrations that technically "work" but don't solve the problem that mattered, along with a backlog of "non-critical" items nobody has the bandwidth to touch.

I work in that gap. Workday integrations since 2016, across HCM, Benefits, Payroll, Absence, Talent, Time Tracking, Student, and Recruiting. That's enough range to step into a struggling environment, find what's actually broken underneath the symptoms, and rebuild it in a way your team can maintain after I leave.

The goal isn't to make myself indispensable. It's to make myself unnecessary. Your team should own this environment and succeed in it without me.

A note on fit: if you're pre-Go-Live, or your implementation partner is still under contract and on the hook, I'm probably not your best call yet. That's a different kind of help, and I'll say so on the phone. This work starts once the partner is gone and the problems are yours.

I work best with

HRIS Directors running Workday without a dedicated integration developer
Technical leads who inherited integrations they didn't build and can't fully explain
Benefits and HR leaders whose team has a standing weekly appointment with a spreadsheet
Executives who want the labor lost to broken feeds identified and quantified in dollars
Organizations a year past launch with a growing backlog of unbuilt or broken feeds
CTOs who need integration problems off their plate so the team can do strategic work
Higher education, healthcare, and government: complex requirements, lean IT teams

Not everything on this list is on fire, and it doesn't have to be. Some of the best engagements start with "nothing's technically broken, but nobody here can explain how any of it works." That's a good reason to talk early, before it becomes an emergency.

How I Help

Clear solutions. No unnecessary complexity.

The best solution to an integration problem is usually the one that already worked somewhere else. I'll tell you when a novel approach is right, and when it's a red herring. Most engagements start with the Assessment, because it's hard to prioritize a fix before you know what the damage actually costs.

Integration Assessment

A clear-eyed audit of your integration environment, scored on five things: failure rates, the labor cost your team has been absorbing, integrations doing work they were never meant to do, documentation quality, and how much your functional and technical teams still trust each other. You keep the plan, whether your team executes it or you bring me in to.

$15,000 · fixed fee

Failure rates across your Workday integration ecosystem
Recurring errors traced to root cause, not just catalogued
Manual rework quantified in hours and dollars
Documentation and knowledge-transfer gaps identified by name
Prioritized recommendations with realistic scope and effort estimates

Integration Development & Repair

An integration can fail in two different ways. It can be badly built, or it can be built well to do the wrong thing. The second kind is more common, more expensive, and much harder to see from the inside. I build and rebuild integrations around the business problem you actually have, and every engagement ends with documentation, training, and knowledge transfer.

Scoped per engagement

EIB, Studio, Core Connector, Orchestrate, Document Transforms
Benefits carrier feeds, vendor sync, and more
Root cause first, not symptom patches
Plain-language documentation your team can actually use
Training so your team owns it when I leave
Stable, maintainable solutions instead of clever ones

Ongoing Advisory & Training

For teams that want to build internal capability and get ahead of the backlog instead of reacting to it, including teams whose integrations aren't failing yet but who have no one in-house who could explain them. I can do the work, teach your developer to do it, or ride along while they drive. (I'm a reasonably polite backseat driver.)

Monthly retainer

Troubleshooting methodology and best practices
Developer coaching and skills transfer
Integration governance and documentation standards
Backlog prioritization and planning support
Proactive review of upcoming Workday releases

Real Examples

What a root-cause rebuild is actually worth

The most expensive integration problems don't fail loudly. They settle into someone's job description and stay there. Client names are withheld here, but the numbers are real.

Leave Administration: Vendor Feed Rebuild

Medical insurance provider. Their leave administration integration technically ran, but didn't reliably update leave requests and events in Workday. Error volume was high enough that the Benefits team reserved most of every Friday to review and manually correct that week's leave status changes.

The integration ran every night. So yes, technically, it worked. But the Benefits team learned something very different: Friday belonged to the spreadsheet. In real terms, that habit was consuming one full benefits administrator plus roughly half of a benefits analyst, an estimated $50,000 to $100,000 a year in labor, before counting the payroll corrections and the FMLA and state-leave compliance exposure that bad leave data creates.

I rebuilt it in Workday Studio against the root cause: the original never accounted for the fact that it was mapping a transactional data feed into a state-machine model. You can't fix a build problem with a sufficiently diligent person.

A full day every week became a roughly five-minute check each morning. Because the review went daily, error volume stayed low too. Payroll accuracy improved, the compliance exposure went away, and the team got documentation they can follow when questions come up.

FMLA Hours-Worked: Eligibility Source Integration Rebuild

University. The integration feeding hours-worked data to their leave vendor was calculating wrong numbers for effectively every employee. The vendor couldn't determine FMLA eligibility from the file, so they called the benefits administrator and had her estimate it by hand, on every single request.

Every FMLA determination the institution made rested on a manual estimate. That's a compliance problem, and a serious one. The root cause was straightforward once someone actually looked: the original build never accounted for three distinct payroll populations that each needed different calculation logic.

I rebuilt the hours-worked logic with population-specific algorithms and validated it over three weeks alongside their Payroll and Time & Absence teams.

Manual estimation stopped, and the vendor calls stopped with it. FMLA determinations became accurate and defensible. The institution's own rough estimate put the eliminated manual effort near $30,000 a year. They hadn't been tracking it, which is its own part of the story.

Student Admissions: Inbound Applications Integration Rebuild

University. Their applicant loader produced hundreds of duplicate-student and duplicate-SSN errors per run and took three to four hours to finish. Eventually the team concluded it was easier to key the data in by hand than to correct what the integration created, and shut the whole suite of integrations off.

That decision put enrollment readiness at risk and dropped daily manual correction on the Registrar's Office. The root cause was brittle XML-based processing with no intelligent matching and no duplicate-detection guardrails: a clever shortcut at build time that nobody could troubleshoot afterward.

I rebuilt it on CSV processing with HashMap-based matching, plus soft-match logic that flags near-duplicates for a human instead of guessing.

Runtime went from four-plus hours to ten minutes, and duplicate creation stopped. The Registrar's Office got its day back, historical student records were properly linked, and the team left with plain-language documentation and training instead of another black box.

The questions I ask first

What was this integration supposed to make possible for someone?
Who is correcting its output by hand, and how often?
Is it badly built, or well built to do the wrong thing?
Does it need to send anything back at all?
When it fails, who finds out, and how?

Whatever is failing in your tenant, the honest first question is whether the original build understood the requirement. That's usually a 30-minute conversation, not a proposal.

Schedule a 30-Minute Call

About

Matthew Hurley

Fair warning: I have a habit of saying things the long way. The short version is that I fix Workday integrations, and then I make sure your team can keep them fixed without me.

I've been building and repairing Workday integrations since 2016, across HCM, Benefits, Payroll, Absence, Talent, Time Tracking, Recruiting, and Student, inside a 24-campus university system, a national research laboratory, federal agencies, and Fortune 500 companies. I've owned environments of 150+ integrations, run tenant and payroll migrations, and done post-implementation recovery for organizations that went live and then found themselves largely on their own.

I learned to write software so I could get an art degree. I'm not a "real" developer in the computer-science sense, and that turns out to be useful: designers are trained to ask whether we're solving the right problem before we solve it. Sometimes the most valuable thing I bring to a project is one question. On one rebuild, it was "Why are we sending anything back to this system at all?" Nobody had a good answer, so we stopped sending it.

I prefer boring, proven solutions over clever ones, because someone on your team has to troubleshoot this at 6am two years from now, and it probably won't be me. I work alone, so the buck stops with me. If you need a status update, there's one person to call, and he knows where everything is. Every engagement ends with your team more capable of running their own environment than when I arrived.

Certified Workday Pro

Integrations Services earned 2025

150+ Integrations Owned

Full module breadth since 2016

Higher Ed, Gov't & Healthcare

Complex orgs, lean IT teams, proprietary software

Design Background

Master of Fine Art in Visualization from Texas A&M University

USMC Veteran

5 years active duty during OIF/OEF

Plain-Language Docs

Every engagement gets readable documentation

Somebody on payroll is doing the integration's job.
I put the work back where it belongs.