I'm Matthew Hurley. I diagnose and rebuild the broken Workday integrations that get left behind after Go-Live — the ones your team is quietly correcting by hand every week — then hand that team the documentation and training to own the fix without me.
Workday Pro certified, Integration Services. Workday integrations since 2016 — higher ed, federal, healthcare, and Fortune 500 environments.
When an implementation partner exits, your team is left holding a system they didn't build and can't reliably predict. The friction gets absorbed into the routine — manual corrections, recurring errors, workarounds that quietly became standard procedure. None of it shows up on a budget line, but you are already paying for it in salaried hours every single week.
A benefits administrator or registrar spending hours — sometimes an entire day every week — correcting data an integration was supposed to deliver correctly the first time.
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."
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 it all lives in one person's head.
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.
New vendor integrations, benefits carrier feeds, and reporting requests sitting in a queue nobody has touched in months — because the team is fully consumed putting out fires.
When the busywork outlives the implementation, people start blaming the platform — and someone starts pricing a replacement or an expensive AMS contract. Usually the platform was never the problem.
If two or three of these describe your month, this isn't a discipline problem on your team. It's a build problem, and build problems are fixable. Let's spend 30 minutes on yours.
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, and growing companies — are left with integrations that technically "work" but don't solve the problem that mattered. Often alongside a backlog of "non-critical" items nobody has the bandwidth to touch.
I work in exactly that gap. Workday integrations since 2016, across HCM, Benefits, Payroll, Absence, Talent, Time Tracking, Student, and Recruiting — 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.
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.
The best solution to an integration problem is usually the one that already worked somewhere else. I'll tell you when the 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.
A clear-eyed audit of your integration environment, scored on five things: failure rates, the labor cost being quietly absorbed, 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 resulting plan whether your team executes it or you bring me in to.
$15,000 — fixed feeBuilding or rebuilding integrations that solve the actual business problem — not the version of it that was easiest to implement. Most failures I find trace back to a requirement that was misunderstood at build time, not to a Workday limitation. Every engagement ends with documentation, training, and knowledge transfer.
Scoped per engagementFor 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.
Monthly retainerThe most expensive integration problems aren't the ones that fail loudly. They're the ones that quietly become part of someone's job description. Client names are withheld; the numbers are not.
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 team had internalized this as normal. The integration existed, the errors felt manageable, and there was no obvious project to fix it — just a standing cost in hours that never made it onto a budget line. In real terms it 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 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. No amount of faster manual cleanup would have fixed that.
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.
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 was resting on a manual estimate. That is a compliance problem, not an inconvenience. 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.
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.
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.
I'm a solo Workday integration consultant. 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.
My background is unusual for a developer: my degrees are in visual design, which means I approach problems differently. Before writing a line of code, I ask whether the problem has been correctly identified. Some of my most valuable work has been recognizing that the integration wasn't the real issue — and saving a client from paying for the wrong fix.
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 don't optimize for indispensability. Every engagement ends with your team more capable of running their own environment than when I arrived.
Integrations Services earned 2025
Full module breadth since 2016
Complex orgs, lean IT teams, proprietary software
Master of Fine Art in Visualization from Texas A&M University
5 years active duty during OIF/OEF
Every engagement gets readable documentation
Thirty minutes is usually enough to tell whether I can help and what the path forward looks like. Bring the integration that's bothering you most. No pitch, no deck — just an honest read on your situation, and if it isn't something I should take on, I'll tell you that on the call.
Prefer to write first? matthew@matthewhurleyconsulting.com · Or call (979) 224-2298
Nothing on fire today? Fair enough. Connect with me on LinkedIn and I'll be easy to find on the day one of these does catch fire.