Benefits Administration Process in HRS
OverviewBenefits Administration (Ben Admin) is an automated process that performs a series of tasks that would normally be performed manually by Institution Benefits Administrators. The State of Wisconsin has complex rules regarding eligibility for the Wisconsin Retirement System (WRS) and related benefit plans. The University of Wisconsin offers additional benefit plans over and above those prescribed by State Statutes.
Institution Benefit Administrators may have many tasks assigned to them and little time to navigate these complex rules and perform all the manual entries required to assign an employee to the appropriate Benefit Program, create their Benefit Options, make their elections or perform the entries required when an employee is hired and/or during an Annual Benefit Enrollment period. Benefits Administration automates many of these processes. This KB explains how Benefits Administration assigns employees to the appropriate Benefit Program, prepares enrollment options for them, and finalizes any enrollments in HRS.
- Benefits Administration (Ben Admin) automatically creates Events based on new Job Rows that have been entered into HRS, as well as outputs for specialized processes such as the UIA, ICI, Open Enrollment (ABE), etc. Events can also be manually created for the purpose of enrolling, changing, or canceling benefit plans for employees. For information on how to add a manual Event, please reference: Adding Events to the BAS Activity Table in HRS .
- Since Ben Admin will move an Event only one step each time it's run so it's set up to run multiple times a night to move Events through several steps. Throughout the cycle, if errors occur or information is missing, the employee's Event will be put on hold until the issue is resolved or the information is added to HRS. For more information on how to handle Benefits Administration error messages, please reference the following KB document: Process Indicators and Event Process Statuses in HRS .
- Newly hired employees who are missing values in key critical eligibility fields will be placed "on hold" from Benefits Administration processing and written to the New Hire Hold Report until the information is added to HRS. For more information about the New Hire Hold report, please reference Processing the WED New Hire Hold Report in HRS .
- Employees who are moving from one Benefit Program to another where benefit eligibility or enrollments may be affected, will be written to the MSC Event Evaluation Report until the Benefits Administrator manually Finalizes the Event. For more information on the MSC Event Evaluation Report, please reference: Reviewing the MSC Event Evaluation Report in HRS .
- Benefits Administration can be run ad hoc for any Event using On Demand Event Maintenance.
Review of Benefits Administration
There are four main steps to processing an Event through Benefits Administration:
1) Determine the population of Events to process (daily events or open enrollment)
2) Evaluate eligibility criteria and Assign the employee to a Benefit Program (determines what set of benefit plans an employee can enroll in)
3) Prepare any available enrollment Options (based on Benefit Program Assignment and type of Event)
4) Validate and load elections to the Base Benefit pages (after enrollments have been entered)
Below is a visual representation of the steps for Benefits Administration and the points in the process where employees will be written to a report, error out, or the Event will Finalize. The Ben Admin process begins when a row is added on Job Data, Benefits Personal Data, or when a manual Event is added to the BAS Activity Table (center circle) and then moves clockwise through the process shown below.
Benefits Administration Steps
1. Determines Population by Assigning the Event to a Benefit Schedule:
Different Ben Admin schedules will be created for different purposes. For example, there will a different Event Schedule for Open Enrollment (ABE) versus every day Event Maintenance. The types of Events (List of Benefit Events Used in HRS.) are tied to specific schedules so Ben Admin knows which Events to process. (List of Benefit Schedules in HRS.) When you are running Ben Admin ad hoc using On Demand Event Maintenance - you designate the population by entering the employee's Empl_ID number.
Once Ben Admin has assigned the Benefit Schedule, it picks up all Open Events within that Schedule in date and priority order. Events that are Closed, Voided, or Disconnected will be ignored.
2. Assigns Benefit Program:
Each JOB row added to HRS or Benefits Personal Data will create a Benefit Event to ensure that Ben Admin will use all available information to evaluate what Benefit Program the employee should be assigned to as of the effective date for that row. Each Benefit Program is set up with a set of Eligibility Rules that must be met in order for an employee to be assigned to it. These Eligibility Rules are based on a number of values including:
Employee Class and FTE found on the Job Information tab of Job Data:
The duration of their job or Continuity Code found on the UW Custom tab of Job Data:
The values manually entered on the UW Benefits Tab.
Which are translated to values assigned to the Benefits Eligibility Fields 1-5:
Since Ben Admin uses key information to determine what Benefit Program to assign an employee to (the same as an Institution Benefits Administrator would), if that information is absent, the employee's Event processing should be put "on hold" until the information is entered into HRS. These employees will be written to the New Hire Hold Report. If Ben Admin is unable to assign a Benefit Program due to a processing error, the employee's Event will be set aside with a status of Assign Error, Assign None or Finalized - Benefit Program None.
If all information is present, a process called Eligibility Configuration Population will run and translate those values to specific fields on Job Data. Ben Admin will then read those eligibility fields and assign the Benefit Program or reassign the employee to a different Benefit Program if warranted. To ensure that Benefit Administrators take that opportunity to counsel their employees on new or changing Benefit Plans based on those JOB actions, the employees will be written to the MSC Event Evaluation Report and the Institutions will need to manually complete the Ben Admin process through On Demand Event Maintenance.
The Benefit Program dictates:
a) Which Benefit Plans an employee is eligible for
b) If an employee will have their deductions taken on a pre-tax or after-tax basis
c) How frequently the deductions will take place and on which payroll periods
d) Their specific category for WRS (if applicable)
e) Any special circumstances that occur for that employee population (such as a unique payroll or deduction schedule)
Once Ben Admin has Assigned the Benefit Program, the status for this Event will be set to Assigned and the Event will be moved forward to the next step.
3. Prepare Options:
Once the employee has been assigned to the appropriate Benefit Program, the system will evaluate if the employee has any enrollment opportunities based on the JOB Action or the type of Event manually entered. For example, if the employee is a new hire or a rehire, they may have an enrollment opportunity. In such cases, the Hire Event is prepared so that the next step of the process allows the employee to make benefit elections using Self Service. If an MSC Event is created because an employee has moved from one Employee Class to another, they may also have enrollment opportunities and/or lose benefits. If the Event created by the JOB row does not provide the employee with an enrollment opportunity, the process will stop with the assignment of the Benefit Program and the Event status will move to Prep None and will be close to further processing. (e.g. PAY for a pay increase, or PLA for a paid leave of absence).
Once Ben Admin has Prepared Options, the status of the Event will change to Prepared and the Event will be moved forward to the next step.NOTE: Between the 3rd and 4th step of Ben Admin, the Benefits Administrator or the employee using Self Service will enter enrollment elections into the Event if applicable. Depending on the type of Event (Hire Event vs Open Enrollment Event), the employee will have a certain amount of time to make enrollment choices before the Event is Closed and Finalized. ADM, SAV, and UIA Events will remain Open until a Benefit Administrator either makes elections or Finalizes the Event keeping current defaults.
4. Finalizes Enrollments:
After elections have been completed, Benefits Administration will validate whether the enrollments are appropriate given the employee's Benefit Program Assignment and the number and types of dependents for the coverage selected, and then load the election rows directly to the Base Benefit pages. This eliminates the need for Institution Benefit Administrators to manually enter the enrollment selections on each enrollment screen. If Benefits Administration is unable to validate the elections, an Election Error will occur and the rows will not be written to the Base Benefit pages.
Once Ben Admin has finalized the enrollments, the status of the Event will be changed to Finalized - Enrolled.
You will be able to verify the information by looking at the Base Benefit pages by referencing: Review Benefit Enrollments in HRS .
- Process Indicators and Event Process Statuses in HRS
- List of Benefit Events Used in HRS
- List of Benefit Schedules in HRS
- Benefits Administration Schedule Summary in HRS
- Adding Events to the BAS Activity Table in HRS
- Entering an Annual Benefits Base Rate (ABBR) in HRS
- Overview of Benefits Eligibility Fields in HRS
- Continuity Status in HRS
- Entering and Updating Benefits Personal Data in HRS
- Enrolling, Changing, or Canceling Coverage Using On Demand Event Maintenance in HRS
- Reprocessing Events Using On Demand Event Maintenance in HRS
- Processing the WED New Hire Hold Report in HRS
- Reviewing the MSC Event Evaluation Report in HRS
- Running the Employee Process Status Report in HRS
- Running the Populate Eligibility Config Pop Process Ad Hoc in HRS