Every fall, the same integrations that ran quietly all year have to do two jobs at once: keep the current year going, and deliver next year's elections. For a few weeks, two sets of data move in parallel. The first file after Open Enrollment is where they meet. Here is what I do, in the order it happens.
Before Open Enrollment: start early
Work with the client to list what changes for the new year. A new plan with an existing carrier, a plan that's being dropped, or a carrier that's being replaced: each one changes an integration. A new carrier means a new integration to build, and an old one to wind down.
Then take that list to each affected vendor and agree what their file needs: new plan codes, a new location, a new coverage tier, new group or policy numbers. These usually live in calculated fields behind the integration's field overrides. A calculated field that doesn't know about a new plan doesn't fail. It returns a blank or a default value, and the file still goes out. It happens often enough that Workday Support keeps a knowledge article on it.
Get the new-year configuration into the implementation tenant as early as you can: new and changed benefit plans, rates, coverage tiers, benefit groups and eligibility rules. On the integration side, link each new plan to its integration and add the vendor's plan codes to the integration maps. The integration depends on all of it. You can't build or test until it exists.
Then make the changes and test them well before Open Enrollment opens. Vendors are at their busiest during Open Enrollment, and test results come back slowly.
One more trap: contribution amounts. HSA and FSA files that report payroll deductions take them from payroll results, and next year's payroll hasn't run yet. In a test file those amounts are empty, and that's expected. To test them properly, run a future-dated payroll in the test tenant.
During Open Enrollment: two years at once
The current year doesn't stop. New hires, terminations and life events keep coming. And each integration run sees one plan year only: it can't look ahead into next year or back into this one.
So ask each vendor how they want current-year data while Open Enrollment is open. Some want the normal schedule to keep running. Others want it paused.
Find out when each vendor will take its last current-year file, and turn off current-year delivery to match. After that point, track current-year changes (new hires, ended coverage) and send them to the vendor yourself, outside the automated file.
The first Open Enrollment file
Agree the date of the first file with the vendor. It's usually a manual run. Before you launch it:
- Finalize the open enrollment events in Workday. If an employee's event isn't finalized, they can be missing from the file, and some vendors end coverage for anyone who is missing.
- Effective Date: the first day of the new plan year. Often January 1, but not always: plan years can start in April, July or November.
- From Last Update: the date open enrollment was finalized. Open Enrollment elections only reach the integration when they're finalized. Run on a Friday with Monday's finalization date, and the file picks up everyone finalized between Monday and Friday.
- Last Update: now, the moment you launch. Anything entered after it isn't in the file.
If the run comes out empty, check that Open Enrollment is finalized, then check the dates.
After the plan year turns
Send the final current-year file, effective the last day of the plan year. It tells the vendor about ended coverage, including for people who moved to a different carrier. Then reset the integration schedules for the new plan year, and switch off any integration whose vendor contract has ended.
Lesson learned: the first Open Enrollment file is decided by two dates on the day you run it, and by everything you tested in the months before.