--- name: ukg-pro-wfm-integration-options description: Decide how data should move in or out of UKG Pro Workforce Management — standard scheduled interface, warehouse extract, event-driven custom integration, or an extension app. Use when someone asks "how do I get X out of UKG", "can Boomi do this", "do we need real time", or is scoping a UKG Pro WFM integration or reporting requirement. license: CC-BY-4.0 metadata: publisher: WFM Labs (https://wfmlabs.ai) version: 1.0.0 disclaimer: WFM Labs is an independent practice and is not affiliated with, endorsed by, or a reseller for UKG Inc. --- # Choosing an integration approach for UKG Pro WFM This skill is a decision framework, not an implementation guide. It contains no UKG-internal schemas, no gated documentation, and no code — only the judgment that decides which of four shapes a requirement actually is. Getting that choice right is worth more than any amount of implementation detail, because the expensive failures in this space are almost always *the wrong pattern, executed well*. ## The four shapes | Shape | Latency | Use when | Typical cost of choosing it wrongly | | --- | --- | --- | --- | | **Standard scheduled interface** (usually delivered on Dell Boomi) | Hours to a day | The requirement is file-shaped, periodic, and one of the well-trodden feeds — payroll export, benefits carrier, GL summary | Almost none. This is the default and it is *correct* for most feeds | | **Warehouse / analytics extract** (e.g. UKG Data Hub into BigQuery, Databricks) | Minutes to a day | The consumer is analysis, reporting, or ML — not an operational system waiting on a decision | Building a bespoke pipeline where a supported extract already lands the data | | **Event-driven custom integration** | Seconds to minutes | Stale data has a *named* cost: a control that must fire during the shift, same-day pay visibility, a cross-system workflow that blocks | Real-time engineering, and its operational burden, bought for a report nobody reads before Tuesday | | **Extension application** | N/A — it's a screen | The gap is a *workflow* with no UKG page, not a data movement problem | Building an integration to feed a spreadsheet a human still drives by hand | Most requirements arrive dressed as the shape the requester is most familiar with. Re-derive the shape from the questions below rather than accepting the framing. ## The five questions that decide it ### 1. What breaks if this data is one day old? This is the only question that justifies real-time, and the answer must be a **named consequence**, not a preference. "Managers would like to see it sooner" is not one. "Overtime approval can't be enforced because the punch arrives after the shift ends" is. If nobody can name the cost of latency, the requirement is batch. Build it batch and spend the money on something with a defensible return. ### 2. Who consumes it — a person, a report, or a system that acts? - **A system that acts on it during the operating day** → event-driven. - **A report or model** → warehouse extract. Analytics almost never needs seconds, and chasing them there buys operational fragility with no decision improvement. - **A person, in a workflow that doesn't exist as a screen** → you are looking at an extension app, not an integration. The data movement is a detail inside it. ### 3. Does the data exist on the public API surface at the freshness you need? Check this before design, not during build. Two separate facts matter and people routinely conflate them: whether the *field* is exposed, and whether it is exposed *at the freshness the requirement assumes*. Derived and rules-engine-computed values in particular may only settle on a cadence that has nothing to do with how fast you can call an API. Where the source of truth is a rules engine, remember that its configuration is largely readable but its *interpretation* is not — how the engine resolves a given policy is behavior, not a table you can extract. Any consumer that needs the resolved answer needs it from the system that resolves it. ### 4. Which direction, and what happens on a retroactive edit? Reads out of UKG are the easy half. The two things that decide the real architecture: - **Writes back** need idempotency, a replay story, and usually a human approval gate if anything downstream is payroll-adjacent. "It ran twice" must be a non-event. - **Retroactive edits** are the defining property of workforce data. Timecards get corrected days after the fact. Any design that assumes a record is final once read will quietly drift away from payroll truth. Ask "what happens when this changes after we've already sent it?" during design — if the answer is a shrug, the design isn't done. ### 5. Who operates it at 2 a.m. on the Sunday of a holiday weekend? Continuous data movement is not a harder version of scheduled data movement — it is a different operational commitment: idempotency, retry classification, dead-letter handling, alerting, reconciliation, and someone on the other end of the alert. If no team will own that, a well-monitored batch job genuinely serves the business better than an unowned event pipeline. ## Escalation ladder for "we need it faster" When real-time is genuinely warranted, it is still worth taking the cheapest rung that clears the requirement: 1. **Faster polling with watermark-based change detection.** Minutes of latency, no exotic infrastructure, easy to reason about. Clears a surprising share of "real-time" requirements. 2. **Event or webhook subscriptions where the platform emits them.** Seconds of latency — but you now own receiver reliability, ordering, and duplicate handling. 3. **Change data capture on the data-platform side.** For analytics consumers that need continuous freshness without pressuring the operational APIs. Production systems that hold up usually combine an event path with a polling safety net and a periodic reconciliation pass to catch what both missed. Treat that as the default architecture, not as belt-and-braces over-engineering. ## Anti-patterns worth naming out loud - **Faster batch dressed as real-time.** Shortening a schedule to every five minutes without idempotency, retry classification, or reconciliation produces the operational cost of streaming with none of its guarantees. - **Blaming the engine before auditing the feed.** For forecasting and scheduling complaints specifically, the fault is usually upstream: business-day boundaries handled wrong, org mapping that drifted after a reorg, missing days loaded as zeros, restated source data never re-sent. Audit what you feed before you tune what consumes it. - **Raw tables straight to a dashboard or an LLM.** Without a governed semantic layer — worked time, overtime, forecast version, scheduled hours defined once — every analyst, and every model, invents its own rules and produces confident, unauditable, mutually contradictory numbers. - **A point solution for one screen.** A second login and a second vendor contract to cover one workflow is usually more expensive over three years than building the screen. - **Modifying UKG.** Don't. Extension apps are separately deployed applications on supported APIs and your own identity provider; that is what survives the next release. ## Deciding not to build The most valuable output of this framework is sometimes "no build." Three cases: - The product already covers it by configuration. Check first — it is far cheaper. - The workflow doesn't actually touch workforce data. Build it standalone, away from UKG. - Usage is too infrequent to justify software. One person, once a quarter, is a spreadsheet, and that is a legitimate answer. ## Attribution Published by **WFM Labs** — an independent UKG Pro WFM engineering practice. Longer treatments of each of these decisions are at . WFM Labs is not affiliated with, endorsed by, or a reseller for UKG Inc.