Onboarding Command Center

New Hire Onboarding Visibility for Dayforce

Built on the Dayforce REST API with a React web frontend. Surfaces new hire onboarding task status, completion progress, and overdue flags across all entities and sites in a single operations view. Supports multi-entity and multi-FOC org structures. Requires an active Dayforce license with HR and Onboarding modules enabled.

Overview

Onboarding Command Center — Solution Overview

The Onboarding Command Center is a standalone web application built directly on the Dayforce REST API. It pulls new hire records, onboarding task assignments, and task completion status from Dayforce in real time, surfaces them in a unified HR operations view, and gives HR teams the ability to nudge employees and escalate blockers — all without leaving the app.

No spreadsheets. No manual status chasing. No cross-referencing Dayforce screens to piece together where each hire stands.

The application is built on a lightweight React frontend authenticated against Dayforce via OAuth 2.0. All data originates from Dayforce — the app writes nothing back except nudge and escalation log entries, which are posted to a lightweight backend and stored in a companion data store for audit purposes. There is no separate ETL, no middleware, and no third-party sync layer. Every page load pulls live from the API.

The app is designed for HR business partners and people operations teams at multi-entity Dayforce customers — organizations where new hires span multiple FOCs, cost centers, and site locations, and where onboarding completion is currently tracked in a mix of Dayforce screens, email threads, and spreadsheets.

How It Works

When an HR user loads the Onboarding Command Center, the application authenticates against Dayforce via the stored OAuth token, fetches new hire records for the configured lookback window (default: hires with a start date within the last 90 days), and resolves each hire's onboarding task list and completion status. The resulting dataset is rendered as a prioritized work queue — sorted by risk status, days since start, and overdue task count.

Data flows in one direction for reads:

Dayforce API → OAuth Token Exchange → React Frontend → Prioritized Work Queue

For nudge and escalation actions, the flow extends:

HR User Action → App Backend → Dayforce API (notification trigger) + Audit Log

Risk status is calculated client-side on each load using a rule set applied to each hire's task completion relative to their days-since-start. No separate analytics engine. No scheduled jobs for flagging — the status is always current because it is always derived from live API data.

Integration Architecture

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

Dayforce OAuth → REST API → React Data Layer → Component State → Rendered Work Queue

Four Dayforce API domains are consumed:

Authentication uses OAuth 2.0 with a dedicated Dayforce service account scoped to read-only HR and Onboarding API access, plus write access to the notification endpoint for nudge delivery. The token is stored server-side and exchanged at session initiation — never exposed to the browser.

All API calls are routed through a thin Node.js backend that handles token management, rate limiting, and response caching. Onboarding task data is cached for five minutes per hire to reduce API call volume on high-headcount pages. The cache is invalidated on any nudge or escalation action for that hire.

Row-level access control mirrors the HR user's Dayforce entity permissions. The app reads the authenticated user's entity scope from Dayforce at login and filters all hire and task queries accordingly. An HR BP scoped to West Region sees only West Region hires. A system admin sees the full org.

Data Model

The app does not maintain a persistent data store for Dayforce-sourced data — all HR and task records are fetched live. The companion backend stores only action log records.

Hire_View — Derived Client-Side Record

Assembled per hire on each API fetch. Not persisted. Drives all UI rendering.

Task_View — Per-Task Record

One record per onboarding task per hire. Assembled from Dayforce Onboarding API response.

Action_Log — Persisted Backend Record

Written on every nudge or escalation action. Stored in the app's companion Postgres instance.

Risk Status Rule Set

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

Completion Threshold Brackets

Brackets are configurable at deployment time via an admin settings screen. Customers with longer or shorter onboarding cycles adjust thresholds to match their standard.

Application Views

Work Queue (Default View)

The primary screen. All active onboarders rendered as a prioritized card list — Overdue at top, then At Risk, then On Track, within each group sorted by days since start descending. Each card shows: name, title, department, entity, manager, start date, days-since-start badge, risk status badge, task completion bar, per-task status breakdown, and action buttons. Filters by entity, department, manager, and risk status. Full-text search across name, department, manager, and entity.

Hire Detail View

Single hire drill-through. Full task list with due dates, days-overdue callouts, owner type per task, and complete action log history for that hire. HR can nudge, escalate, or flag as blocked from this view with an optional note.

Entity Summary View

Aggregate view by entity or FOC. Headcount in each risk tier, average completion percentage, overdue task count, and most common blocked tasks across the entity. Designed for HR leads managing multi-site operations.

Admin / Configuration View

Manage completion threshold brackets, configure notification routing (which Dayforce user receives nudge emails per entity), set the active lookback window, and view API health status including last successful sync timestamp and any rate limit events.

Action Types

Four actions available from the work queue and hire detail view.

Deployment Architecture

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

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

Deployment Sequence

Three-phase deployment to stand up the full stack.

Requirements