Testing the UKG Rehire Employee Process
UKG rehire testing verifies that when a former employee returns, UKG Pro makes the right foundational decision — reactivate and merge the existing person record or create a new one — and then correctly reinstates prior service and seniority, re-establishes accrual eligibility, re-enrols benefits and tax, and re-provisions the access the returning worker should have. SyntraFlow is an AI-powered UKG payroll and workforce assurance platform, Oracle-native and expanding to UKG, whose architecture is designed to prove that a rehire lands as one clean, correctly dated worker with the right history — not a duplicate identity, a lost tenure clock, or a stale benefits and access profile.
Record decision
Reactivate and merge the prior person record, or create a new one.
Prior service
Seniority, tenure and bridging rules reinstate as configured.
Benefits & tax
Eligibility, enrolment windows and tax setup are re-established.
Access
Roles, security profile and downstream accounts are re-provisioned.
Process overview
Rehire is the process by which a person who previously worked for the organization is brought back into UKG Pro as an active worker. Unlike a first-time hire, a rehire starts from a decision that shapes everything after it: does UKG reactivate the existing person record and merge the new assignment onto that history, or does it create a brand-new record? That single branch determines whether prior service, seniority, accrual history, benefits history and identity carry forward or restart from zero. The process then re-establishes the returning worker's employment details, pay, prior-service credit, accrual eligibility, benefits and tax setup, and system access — all effective-dated from the rehire date.
Testing it matters because rehire is where duplicate identities, lost tenure and mis-set eligibility are born, and each has a direct payroll and workforce consequence. A duplicate person record splits a worker's history and can drive duplicate pay, duplicate benefits deductions or a broken year-to-date tax picture. A tenure clock that silently restarts can under-grant accruals, miss a seniority-based pay step, or misapply a benefits waiting period. And access that is not re-provisioned — or worse, over-provisioned from the prior role — is both an operational blocker and a security exposure.
This runbook covers the rehire transaction end to end, from the reactivate-versus-new-record decision through prior-service reinstatement, benefits and tax re-setup, and access re-provision. It is deliberately distinct from the hire employee process, which starts from a genuinely new person, and from onboarding, which handles the tasks and forms a returning worker may or may not need to repeat. It is the mirror image of the terminate employee process that produced the prior separation.
Preconditions
A rehire test is only meaningful when the prior-employment state and the reinstatement rules are known and controlled. Before the process runs, confirm the following are in place:
- ▸A terminated prior record. Each rehire persona has a genuine prior employment record in a terminated status, with a known hire date, termination date, termination reason and eligible-for-rehire flag.
- ▸Prior-service and bridging rules. The service-bridging configuration is defined — the break-in-service window within which prior service is credited, and beyond which the tenure clock restarts.
- ▸Accrual reinstatement rules. Whether prior accrual tenure and any carried or forfeited balances reinstate on rehire, and under which plans, is configured for the plans under test.
- ▸Benefits eligibility and waiting periods. Benefit plans, rehire waiting-period rules and any waiver-of-waiting-period logic for recent rehires are configured.
- ▸Tax and year-to-date context. Prior-year and current-year tax and YTD data exist so a same-year rehire's continuity can be verified rather than reset.
- ▸Security and provisioning model. Role-based security profiles and any downstream account-provisioning integration are active so access re-provision can be asserted, not assumed.
User roles
A rehire touches several personas whose actions and security shape the outcome. Testing must exercise these as distinct users, not one all-powerful test account, because who does what changes what the record ends up looking like.
| Role | Responsibility in this process |
|---|---|
| HR administrator / recruiter | Initiates the rehire, searches for and matches the prior person record, and makes or confirms the reactivate-versus-new-record decision. |
| HR business partner / approver | Approves the rehire, confirming eligibility-for-rehire and the prior-service credit being applied per policy. |
| Benefits administrator | Owns and verifies rehire benefits eligibility, waiting-period or waiver logic, and re-enrolment windows. |
| Payroll administrator | Confirms pay, tax and year-to-date continuity, and that no duplicate pay group or deduction is created for the returning worker. |
| Manager | Receives the returning worker into the correct position and reporting relationship, which drives access and schedule. |
| Security / IT administrator | Owns re-provisioning of the security profile and any downstream accounts, and confirms prior over-broad access is not silently restored. |
Required test data
Because the correct outcome of a rehire depends entirely on the prior record and the break in service, the test data set is the test. Build a small library of deterministic personas that each isolate one reinstatement rule:
- ▸Short-break rehire. An hourly hospital employee rehired inside the bridging window, so prior service and accrual tenure should reinstate — the clean bridged path.
- ▸Long-break rehire. A retail employee returning after the bridging window, so the tenure clock should restart and no prior service is credited.
- ▸Same-tax-year rehire. A worker rehired in the same calendar year, to verify year-to-date tax and wage continuity rather than a reset.
- ▸Union rehire. A returning member of a union group with seniority-based recall and step rules that must reinstate to the correct seniority date.
- ▸Cross-location rehire. An employee rehired into a different location or legal entity than their prior role, to test entity, tax jurisdiction and security changes.
- ▸Not-eligible-for-rehire persona. A prior record flagged ineligible for rehire, to confirm the guardrail blocks or warns rather than silently proceeding.
Each persona needs a terminated prior record with a defined hire and termination date, a rehire date chosen to fall inside or outside the bridging window, and known accrual, benefits and tax history — state that is managed repeatably through UKG test data management.
Main process steps
The happy-path flow for a bridged rehire follows a predictable sequence. A test asserts on the state at each step, not just that the worker appears active at the end.
- 1.Find and match the prior record. HR searches for the returning person; UKG surfaces the existing terminated record and its eligible-for-rehire status, avoiding a blind new record.
- 2.Choose reactivate versus new record. The rehire is applied to the matched person so history merges onto one identity, rather than creating a duplicate.
- 3.Set rehire employment details. Rehire date, position, pay, legal entity, location and reporting relationship are entered, all effective-dated from the rehire date.
- 4.Apply prior-service and seniority rules. Bridging logic evaluates the break in service and reinstates the adjusted service date, seniority date and any seniority-based pay step.
- 5.Reinstate accrual eligibility. Accrual plan enrolment, tenure-driven accrual rate and any reinstated or forfeited balance are set according to the reinstatement configuration.
- 6.Re-establish benefits and tax. Benefits eligibility and waiting-period or waiver logic apply, the re-enrolment window opens, and tax and year-to-date setup continue or reset per the rehire timing.
- 7.Re-provision access. The correct security profile and downstream accounts are granted for the new role, and any obsolete prior access is not carried over.
Positive test scenarios
Positive scenarios confirm that valid rehires land on one record with the correct prior-service, accrual, benefits, tax and access outcome. The table below uses concrete UKG employee variations, each with the rule under test and the expected end state.
| Type | Scenario | Expected outcome |
|---|---|---|
| Positive | Hourly hospital employee rehired inside the bridging window | Prior record is reactivated; adjusted service and seniority dates reinstate; accrual tenure continues on one identity |
| Positive | Retail employee with split shifts rehired after the bridging window | Tenure clock restarts from the rehire date; no prior service credited; a fresh accrual and benefits waiting period applies |
| Positive | Employee rehired in the same calendar year as termination | Year-to-date wages and tax continue on the same record; no duplicate YTD or wage-base reset |
| Positive | Union employee recalled under seniority-based rules | Union seniority date and step reinstate correctly; union plan and rules apply, not the default configuration |
| Positive | Employee rehired into a different location and legal entity | New entity, tax jurisdiction and location apply from the rehire date while the person history stays merged |
| Positive | Manufacturing worker rehired into a role with a shift premium | Pay, shift-premium eligibility and work rule are set for the new role; prior pay is not silently carried forward |
| Positive | Rehire re-provisioned with the correct role-based security profile | Access reflects the new position only; downstream accounts are re-created and the audit trail records the grant |
Negative test scenarios
Negative scenarios confirm the configured guardrails actually hold — that a rehire cannot create a duplicate identity, over-credit service, or silently restore access it should not.
| Type | Scenario | Expected outcome |
|---|---|---|
| Negative | Rehire processed as a new record when a matching prior record exists | Duplicate-detection warns or blocks; the process does not create a second identity for the same person |
| Negative | Prior record flagged not-eligible-for-rehire is submitted for rehire | The eligibility guardrail blocks or routes for exception approval; the rehire does not proceed silently |
| Negative | Long-break rehire where prior service is incorrectly credited | Bridging rule restarts the tenure clock; no over-credited seniority, accrual rate or pay step is applied |
| Negative | Same-year rehire whose year-to-date tax and wage base reset to zero | Reset is prevented; YTD continuity is preserved so wage-base limits are not incorrectly reopened |
| Negative | Benefits waiting period waived when policy requires it to reapply | The configured rehire waiting-period rule is enforced; enrolment does not open earlier than allowed |
| Negative | Prior over-broad security access is silently restored on reactivation | Access is re-provisioned from the new role only; obsolete or excessive prior permissions are not carried over |
| Negative | Rehire date set earlier than the recorded termination date | The overlap is rejected or flagged; no invalid overlapping employment period is created on the record |
Rule variations
The same rehire produces different, equally correct outcomes depending on which rules govern the returning worker. These are the variation axes a thorough rehire suite parameterises across:
- ▸Break-in-service length. Whether the rehire date falls inside or outside the bridging window decides if prior service, seniority and accrual tenure reinstate or the clock restarts.
- ▸Accrual reinstatement policy. Plans differ on whether prior tenure, carried balances or forfeited balances return on rehire, changing the starting accrual rate and balance.
- ▸Benefits waiting-period rule. A rehire may face a fresh waiting period, a waived period for recent rehires, or immediate re-enrolment depending on plan and timing.
- ▸Tax and YTD timing. A same-year rehire should continue year-to-date wages and tax, while a new-year rehire starts fresh — one date changes the correct payroll behavior.
- ▸Union and seniority rules. Union recall carries distinct seniority-date, step and eligibility rules that must override the default and reinstate to the correct point.
- ▸Entity, location and security. Rehire into a different legal entity or location shifts tax jurisdiction and work rules, and the security profile must reflect the new role, not the old one.
Integration checkpoints
A rehire is rarely contained inside UKG Pro alone; it fans out to payroll, benefits carriers, provisioning and often a system of record in another suite. These are the checkpoints where UKG integration testing intersects with this process:
- ▸Payroll continuity. Pay group assignment, tax setup and year-to-date data must flow into payroll without creating a duplicate pay record — verified alongside UKG Pro testing.
- ▸Benefits carrier feeds. Rehire eligibility, waiting-period and enrolment changes are transmitted to carrier files, so the outbound feed must reflect the reinstated, not the terminated, status.
- ▸Identity and provisioning. Re-provisioning depends on SSO, directory and account-creation integrations, so a returning worker must resolve to one identity rather than a duplicate downstream account.
- ▸Cross-application HCM. When the worker system of record lives in Workday, Oracle or SAP, the rehire and prior-service context must match across suites so tenure and eligibility are consistent.
- ▸Downstream continuity. The reinstated worker feeds scheduling, accrual and timecard processes, so a clean rehire protects everything those workforce processes build on.
Expected outcome & evidence
For a valid rehire, the correct end state is one active worker on a single merged person record, with prior service, seniority and accrual eligibility set exactly as the bridging and reinstatement rules require, benefits and tax re-established for the rehire timing, and access re-provisioned for the new role. For a blocked rehire, the correct end state is no duplicate identity and no invalid state, with the appropriate warning or exception raised. A test proves the outcome only if it captures the evidence to support it:
- ▸Person-record proof. Evidence that the rehire merged onto the existing person, with no duplicate identity, and the original and adjusted service dates recorded.
- ▸Prior-service and accrual snapshot. The reinstated seniority date, accrual plan enrolment, accrual rate and starting balance, showing bridging applied correctly.
- ▸Benefits and tax state. Benefit eligibility, waiting-period or waiver applied, re-enrolment window, and year-to-date tax and wage continuity or reset as expected.
- ▸Access and provisioning record. The re-provisioned security profile and downstream accounts, confirming new-role access and no restored obsolete permissions.
- ▸Expected-versus-actual log. A captured comparison for each scenario that supports later review by payroll, HR, benefits and compliance stakeholders.
SyntraFlow automation approach
SyntraFlow is designed to treat the rehire as one reusable master scenario — match the prior record, reactivate onto one identity, then assert on service, accrual, benefits, tax and access — that runs data-driven across every persona and rule permutation. Instead of scripting one click-path, the platform seeds the precise terminated record and break-in-service context, drives the rehire, and verifies the outcome against expected values.
- ▸Reusable master scenario. A single parameterised flow covers match through re-provision, so new bridging windows or reinstatement rules are added as data rows, not new scripts.
- ▸Data-driven permutations. The same scenario runs across break lengths, accrual policies, benefits waiting-period rules, tax timing, union recall and entity changes to cover the combinations that matter.
- ▸Self-healing execution. Tests are designed to stay stable when the UKG HR and payroll UI shifts between releases, reducing maintenance on every update.
- ▸Evidence capture. Each run records the person-record proof, prior-service snapshot, benefits and tax state, and provisioning record as audit-ready expected-versus-actual evidence.
AI is designed to assist and recommend — drafting rehire scenarios from plain-language intent and suggesting the bridging, accrual, benefits and access permutations worth covering — while humans remain responsible for approving payroll and confirming compliance. SyntraFlow never approves a rehire, approves pay, or makes wage-hour, benefits-eligibility, union or tax determinations. These capabilities reflect design intent for an early, roadmap-stage UKG offering and are available for demonstration and proof-of-concept validation. A rehire pack pairs naturally with a regression automation effort so returning-worker paths stay verified on every UKG release.
See the rehire flow validated end to end
Bring your bridging rules, accrual reinstatement policy, benefits waiting periods and provisioning model, and we will scope a proof-of-concept that validates the reactivate-versus-new-record decision and every reinstatement outcome as checkable evidence.
Frequently asked questions
What is UKG rehire testing?
UKG rehire testing verifies that when a former employee returns, UKG Pro reactivates and merges the correct person record instead of creating a duplicate, and then reinstates prior service and seniority, accrual eligibility, benefits and tax setup, and system access exactly as the bridging and reinstatement rules require — not just that the worker shows as active.
How is rehire testing different from hire testing?
A hire starts from a genuinely new person, so the focus is clean record creation. A rehire starts from an existing terminated record, so the consequential logic is the reactivate-versus-new-record decision and whether prior service, accruals, benefits and tax reinstate correctly. Rehire testing exercises history continuity and duplicate prevention that a first-time hire never touches.
Why is reactivate-versus-new-record the critical decision?
That single branch decides whether a worker keeps one identity and history or is split across two. A wrong new record can drive duplicate pay, duplicate benefits deductions and a broken year-to-date tax picture, while incorrectly merging can carry forward stale data. Testing asserts the decision resolves to one clean, correctly dated worker.
How do prior-service and bridging rules get tested?
Tests pair rehires inside and outside the break-in-service window. Inside the window, prior service, seniority date and accrual tenure should reinstate; outside it, the tenure clock should restart with no credit. Each persona asserts on the adjusted service date, seniority-based step and accrual rate so bridging is proven, not assumed.
What benefits and tax behavior should rehire testing confirm?
It confirms benefits eligibility and the correct waiting-period or waiver logic, the re-enrolment window, and tax continuity. A same-calendar-year rehire should continue year-to-date wages and tax rather than resetting the wage base, while a new-year rehire starts fresh. These outcomes are asserted per the rehire date and plan configuration.
Does rehire testing cover access re-provisioning?
Yes. Tests confirm the returning worker receives the security profile and downstream accounts for the new role, and that obsolete or over-broad prior access is not silently restored on reactivation. This closes both an operational gap, where access is missing, and a security exposure, where old permissions linger.
Does SyntraFlow support UKG rehire testing today?
SyntraFlow is an established Oracle-native testing platform now expanding to UKG. UKG coverage is early and on the active roadmap; the capabilities described reflect design intent and are available for demonstration and proof-of-concept validation. We recommend a scoped assessment to confirm which rehire scenarios fit your configuration and reinstatement rules.
Where should we start with rehire testing?
Start with an assessment that maps your bridging window, accrual reinstatement policy, benefits waiting periods, tax handling and provisioning model, then scope a proof-of-concept against the highest-risk rehire paths. Those validated scenarios become reusable assets for regression and release testing. Schedule a demonstration or contact us to begin.
Related UKG testing
Hire employee process
The new-person path a rehire branches from — clean record creation, pay and eligibility setup.
Terminate employee process
The separation that produced the prior record every rehire reactivates or bridges from.
Onboard employee process
The tasks and forms a returning worker may repeat, tested as its own flow.
UKG Pro testing
The capability view of HR, payroll and benefits assurance a rehire depends on.
Regression automation
Keep returning-worker paths verified automatically on every UKG release.
Business process testing
The hub for end-to-end UKG process runbooks across HR, WFM and payroll.
Validate every rehire onto one clean record
Move from screen-level checks to outcome-level assurance designed to confirm the record decision, prior-service reinstatement, benefits and tax re-setup, and access re-provision are correct the moment a former employee returns. Start with an assessment and a proof-of-concept against your highest-risk rehire paths.