A multi-location restaurant group moved scheduling to a specialist platform while keeping UKG WFM for time and payroll. Connecting the two was the easy part. The real design question was what the time clock does when a manager approves a cover after the last sync and the replacement is standing there ready to work.
Operations picked the scheduling platform, on operational grounds, and the job that landed with HRIS and IT was not to relitigate it. It was to route the operative schedule to the time clocks already on the wall without touching payroll.
A multi-location restaurant group in the US did exactly that. It runs UKG WFM for time and payroll with CloudApper hrPad on the floor, and moved its scheduling work to a specialist third-party platform. Connecting the two is the least interesting part. The design question worth writing down is narrower.
Everything Turns on What Happens Between Syncs
Punch rules at these clocks are schedule-aware. A common one: no clock-in more than fifteen minutes before the scheduled start. That rule is only as good as the schedule the clock is reading.
Now consider a real shift. Someone calls out at 3:40. A manager approves a cover at 3:52. The replacement arrives at 4:05 for a 4:15 start and puts a hand on the clock. If the terminal still holds the schedule as it stood at the last sync, that person is not on it, and a rule meant to prevent early clock-ins refuses somebody standing there ready to work.
That is the whole problem. Not the connection. The window between a change and a punch.
“Every schedule change we make is late by definition. If it were not late we would have put it in the schedule.”
Director of Operations, multi-location restaurant group
The design problem is not the connection. It is the window between a manager approving a cover and the replacement putting a hand on the clock.
Two Levers, and Neither Is the Connection Itself
The first is sync cadence. Schedule data flows from the scheduling platform into CloudApper hrPad on a configurable interval, and the useful work was tuning that interval against when changes actually cluster rather than picking a round number. Here they bunch in the hours before service, so the cadence tightens when it matters.
The second is what happens when the sync loses anyway, because sometimes it will. A rule that cannot be satisfied at the terminal needs a path that resolves on the floor. A supervisor confirming a legitimate punch in the moment costs less than a refused employee waiting on a ticket, and it leaves a record either way.
Punches keep flowing to UKG WFM for payroll throughout. Nothing about the pay calculation or the timecard changed, which is what made this a scheduling project rather than a payroll project. The pattern is the same one behind multi-location scheduling flexibility and clock-level location enforcement: the enforcement point stays where it was, and the data feeding it gets sourced from wherever the business decided it should live.
“I did not want a second place where a shift could be true. One schedule is operative, the clock reads that one, and payroll never sees the difference.”
IT Director, multi-location restaurant group
Two levers carry the design: a sync cadence tuned to when changes actually cluster, and a resolution path that settles a refused punch on the floor.
The Person Standing at the Clock
Designs like this get judged by a general manager during a Friday dinner rush, not in a review meeting. According to a GM at one of the group’s locations, the test was whether a disputed punch could be settled without leaving the floor. Anything that sends a shift lead to a laptop mid-service loses, however correct it is architecturally.
For UKG customers assembling a best-of-breed stack, the lesson is this: enforcement logic survives a system move when someone maps the timing of real-world changes against the timing of the sync, and decides in advance who resolves what falls through. CloudApper’s connective work put the schedule at the clock; those operating decisions kept last-minute schedule changes from becoming punch exceptions and payroll cleanup.
One Question Teams Ask
How can UKG time clocks keep enforcing schedule-based punch rules when schedules come from a third-party tool?
Feed the clock the operative schedule from that tool on a sync interval tuned to when changes actually happen, keep punches flowing to UKG for payroll, and define a supervisor path for punches that arrive before a change has synced. The enforcement point does not move; only the source of the schedule does.
If your scheduling has moved to a specialist platform and your UKG time clocks are still enforcing against yesterday’s roster, talk to the CloudApper team about sourcing the operative schedule at the clock.




