Dayforce Benefits Enrollment Configuration for Mid-Market Open Enrollment

Benefits plan setup: the structure underneath enrollment

Before any enrollment window can open in Dayforce, the benefit plans themselves need to be configured correctly. This is the layer that most implementation teams treat as a data entry exercise, and it's where the most consequential configuration decisions get made without enough attention.

Plan types and plan definitions

Dayforce organizes benefits into Plan Types (Medical, Dental, Vision, Life, LTD, 401k, HSA, FSA, etc.) and then Plan Definitions within each type (e.g., "Medical - HDHP 2026," "Medical - PPO 2026"). The plan definition is where you configure coverage tiers, employee contribution amounts, employer contribution amounts, and the options available for each coverage tier (Employee Only, Employee + Spouse, Employee + Children, Family).

The configuration point that most teams get wrong: contribution amounts. Dayforce supports flat dollar contributions, percentage-of-premium contributions, and rate table contributions. The rate table approach is the most flexible — it lets you define different employee cost amounts for each coverage tier and different employer subsidy amounts — but it requires more upfront setup. If your contribution structure is more complex than "employees pay a flat $X per pay period," you need the rate table approach, not the flat dollar approach, even if flat dollar feels simpler at setup time.

Plan year and enrollment window configuration

Each benefit plan in Dayforce has a Plan Year — the coverage period — and an associated Enrollment Window — the period during which employees can make elections. These are separate configurations that must align correctly.

// Dayforce Benefits Plan Year — key configuration

Plan Year: 2026 Benefits Year Coverage Start: 2026-01-01 Coverage End: 2026-12-31 Enrollment Window: 2025-11-01 to 2025-11-21 // Open enrollment period Election Effective: 2026-01-01 // When elections take effect Waive Deadline: 2025-11-21 // Last day to actively waive Late Enrollment: Qualifying Event Only // Post-window enrollment rules

A common mistake: setting the enrollment window to end on the same date as the election effective date. This leaves no gap for HR to review enrollments, correct errors, and transmit to carriers before coverage begins. Best practice is a 7-10 day gap between the enrollment window close and coverage effective date.

Eligibility rules: what gets them wrong

Eligibility rules determine which employees can enroll in which plans. In Dayforce, eligibility is configured through Eligibility Rules attached to each plan definition, and through Waiting Periods that govern when new hires become eligible.

Common eligibility rule errors

The eligibility configurations that cause the most open enrollment problems:

• Employment type mismatches. If your medical plan is available to full-time employees only, the eligibility rule needs to filter on the employment type field — and that field needs to be populated correctly for every employee. A part-time employee with an incorrect full-time employment type assignment will appear as eligible and may enroll in a plan they shouldn't have access to. The error shows up when the carrier file transmits and the carrier rejects the enrollment. Employment type in Dayforce is configured in the HR module — see our Dayforce HR module configuration guide for how to audit and correct employment type assignments across your population.

• Hours threshold eligibility. For ACA compliance, companies often have benefit eligibility tied to a minimum hours threshold (typically 30 hours per week for ACA full-time status). Configuring this correctly in Dayforce requires the ACA measurement period module to be set up and the eligibility rule to reference average hours from the measurement period — not just current scheduled hours, which can change week to week.

• Dependent eligibility age limits. Dayforce's dependent eligibility rules can enforce dependent age limits automatically (removing a dependent from coverage when they turn 26, for example). But this only works if the rule is configured correctly and the dependent date-of-birth is accurate. Missing or incorrect dependent DOBs in Dayforce are a persistent data quality issue that surfaces during open enrollment.

Waiting period configuration

Waiting periods in Dayforce are configured per plan type and define when a new hire's eligibility begins. Common options:

• Immediate — eligible on hire date (common for some life insurance plans)

• First of month following hire — eligible on the first day of the month after the hire date

• 30/60/90 day waiting periods — eligible a defined number of days after hire

• First of month following 30/60/90 days — a combination that aligns eligibility with a billing cycle

Waiting period configuration errors are especially visible during onboarding. A new hire who believes they're eligible for benefits on day one — because HR told them they would be — but whose Dayforce configuration has a 30-day waiting period will find that the enrollment screen in Employee Self-Service doesn't show any benefit options. The resulting help desk ticket is entirely preventable.

Benefits enrollment configuration getting complicated? This is exactly what we scope and fix. Get a fixed-price quote in 48 hours →

Carrier EDI connections: where enrollment data goes after the election