Scheduling Software That Works Alongside UKG

There is a specific kind of frustration that lives inside large organizations running an enterprise workforce management suite. The suite is real, the investment is real, payroll runs on it, and nobody is going to rip it out. And yet the nurses on ward 4 are still swapping shifts over a group chat, the contact center's intraday changes live in a spreadsheet, and the site manager builds next week's rota by hand because the suite's scheduling module needs a change request to adjust a template.

The suite did not fail. It was bought for payroll accuracy, compliance, and a single employee record, and it delivers those. Day-to-day scheduling was the line item that came bundled in, and for many teams it never became the tool they actually plan with.

This guide is about the unbundled middle path: keep UKG as the system of record and run daily scheduling in Soon for the teams that need it. No migration project, no procurement cycle for a suite replacement, no waiting for the next fiscal year.

Where the seam sits

Coexistence works when the boundary between the two systems is clean. The division that holds up in practice:

• UKG keeps: the employee record, payroll processing, time clocks and attendance hardware, accruals as the legal record, and HR workflows. Everything that makes it the system of record.
• Soon takes: building and publishing schedules, auto-scheduling against rules and availability, shift swaps and self-service, leave requests at the planning level, forecasting, and intraday coverage when the day starts moving.
• The seam: a people list flowing into Soon once, and hours flowing back to payroll on a cycle. Both are CSV exchanges that take minutes once mapped.

The important property of this split is that nothing UKG is contractually or legally responsible for moves. Payroll does not change. The audit trail does not change. What changes is where a manager spends Thursday afternoon.

What the loop looks like week to week

1. People sync. Employees come into Soon from a UKG export: names, roles, contract hours, teams. For most departments this list changes rarely, so a monthly refresh or an update on joiners and leavers is enough.
2. Planning happens in Soon. Managers build the week with auto-scheduling, employees see shifts in their browser, swaps and time-off requests happen with self-service instead of messages to the manager.
3. Hours flow back. At the end of the pay period, scheduled and worked hours export as CSV matched to the payroll system's columns. The payroll team's process does not change; only the source of the file does.

Teams that run this loop describe the same before-and-after: scheduling stops being a manager's evening job, and the suite goes back to being the quiet system of record it was bought to be.

Teams weighing this setup usually want the detail on both sides of the seam, and the honest version matters: the Soon vs UKG comparison includes the rows UKG wins, because a coexistence decision depends on knowing exactly what stays in the suite.

The teams that end up in the seam

Coexistence sounds abstract until you look at which teams actually live in the gap between the suite and the spreadsheet. Two patterns come up again and again in our conversations with UKG-run organizations.

The first is the flexible labor pool. A logistics operator we spoke with runs a pool of several hundred flexible workers across multiple sites, and the suite handles their time, attendance, and payroll while the scheduling itself lives in a spreadsheet, because pool demand arrives as hours and skills rather than as a rota, and the suite's roster views are organized around home departments the pool does not have. Float pool and flex pool scheduling runs in a different order than roster scheduling for exactly that reason: it starts from a staffing requirement, not from an empty grid.

The second is the team whose scheduling problem happens inside the shift. A large attractions operator, also a UKG shop, has clean shifts in the suite; what it cannot plan there is the rotation within them, who is at which position, who relieves whom, and how a rotation tightens in the heat, for a workforce that is largely not allowed to carry phones on the floor. That within-shift layer is intrashift scheduling, and it coexists with a suite for the same reason the pool does: the suite's unit of planning stops at the shift boundary.

In both cases nobody is unhappy with what the suite does well. The gap is a shape-of-problem gap, and it is why the coexistence question comes up most often not from IT but from the operations people holding the spreadsheet.

The pilot: one site, one day

The strongest argument for coexistence is not the steady state; it is how cheaply you can test it. A suite-wide scheduling rollout is a project with a steering committee. A coexistence pilot is one department, one CSV export, and one manager willing to try next week's schedule in a different tool.

That asymmetry matters for the decision itself. After four weeks of one site scheduling in Soon, the organization knows what its teams actually need from scheduling software: which rules matter, how much self-service employees pick up, what forecasting is worth. That knowledge is exactly what a later suite decision needs, and there is no way to get it from an RFP document.

It also changes the risk shape of the Workforce Central end-of-life decision for the organizations facing it. Every team already scheduling in Soon is a team whose daily operations do not depend on the migration timeline, whichever path the organization picks for the suite itself.

What IT will ask, answered

Coexistence pilots die in security review more often than in budget review, so it is worth knowing the answers up front.

• Access: Soon supports SAML single sign-on through Microsoft Entra ID, Okta, and Google Workspace on the Enterprise plan, so the pilot uses the same identity provider and offboarding flow as everything else.
• Data: the people data Soon holds is the scheduling subset: names, contact details, roles, availability. Payroll data, salaries, and HR records never leave the suite.
• Devices: Soon runs as a PWA in any browser, so there is no app to package and deploy through mobile device management.

The trust and security page documents hosting, subprocessors, and GDPR posture in the format security reviews expect.

When coexistence is the wrong answer

Being honest about the boundary cuts both ways. Coexistence is the wrong setup when the thing you need fixed is inside the suite's half of the seam: payroll errors, time clock disputes, accrual calculations, or certified compliance reporting. Those problems live in the system of record and adding a scheduling layer does not touch them.

It is also the wrong answer if your organization is about to run a full suite migration anyway and scheduling requirements are already captured in it. In that case adding a second tool mid-project adds a workstream. Run the pilot before the migration starts or after it lands, not during the cutover.

For everyone else, the teams doing their scheduling in spreadsheets beside a seven-figure suite, the middle path is real, it is cheap to test, and it does not ask anyone to bet the payroll run on it.