Closure

Payroll Readiness for Dayforce

Built on the Dayforce REST API with a React web frontend. Auto-generates a pre-close checklist by pay group, surfacing missing timesheets, unapproved absences, incomplete new hire pay assignments, and unflagged terminations before payroll runs. Requires an active Dayforce license with Payroll and Workforce Management modules enabled.

Overview

CloseReady — Solution Overview

CloseReady is a standalone web application built directly on the Dayforce REST API. It pulls timesheet data, absence records, new hire pay assignments, and termination flags from Dayforce in real time, runs them against a configurable pre-close rule set, and auto-generates a prioritized readiness checklist by pay group — one per payroll run cycle.

No manual checklist assembly. No cross-referencing Dayforce screens before every close. No last-minute discoveries after payroll has already run.

The application is built on a React frontend authenticated against Dayforce via OAuth 2.0. All checklist items are derived live from Dayforce — the app writes nothing back except resolution notes and item sign-off records, which are stored in a companion audit log for compliance purposes. There is no ETL, no middleware, and no third-party sync. The checklist reflects the current state of Dayforce at every load.

CloseReady is designed for payroll managers and HR operations teams at multi-entity Dayforce customers — organizations running multiple pay groups across FOCs, sites, and employment types, where pre-close prep currently happens in spreadsheets, email threads, and memory.

How It Works

When a payroll user opens CloseReady, the application authenticates against Dayforce, identifies all active pay groups with a close date within the configured lookahead window (default: next 7 days), and fetches the relevant timesheet, absence, employee, and payroll data for each group. The rule engine runs against that data and generates a checklist of flagged items — grouped by pay group, sorted by severity, and assigned to the responsible resolution owner.

Data flows in one direction for reads:

Dayforce API → OAuth Token Exchange → Rule Engine → Checklist State → React Frontend

For item resolution, the flow extends:

Payroll User Action → Resolution Note → App Backend → Audit Log + Checklist State Update

The checklist is stateful within a pay period. Once an item is marked resolved, it stays resolved for that cycle unless the underlying Dayforce data changes — in which case it automatically resurfaces on the next refresh.

Integration Architecture

The end-to-end pipeline follows a single pattern:

Dayforce OAuth → REST API → Rule Engine → Checklist Generator → Pay Group View

Five Dayforce API domains are consumed:

Authentication uses OAuth 2.0 with a dedicated Dayforce service account scoped to read-only Payroll, Workforce Management, Absence, and Employee API access, plus write access to the notification endpoint for escalation routing. The token is stored server-side and exchanged at session initiation.

All API calls are routed through a thin Node.js backend handling token management, rate limiting, and response caching. Checklist data is cached per pay group for ten minutes and invalidated on any resolution action or manual refresh trigger.

Access control mirrors the authenticated user's Dayforce payroll entity permissions. A payroll manager scoped to a single FOC sees only that entity's pay groups. A payroll director with multi-entity access sees the consolidated view across all groups.

Data Model

CloseReady does not persist Dayforce-sourced payroll or employee data. All checklist items are derived live on each fetch. The backend stores only checklist state and resolution log records.

PayGroup_View — Derived Per Pay Group

Assembled on each API fetch. Not persisted. Drives pay group card rendering.

Checklist_Item — Per Flagged Issue

One record per detected issue per pay group per pay period. Derived from rule engine output.

Resolution_Log — Persisted Backend Record

Written on every status change to a checklist item.

Checklist Item Taxonomy

Eight item types, grouped by source domain. Severity is fixed per type but overridable by the admin configuration.

Readiness Status Rule Set

Pay group readiness status is derived client-side on each load. Rules applied in priority order — first match wins.

Thresholds are configurable per pay group in the admin settings screen. High-volume hourly pay groups typically warrant tighter thresholds than salaried groups.

Application Views

Pay Group Dashboard (Default View)

The primary screen. All active pay groups with a close date within the lookahead window rendered as cards — Blocked at top, then At Risk, then Ready, within each group sorted by days-to-close ascending. Each card shows: pay group name, entity, pay period dates, close date, days-to-close badge, readiness status badge, open item count by severity, and a progress bar showing resolved vs. total items. Filters by entity, readiness status, and days-to-close range.

Checklist View

Single pay group drill-through. Full itemized checklist grouped by item type, with severity badges, affected employee names, auto-generated descriptions, owner type indicators, and resolution controls. Payroll users mark items resolved, waive with a reason, or escalate from this view. Each item shows detection timestamp and, if resolved, who resolved it and when.

Employee Spotlight

Accessible from any checklist item tied to a specific employee. Shows all open checklist items across all pay groups for that employee in the current cycle — useful for employees appearing in multiple item types simultaneously (e.g. missing timesheet AND unapproved absence).

Historical Close View

Post-close read-only view of completed pay period checklists. Shows final item counts, resolution timeline, waive rate, and which item types recurred most frequently. Designed for payroll managers conducting post-close reviews and identifying systemic gaps in upstream processes.

Admin / Configuration View

Manage item type severity overrides, configure readiness status thresholds per pay group, set the close date lookahead window, configure prior period variance percentage threshold, manage notification routing for escalations, and view API health status.

Action Types

Four actions available from the checklist view.

Deployment Architecture

Three-component deployment. All components containerized and deployable to any cloud environment.

The backend never persists Dayforce payroll or employee data. It proxies, caches briefly, and passes through. All source data remains in Dayforce as the system of record.

Deployment Sequence

Requirements