Beyond Boomi: When a UKG Pro Integration Needs to Be Real-Time

Most UKG Pro integrations are born in a spreadsheet: a list of interfaces, each with a source, a target, a file format, and a schedule. The delivery toolchain behind that list — typically Dell Boomi under the hood — is genuinely good at what it was designed for: scheduled, file-shaped data movement. Payroll exports, benefits carrier feeds, GL summaries. If your requirement fits that shape, use the standard pattern and spend your money elsewhere.

But some requirements don’t fit that shape, and forcing them into it is where integration projects quietly go wrong.

The batch-shaped hole

Here’s a test I use with clients: what is the cost of your data being four hours old?

For a benefits carrier feed, the answer is “nothing.” For these scenarios, the answer is real money or real risk:

• Punch-driven downstream behavior. A point-of-sale system that should only allow an employee to log in when they’re clocked in. A production system that assigns work based on who’s actually on the floor. Four-hour-old punch data means the control simply doesn’t work.
• Same-day pay and earnings visibility. Tip allocations, earned-wage access, daily labor cost tracking — anything where an employee or manager looks at a number today that depends on transactions from this morning.
• Cross-system workflows. An approval in one system that should release a transaction in another. Batch windows turn a thirty-second workflow into a next-day workflow.

If none of your requirements look like this, stop reading and enjoy your batch files. If one does, the standard interface catalog was never going to solve it — no matter how many change orders you attach to it.

What real-time actually means against UKG

“Real-time” gets thrown around loosely, so let’s be concrete. Against the UKG Pro WFM API surface you have three escalating options:

1. Fast polling with change detection. Query the API on a short interval, track a watermark, process only deltas. Unglamorous, universally available, and often entirely sufficient. Done well — with proper watermark handling and backoff — this gets you to minutes of latency without any exotic infrastructure.
2. Webhooks / event subscriptions. Where UKG emits events for the data you care about, subscribe and react. This gets latency to seconds, but it changes your reliability burden: you now need a receiver that’s always up, and a strategy for the events you didn’t receive.
3. Change-data-capture on the data platform side. For analytics-shaped consumers, streaming changes out of the data layer rather than hammering the application APIs.

The right answer is frequently a hybrid: events where they exist, polling as a safety net, and reconciliation to catch what both missed.

The parts nobody quotes you

The API calls are the easy 20%. What makes a real-time UKG integration production-grade is everything around them:

• Idempotency. Events arrive twice. Polls overlap. If your writes to UKG (or from it) aren’t idempotent, you will double-post a paycode edit at the worst possible moment. Tag what you write and check before you write it again.
• Retry with classification. A 429 is not a 400 is not a 500. Retry the transient, quarantine the poisonous, and never let one bad record stall the queue behind it.
• A dead-letter story. Where does a failed record go, who sees it, and how is it replayed? “It’s in the logs” is not an answer a payroll manager can act on.
• Observability. The difference between finding out at 9 a.m. from your dashboard and finding out at month-end from payroll is the entire value of the system.

This is also why “we’ll just have our Boomi developer poll faster” underdelivers: the tooling can technically make the calls, but the operational architecture around continuous data movement is a different discipline than scheduled file transfer.

A working example, generalized

One deployment I built for a global retail operator moves point-of-sale transactions and UKG punch data through an event-driven pipeline that calculates variable pay continuously during the day. Managers review and approve in a purpose-built app; only approved amounts sync onward to payroll — idempotently, with a full audit trail. The batch predecessor it replaced ran overnight and made every correction a next-day event. The event-driven version made the same process same-hour, and — more importantly — made errors visible while they were still cheap to fix.

Nothing in that system modifies UKG. It’s all supported APIs, webhooks, and disciplined engineering on infrastructure the client owns.

How to evaluate your own case

Ask three questions:

1. What is the real cost of latency, in dollars or risk? (If you can’t name one, batch is fine.)
2. Does the data you need exist on the UKG API surface at the freshness you need?
3. Who will operate this? Real-time systems need monitoring, not babysitting — but they need someone to own the pager.

If you have crisp answers to the first two and a plan for the third, the build is very achievable — typically weeks, not quarters, for a first production flow.

---

Have a scenario that doesn’t fit the batch shape? Tell me about it — I’ll give you a straight answer on whether it’s buildable.