PeopleSoft Benefits Administration 9.1 PeopleBook

Creating Event Rules

This chapter provides overviews of event rules and the evaluation of event rules, and discusses how to:

Define Benefits Administration actions for event rules.
Set up event classes.
Define trigger events.
Define event rules.
Process events for COBRA (Consolidated Omnibus Budget Reconciliation Act) administration.
Define rules for Benefits Billing.
(USF) Set up multiple, concurrent open seasons.

Understanding Event Rules

You use event rules to:

Take into account the type of event and your employees' benefit election history to determine which benefit options employees can choose.
Determine how the system compensates when employees neglect to make certain benefit elections.
Determine effective dates for coverage and premiums.
Manage enrollments in and move them into Benefits Billing.

Event rules are not the same as eligibility rules. Eligibility rules help determine which benefit program and benefit plan options an employee can have. They tell the system that because of changes to employee data, employee X is no longer eligible for certain plan options, but is eligible for others.

Event rules determine which eligible options employee X can actually choose, based on the type of event that has occurred and when new coverage begins. The event rules also determine when the plans that employee X is now ineligible for will be terminated and which plan options employee X will be enrolled into if new enrollments are not specified.

Event rules are linked to a benefit program on the Benefit Program page. You can have a different event rule for each plan type in a benefit program.

To set up event rules:

Use the Action Reason table to link personal action and action reason combinations that affect benefits eligibility.
Use the Event Class table to assign the types or classes of events that you want the system to recognize, and to control how the system processes event classes.
Use the Event Rules table to define the specific behavior that the system takes for each event classification.

Understanding the Evaluation of Event Rules

PeopleSoft Benefits Administration processes all participant events by using the appropriate event rule or event classification rule for each covered plan type. Depending on the results of this evaluation, Benefits Administration either sets the participant event up for further processing or closes the event.

To evaluate events, the system runs through the following sequence for each plan type:

Benefits Administration uses the eligibility rules that you have defined to determine the participant's eligibility as of the effective date of the event.

For example, if a participant has moved from full-time to part-time status, he might be ineligible for current elections and would need to select from part-time plan options.
If the event causes the participant to lose eligibility for current elections, the event is prepared for further processing, regardless of how you defined your event rule.

At a minimum, the system terminates the participant's newly ineligible elections. If the participant selects a new election within the plan type, the prior election is replaced as of the new election coverage and deduction begin dates.
If the event rule has the Use History check box selected, the eligible options as of the event date are compared to the prior eligible options.

If the participant has gained eligibility to new options, Benefits Administration prepares the event for further processing and enables new enrollment elections.

If the event rule does not have the Use History check box selected, the Select Allowed field controls further processing of the event. For example, for a family status change, plan type 10 (Medical), Select Allowed could be set to change the coverage code only. The options prepared by the system are only those within the same benefit plan as the current enrollment.

Loss of eligibility to a current election takes priority over event rule selection for both Use History and Select Allowed. The system's selection for Use History takes priority over Select Allowed.

Recommended Event Rule Definitions for FSC and HIR Events

This table lists the recommended event rule definitions for family status change (FSC) and new hire (HIR) events:

Fields	FSC Event Class (commonly used for plan types 1x–3x, 6x)	HIR Event Class
Pre-enter	Yes.	No.
Use History	No. Typically, the event should be controlled by the Select Allowed setting.	No. If your organization uses multiple-jobs processing, you would typically select the Use History check box for the HIR event, and set the default method to one of the Current/Else settings.
Elect Required	Depends on company policy.	Depends on company policy.
Provide FlexCR Upon Default (provide flex credits upon default)	Depends on company policy.	Depends on company policy.
Default Method	Assign Cur Covrg Else Option (assign current coverage else option) and Assign Cur Covrg Else Low Opt (assign current coverage else low option) are typical selections.	Default to Lowest Elig Option (default to lowest eligible option) and Default to Option and Coverage are typical selections. If your organization processes employees with multiple jobs, use Assign Cur Covrg Else Low Opt or Assign Cur Covrg Else Option.
Select Allowed	Current Plan + Waive is the typical selection for plan type 1x. For plan types 2x and 3x, use All Plans. For plan type 6x, use Current Plan.	All Plans.
If currently Enrolled, or not participating Max Number of Change Levels (maximum number of change levels)	Use the same setting that you use for the Open Enrollment (OE) event class. This maximum number varies by plan type; 99 appears by default.	Not applicable for new hires with no current elections. The value 99 appears by default. You can set levels for hire; the system restricts what employees can choose.
Levels of Change w/o Proof (levels of change without proof)	Use the same setting that you use for the OE event class. This value varies by plan type; 99 appears by default.	Not applicable for new hires with no current elections.
Proof Required at Plan Level	Use the same setting that you use for the OE event class. This value varies by plan type; 99 appears by default. Proof required at plan level is typically used for life and accidental death and dismemberment (AD/D) plans.	Use the same setting that you use for the OE event class.
Amt. Proof Required (amount proof required)	Used for life and AD/D plans. The limit is linked to coverage amounts. The same limit by plan type is used across all event classes.	Use the same setting that you use for the OE event class.
If currently Waived Max Number of Change Levels	Use the same setting that you use for the OE event class.	Not applicable for new hires with no current elections (including waive).
Proof Required at Plan Level	Use the same setting that you use for the OE event class.	Use the same setting that you use for the OE event class.
Amt. Proof Required	Use the same setting that you use for the OE event class.	Use the same setting that you use for the OE event class.
Coverage Begins On the Event Date Month-Begin After Event Dt (month-begin after event date) On Pay Pd Begin after Event Date (on pay period begin after event date)	Depends on company policy. For FSC events, On the Event Date is a common selection.	Depends on company policy.
Waiting Period... Days Waiting Period... Months	On the Event Date is a common selection.	Depends on company policy.
Coverage Ends On the Event Date On Month-End after Event Date (on month end after event date) On Pay Pd Begin after Event Date	Depends on company policy.	Not applicable for new hires. On Event Date appears by default.
Grace Period Days Grace Period Months	Depends on company policy.	Not applicable for new hires. The value 0 (zero) appears by default.
Deduction + Flex Credits Begin 1st Full PayPd After Covg BgDt (first full pay period after coverage begin date) On CovgBegin Date (on coverage begin date) Pay Pd Containing Covg BegDt (pay period containing coverage begin date) Pay Pd Preceding Covg BegDt (pay period preceding coverage begin date)	Depends on company policy.	Do not use Pay Pd Containing Covg BegDt for HIR events. This can result in enrollments for which the benefits coverage begin date precedes the hire date. Use On CovgBegin Date instead.
Deduction + Flex Credits End On Covg End Date 1st Full PayPd after Event Dt Pay Pd Containing Event Date Pay Pd Preceding Covg EndDt	Depends on company policy.	Depends on company policy.

Recommended Event Rule Definitions for MSC, OE, and SNP Events

This table lists the recommended event rule definitions for miscellaneous (MSC), OE, and snapshot (SNP) events:

Fields	MSC Event Class	OE Event Class	SNP Event Class
Pre-enter	Yes. Common for MSC events. Saves data entry effort.	Yes. Common for OE events. Saves data entry effort.	No.
Use History	Yes. Common for MSC events.	No.	No.
Elect Required	Depends on company policy.	Depends on company policy.	No.
Provide FlexCR Upon Default (provide flex credits upon default)	Depends on company policy.	Depends on company policy.	Yes.
Default Method	Assign Cur Covrg Else Option and Assign Cur Covrg Else Low Option are common selections.	Assign Cur Covrg Else Option and Assign Cur Covrg Else Low Option are common selections, except for plan types 6x and 9x, which use Terminate Coverage.	Assign Cur Covrg Else Low Option.
Select Allowed	None. Use History controls whether the enrollment is allowed for an event.	All Plans.	All Plans.
If currently Enrolled, or not participating Max Number of Change Levels	Use the same setting that you use for OE events. This maximum number varies by plan type; 99 appears by default.	This maximum varies by plan type; 99 appears by default.	This maximum number varies by plan type; 99 appears by default.
Levels of Change w/o Proof	Use the same setting that you use for OE events. This value varies by plan type; 99 appears by default.	This value varies by plan type; 99 appears by default.	This value varies by plan type; 99 appears by default.
Proof Required at Plan Level	Use the same setting that you use for OE events. This value varies by plan type; 99 appears by default. Proof required at plan level is commonly used for life and AD/D plans.	This value varies by plan type; 99 appears by default. Proof required at plan level is commonly used for life and AD/D plans.	This value varies by plan type; 99 appears by default.
Amt. Proof Required	Used for life and AD/D plans. Limit is linked to coverage amounts. The same limit by plan type is commonly used across all event classes.	Used for life and AD/D plans. Limit is linked to coverage amounts. The same limit by plan type is commonly used across all event classes.	Used for life and AD/D plans. Limit is linked to coverage amounts. The same limit by plan type is commonly used across all event classes.
If currently Waived Max Number of Change Levels	Use the same setting that you use for OE events.	This maximum varies by plan type; 99 appears by default.	This maximum varies by plan type; 99 appears by default.
Proof Required at Plan Level	Use the same setting that you use for OE events.	This value varies by plan type; 99 appears by default. Proof required at plan level is typically used for life and AD/D plans.	This value varies by plan type; 99 appears by default. Proof required at plan level is typically used for life and AD/D plans.
Amt. Proof Required	Use the same setting that you use for OE events.	Used for life and AD/D plans. Limit is linked to coverage amounts. The same limit by plan type is typically used across all event classes.	Used for life and AD/D plans. Limit is linked to coverage amounts. The same limit by plan type is typically used across all event classes.
Coverage Begins On the Event Date Month-Begin On/Aft Event Dt On Pay Pd Begin after Event Dt	Depends on company policy. For MSC events, On the Event Date is the common selection.	On the Event Date is the common selection for OE events. The event date for OE events is equal to the period begin date for the Open Enrollment definition.	On the Event Date is the common selection for SNP events. The event date for SNP events is equal to the period begin date for the Snapshot definition.
Waiting Period... Days Waiting Period... Months	On the Event Date is a common selection for FSC events.	On the Event Date is a common selection for OE events.	Zero days and months.
Coverage Ends On the Event Date On Month-End after Event Dt On Pay Pd End After Event Dt	Depends on company policy.	Depends on company policy.	Depends on company policy.
Grace Period Days Grace Period Months	On the Event Date is a common selection for FSC events.	On the Event Date is a common selection for OE events.	On the Event Date is a common selection for SNP events.
Deduction + Flex Credits Begin 1st Full PayPd After Covg BgDt On CovgBegin Date Pay Pd Containing Covg BegDt Pay Pd ePreceding Covg BgDt	Depends on company policy.	Depends on company policy.	1st Full Pay Pd After Covg BgDt.
Deduction + Flex Credits End On Covg End Date 1st Full PayPd after Event Dt Pay Pd Containing Event Date Pay Pd Preceding Covg EndDt	Depends on company policy.	Depends on company policy.	1st Full Pay Pd After Covg BgDt.

Recommended Event Rule Definitions for TER Events

The Termination (TER) Event class assumes that the participant is not eligible for any benefit programs and that Consolidated Omnibus Budget Reconciliation Act (COBRA) enrollment is managed outside of Benefits Administration.

This table lists the recommended event rule definitions for TER events:

Fields	TER Event Class
Pre-enter	No.
Use History	No.
Elect Required	No.
Provide FlexCR Upon Default (provide flex credits upon default)	No.
Default Method	Terminate Coverage.
Select Allowed	None.
If currently Enrolled, or not participating Max Number of Change Levels	Not applicable; 99 appears by default.
Levels of Change w/o Proof	Not applicable; 99 appears by default.
Proof Required at Plan Level	Not applicable; 99 appears by default.
Amt. Proof Required	Not applicable; 99,999,999 appears by default.
If currently Waived Max Number of Change Levels	Not applicable; 99 appears by default.
Proof Required at Plan Level	Not applicable; 99 appears by default.
Amt. Proof Required	Not applicable; 99,999,999 appears by default.
Coverage Begins On the Event Date Month-Begin After Event Dt Month-Begin On/Aft Event Dt On Pay Pd Begin after Event Dt	Not applicable; On the Event Date appears by default.
Waiting Period... Days Waiting Period... Months	Not applicable; 0 (zero) appears by default.
Coverage Ends On the Event Date On Month-EndAater Event Dt On Pay Pd End after Event Dt	Depends on company policy. Selection is typically based on benefit claims processing agreements with carriers and participants.
Grace Period Days Grace Period Months	Depends on company policy.
Deduction + Flex Credits Begin 1st Full PayPd After Covg BgDt On CovgBegin Date Pay Pd Containing Covg BegDt Pay Pd Preceding Covg BegDt	Not applicable; 1st Full Pay Pd After Covg BegDt appears by default.
Deduction + Flex Credits End On Covg End Date 1st Full PayPd after Event Dt Pay Pd Containing Event Date Pay Pd Preceding Covg EndDt	Depends on company policy.

Defining Benefits Administration Actions for Event Rules

Use the Action Reason Table page to link personnel actions—such as promotions, transfers, terminations, salary increases, and leaves of absence—with action reasons that explain why the action took place. Each defined action and reason combination enables the system to classify and track the events that cause changes to employees' employment and benefit coverage status.

See Also

Defining Personnel Actions and Reasons

Setting Up Event Classes

To set up the types or classes of events for the Benefits Administration system to recognize, and to control the handling of event classes, use the Event Class table (BAS_EVENT_CLASS_GBL) component.

This section discusses how to define event classes.

Page Used to Set Up Event Classes

Page Name	Definition Name	Navigation	Usage
Event Class Table	BAS_EVENT_CLASS	Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Class Table, Event Class Table	Define the classes of events that the Benefits Administration system recognizes, and control how event classes are handled.

Defining Event Classes

Access the Event Class Table page (Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Class Table, Event Class Table).

This table shows default values for the event classes delivered by PeopleSoft Benefits Administration:

Event Class	Description	Event Class Use	Event Priority	Manual Events Allowed?
BIR	Birth	Specific Event Class	401	Selected
DIV	Divorce	Specific Event Class	403	Selected
FSC	Family status change	Specific Event Class	300	Selected
HIR	New hire	Specific Event Class	100	Deselected
MAR	Marriage	Specific Event Class	402	Selected
MSC	Miscellaneous	Default Event Class	400	Selected
OE	Open Enrollment	Open Enrollment Event Class	900	Deselected
SNP	Snapshot	Snapshot Event Class	50	Deselected
TER	Termination	Specific Event Class	200	Deselected

Specific Event Class	Select to designate an event class that is designed to match the Benefits Administration action entered on the Action/Reason page to call specific processing rules.
Open Enrollment Event Class	Select to indicate that open enrollment events are triggered for all employees associated with a particular open enrollment process.
Default Event Class	Select to indicate that the Benefits Administration action does not match any specific event class. For example, an employee undergoes a Leave of Action/Military Leave (LOA/MIL) action and action reason, and the Benefit Administration action value for that combination is MIL. If you have not defined any additional event classifications beyond those delivered by PeopleSoft Benefits Administration, the system processes the employee according to the event rules for the MSC class. It does not recognize MIL as a specific event class unless you define it that way.
Snapshot Event Class	Select to indicate that snapshot events are triggered for all employees associated with a particular snapshot process.
Event Priority	Enter the priority in which the system processes the event in situations in which multiple events take place on the same date. The system processes events associated with event classes with lower event priority values first.
Manual Events Allowed	Select if events associated with the event class can be inserted manually for an employee using the Review BAS Activity page.
Available through Self Service	Select to enable employees to elect or change benefit information based on the eligibility determinations that result from event processing in the selected class. This is linked to the Enroll In Benefits feature for the PeopleSoft eBenefits application. For example, you might not want employees to be able to enter or update election information after they experience a TER event.
Print Option	Specify the printing of enrollment forms or confirmation statements. You may, at times, create event classifications, which are meant for administrative use only. Event classifications should never be viewed by employees.
Days to Print	Enter the number of days prior to an event that an enrollment form prints. This accommodates future-dated events by holding the form for a reasonable time period just before the event is processed.

Defining Trigger Events

To set up passive events, use the Passive Event Definition (BAS_PASSIVE_EVENT) component.

This section provides an overview of event triggers and discusses how to:

Add events to the Benefits Administration (BAS) Activity table.
Define passive events.

Understanding Event Triggers

The system triggers events through employee data changes when:

An administrator opens an employee data page, such as the Personal Data page, and enters a change to employee information.
The employee enters a marital status or birth or adoption change through eBenefits.

To increase the efficiency of the Event Maintenance process, the system triggers job and non-job events from a variety of different tables. Job events are relevant to employment, such as hires, transfers, and terminations. Non-job events cause changes in your employees' personal or demographic information that affect benefits eligibility or elections.

This table describes the delivered non-job event triggers:

Non-Job Event	Cause	Processing Result
Date of birth change	Update to the non-effective-dated Date of Birth field on the Personal Data pages.	Generates a workflow notice to the benefits administrator.
Postal code change	Update to the effective-dated Postal Code field of the home address on the Personal Data pages. Also triggered if the effective date of the current home address is changed.	Generates a BAS_ACTIVITY trigger.
Service date change	Update to the non-effective-dated Service Date field on the Job Data - Employment Information page.	Generates a workflow notice to the benefits administrator.
State code change	Update to the effective-dated State field of the home address on the Personal Data pages. Also triggered if the effective date of the current home address is changed.	Generates a BAS_ACTIVITY trigger.

Note. Changes to birth and service dates generate a workflow notice, because they occur to fields that are not effective-dated under a correction action, and as such must be handled carefully. The appropriate action, if applicable, may be to reprocess an existing event.

Event triggers based on the Job table include changes to these fields in the Job Data component:

Action/Action Reason
Benefits Status
Benefits System Flag
Benefit Record Number
Business Unit/SetID
Company
Employee Class
Employee Type
Eligibility Config Field 1 - 9
Employee Status
FLSA Status
FTE
Full/Part-time Status
Grade
Location
Medicare
Officer Code
Paygroup
Regular/Temporary
Regulatory Region
Salary Administration Plan
Standard Hours
Union Code

Pages Used to Define Trigger Events

Page Name	Definition Name	Navigation	Usage
Review BAS Activity (review benefits administration system activity)	BAS_ACTIVITY	Benefits, Manage Automated Enrollment, Events, Review BAS Activity, Review BAS Activity	Add events into the BAS Activity table. You manually insert events to be processed according to event rules that map to the BAS action that you enter when you run the Benefits Administration process. You can also delete unwanted, but automatically triggered, events.
Passive Event Definition	BAS_PASSIVE_EVENT	Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Passive Event Definition, Passive Event Definition	Define passive events that are not initiated by data entry.

Adding Events to the BAS Activity Table

Access the Review BAS Activity page (Benefits, Manage Automated Enrollment, Events, Review Bas Activity, Review BAS Activity).

You can insert into the BAS Activity table only event classes that have the Manual Event Allowed check box selected in the Event Class table.

As delivered, you can insert two event classes manually: Family Status Change and Miscellaneous Status Change. You can also review and delete any type of unprocessed event with this page.

Note. The BAS Activity table displays unprocessed events only. As soon as Benefits Administration successfully processes an event, the system deletes it from the BAS Activity table.

Action Source	Identifies whether the event is due to a change in job data, personal data, or multiple job flags, or is a passive event. Possible action sources are: Manual: Manual event. PasBirthDt: Passive event - birthdate. PasSvcDt: Passive event - service date. JobChg: Job data change. MJChg: Multiple job indicator change. AddressChg: Address (state and postal) change.
All Jobs	Select to have the manual event trigger benefits processing for all possible jobs and not just the specific job (employment record number) entered for the event. For example, a manually entered FSC could impact benefits for all jobs. Note. This option is available if the Multiple Jobs feature is enabled.
Event Date	Displays the event date. If a job, address, or multiple job change triggers the activity, the event date is the effective date of the change. If a passive event triggers the activity, the event date is the date on which the limit represented by the event (a limit related to age or years of service, for example) was reached. The date for a manually entered event appears by default when the activity record for the event was inserted into the table through the Review Bas Activity page. You can change the event data if required.
Event Effseq (event effective sequence)	If more than one manual event exists for an employee for the same effective date, enter unique sequence numbers for each event.
BAS Action	Identifies the Benefits Administration action associated with this event as defined in the Action Reason table. Events triggered by job, address, multiple job indicators, and passive events are assigned codes from the Action Reason table. Manual events are given a code that is selected by the user entering the manual event record.
COBRA Action (Consolidated Omnibus Budget Reconciliation Act)	Identifies the COBRA action code associated with this event as defined in the Action Reason table (not entered for a manual event).

Defining Passive Events

Access the Passive Event Definition page (Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Passive Event Definition, Passive Event Definition).

Note. (USF) Passive event processing functionality is not applicable to most U.S. federal government agencies.

Passive Event Type	Select a passive event type. Delivered event types include employee birthdate and events based on an employee's service date.
Event Classification	Select an event classification. Of the delivered event classes, OE and Snapshot are not available.
Event Limit - Months and Event Limit - Days	Indicate how long after the birthday or service date the event will take place.

Example of Passive Event Definition

You might set up a passive event to determine which employees are eligible for certain benefits once they've worked for your organization for a year. To do this, you define a passive event with the service date event type and an event limit - months value of 12. The event classification for this example could be MSC, or it could be a new event classification created specifically to manage this passive event.

After you set up the passive event, the system calculates the difference between your employees' service dates and the process date, and it triggers the event for any employees with a difference of twelve months within the date range that you specify on the Benefits Administration process run control page. The system processes the passive event as an MSC event.

Note. Internally, when the Benefits Administration process runs, it processes passive events by inserting a BAS Activity record for each individual who meets the passive event criteria. From this point, the activity record is processed like any other event, which means that you can extend the passive event concept beyond that which is delivered. Do this by creating your own modified processes that insert the required BAS Activity rows.

Defining Event Rules

To define event rules, use the Event Rules Table (BAS_EVENT_RULES ) component.

This section provides an overview of event-rule definition and discusses how to:

Define basic rules for event classes.
Make a certificate available for enrollment.
Set evidence of insurability (EOI) and level rules.
Define date rules.

Understanding Event-Rule Definition

The Event Rules table components define how events are managed for benefit programs and benefit plan types. You link an event rule ID to each benefit program and benefit plan type that your organization offers through the Benefit/Deduction Program table.

In general, you link event rules to benefit programs only to determine when the benefit program participation takes effect and when flexible credits begin and end.

You set up more complicated event rules at the plan type level to help the system determine how to process the various classes of events for each plan type that you offer.

Note. You set up event rules at the program level by setting up rules for Plan Type 01 (the program level).

Pages Used to Define Event Rules

Page Name	Definition Name	Navigation	Usage
Event Rules Table - Event Rules	BAS_EVENT_RULES1	Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, Event Rules	Define basic event rules for event classes.
EOI and Level Rules (Evidence of Insurability and Level Rules)	BAS_EVENT_RULES1A	Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, EOI and Level Rules	Set EOI and level rules for event classes.
Event Rules Table - Date Rules	BAS_EVENT_RULES2	Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, Date Rules	Define date rules.
Event Rules	RUNCTL_BAS703B	Set Up HRMS, Product Related, Automated Benefits, Reports, Event Rules, Event Rules	Print event rule definitions.

Defining Basic Rules for Event Classes

Access the Event Rules Table- Event Rules page (Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, Event Rules).

Event Class

Use this group box to define rule information for an event class.

Event Classification	Select an event classification. You can have more than one event classification for an event rule to cover all expected contingencies and usages. Note. If the Event Classification field is left blank, that row becomes a wildcard and is used to manage any event processed by this rule for which no specific event classification behavior has been defined. This wildcard is difficult to troubleshoot because the system provides no indication as to when it was invoked, and thus can lead to unanticipated results. Use the wildcard feature cautiously.
Use History	Reviews the eligibility history of the participant's benefit plan option and the eligibility of the participant's current benefit plan option to determine whether the employee can change an election. If the lists of eligible options are the same, the participant is not allowed to make plan option changes. This setting is used to filter out events that do not result in an opportunity for an employee to change elections. If, after processing, the participant is eligible for new options, Benefits Administration prepares the event for further processing and enables new enrollment elections. If the participant has lost eligibility for one or more current elections, he or she can make a new election.
Pre-enter	Select to populate the Benefits Administration data entry pages with the participant's current elections for the plan type associated with the event rule. Doing so enables you to view current elections during data entry and change them as necessary. Current elections include the option code of the enrolled benefit plan and the coverage code, as well as dependent, beneficiary, and 401(k) investment elections. The system only pre-enters current elections if the participant's current option is in the participant's current eligible list of options. Note. You should avoid selecting Pre-enter for plan types 4x (Savings), 6x (FSA), and 9x (Vacation Buy/Sell) during open enrollment, because these plans types may legally require positive annual reenrollment.
Ignore Plan	Select to make changes to plan information without restrictions as to how often or when the changes are made. When this option is selected, the plan types linked to this event rules ID and event classification combination are unaffected by Benefits Administration processing. You can use this option to arrange for specific plan types to have automatic event processing only for major event classifications such as hires, terminations, and open enrollment, while leaving them unaffected by lesser event classifications. When you select Ignore Plan, the system selects and locks Ignore Dep/Ben Edits and Ignore Investment Edits. The system also sets Select Allowed to None, and all participate and waive level values to 99. Ignore Plan does not interfere with eligibility rule processing. It does not enable employees to stay in or enroll in plans for which they are no longer eligible. If participant plan eligibility does not change, the system gives employees their current coverage. But if participant plan eligibility does change—that is, if employees lose eligibility for their current plan—you need to set a default method of Assign Cur Covg Else Option, Assign Cur Covg Else Low Opt, or Assign Cur Covg Else None. With Ignore Plan selected, the system ignores: Change level maximums and proof required for changing levels. Plan-specific edits (life insurance settings, individual FSA (Flex Spending Account) maximums, vacation limits, and so on). Edits on dependent or beneficiary information. Edits on investment elections. The system continues to: Flag errors generated due to invalid setup, such as missing table entries or pay calendars. Require that the option code entered through data entry be a valid selection from the eligible plans on the program. Consider the coverage amount for all life and AD/D plans when evaluating coverage group maximums. Include the annual pledge on all FSA plans when evaluating total FSA maximums. Select Ignore Plan when your automatic benefits processing responsibility has to share (or completely abdicate) responsibility for the processing of certain plan types with an outside or manual process. Don't use it only to suppress the entry of elections. A Select Allowed value of None, an appropriate default method setting, and the Use History rule are generally sufficient to control employee involvement in benefit elections.
Elect Required (election required)	Select to note the absence of elections for this plan type as an error in the Benefits Administration Messages table.
Ignore Overage Dependent	Select to control when and how dependents are actually dropped from coverage. You can create a midyear event that allows overage dependents to remain covered until the open enrollment event, when they are dropped from the coverage.
Retain Covered Dependent	Select to enable employers to move employees from one plan to another, while maintaining the current coverage code and dependent elections (default plan). In case of no matching coverage, the system assigns the default coverage and the existing dependent is not retained. If the employee has lost eligibility for a current election and the default election is supplied, the system determines the plan for the default option and attempts to move that employee into an option with the default plan and the employee's current coverage code.
Ignore Dep/Ben Edits (ignore dependent or beneficiary edits)	Select to skip all checks for the presence of dependents or beneficiaries and bypass all edits on dependents or beneficiaries already present or entered with elections.
Provide FlexCR Upon Default (provide flex credit upon default)	Select if you want participants that appear by default in a plan type to continue to receive credits that are tied to the default plan type. When this check box is deselected for plan types 1x through 3x (plan types 1x through 2x for federal users), participants who accept election defaults do not receive any credits (general plan type credits or option-based credits) for those plan types. For employees who elect to have excess credits applied to an FSA plan type and who are not enrolled in an FSA plan type, and for whom the Default Method field is set to Default Option for Excess Credit, the system creates an enrollment for the employee with a contribution amount equal to the excess credits.
Ignore Investment Edits	Select to skip all checks for the presence of investments on savings plans and bypass all edits on investment elections already present or entered with elections.
Default Method	Indicates what happens when an employee does not select an election for a particular plan type. Values are: Assign Cur Covrg Else Option (assign current coverage else option): Select to assign and continue the participant's current coverage. If participants do not have current coverage, or have lost eligibility to current coverage, they are assigned to the default for the specific plan type, as defined in the Benefit/Deduction Program table. The participant must be eligible for the current election for it to be used as the default. Assign Cur Covrg Else None (assign current coverage else none): If the employee loses eligibility for the current plan, another plan is not set up to replace the old one. Assign Cur Covrg Else Low Opt (assign current coverage else low option): Select to assign and continue the participant's current coverage. If the participant has no current coverage, or if the participant has lost eligibility to current coverage, the system assigns the lowest-level option available, as defined in the Benefit/Deduction Program table. This option is not recommended for Savings, FSA, and Vacation Buy/Sell plan types. Default to Lowest Elig Option (default to lowest eligible option): Select to assign the lowest-level option for which the employee is eligible. This option is not recommended for Savings, FSA, and Vacation Buy/Sell plan types. Default to Option and Coverage: Select to assign the option marked for default on the Benefit Program Definition page. The participant must be eligible for the option for it to be used as the default. This option is not recommended for Savings, FSA, and Vacation Buy/Sell plan types. Default Option for Exc Credit: (default option for excess credit) Applicable only to FSA plan types. If the employee has indicated that excess credits should be directed to an FSA enrollment, this rule assigns the option marked for default on the Benefit Program Definition page and sets the annual pledge to the amount of the excess credits. The participant must be eligible for the option for it to be used as the default, and excess credits must exist. Note. During enrollment, the system does not create a zero-monetary annual pledge enrollment when excess credits do not exist, and any current FSA enrollment is terminated if not reelected by the employee. Terminate Coverage: Inserts a termination entry for the plan type covered by this event rule. This option is commonly used for FSA and Vacation Buy/Sell plan types, because employees are usually required to reenroll in them each year or lose coverage.
Allowable FSA Pledge Changes (allowable flexible spending account pledge changes)	Select either Increase or decrease to indicate whether employees can increase or decrease their FSA pledges based upon the event classification that is being processed. For example, if the event classification is Birth, employees can increase, but not decrease their FSA pledge. This field applies only to 6x plan types and should be set to N/A for all other plan types.

See Entering Benefit Elections.

Self-Service Configuration

Use this group box to define rules for the information that appears on the eBenefits application pages. Values are:

Collect Dep/Ben (collect dependent or beneficiary coverage)

Select this check box when you want the system to collect information pertaining to dependents and benefits and display that information on the eBenefit Summary and eBenefit Detail Information pages.

For 1x Health plans on the enrollment form, the system collects elections at the plan level. The system then derives the coverage code based on the dependents covered. When this check box is deselected, the system collects elections at the coverage code level for 1x plans on the enrollment form.

This works in conjunction with the Ignore Dep/Ben Edits check box on the Event Rules page.

Allow Dep/Ben Additions (allow dependent or beneficiary additions)

Select to indicate that an employee can add new dependents through the eBenefits enrollment process.

Collect Fund Allocations

When this check box is selected, the system collects the information pertaining to savings plans and displays that information on the eBenefit savings pages.

Certification

Certificate ID

Select from available certificates that will appear during self-service enrollment for this event class

Electable Options

Use this group box to define benefit plans to which employees can make changes, and to set up coverage codes.

Select Allowed

Provides a means for you to indicate which plan or plans an employee can select from among all eligible types of plans. Values are:

All Plans: Select to enable employees to select from any option within the list of eligible options for the event.
Current Plan: Select to indicate that employees can make changes only to the current plan.
Current Plan + Waive: Select to enable employees to change only coverage levels (eligible options), including electing Waive, within their currently enrolled benefit plan. However, if the employee's current election is a waive of the plan type, she can elect any eligible option within any benefit plan.

For example, an employee has single coverage and gets married and the new spouse has health coverage through her employer. They decide that covering both individuals under the spouse's benefit plan is a better choice. In this case, the employee is allowed to waive his current coverage because the spouse is adding the employee to the spouse's coverage.

Suppose that the employee in the example is married, and at the last open enrollment she waived health coverage because she was covered under the spouse's plan. Now suppose that the spouse terminates employment, thereby losing eligibility for the plan that covered both the spouse and the employee. In this situation (which is also considered an FSC event by most customers), the employee is allowed to enroll in any eligible option in the plan type.
None: Select to disallow employees from making any changes to their elected option (unless eligibility for their current option or plan has been lost, in which case the system automatically overrides this setting and allows All Plans.)

Coverage Code Control

Select to enable employees to change only coverage levels (eligible options) within their currently enrolled benefit plan (applies only to the 1x series of plans). Coverage code control rules specify the criteria you use to select a valid coverage code for presentation to the employee for election. The rule specifies one set of criteria that is used when current coverage is in effect, and another set of criteria to be used when no current coverage is in effect.

If an employee loses eligibility for his current benefit plan, the system automatically overrides this setting and allows all options.

When you select the Coverage Code Control check box, the Coverage Code Control group box appears, where you can define coverage types and indicators.

See Setting Up Coverage Codes.

Coverage Code Control

Use this group box to define parameters for coverage codes that help control the gain and loss of eligibility and who can be added to or dropped from coverage. The codes you define are for the event class.

To increase the number of covered person types, the event must be an increase in the number of eligible dependents such as marriage, birth, adoption, or placement for adoption. Coverage decrease is allowed only if a divorce, annulment, legal separation, death of spouse or dependent, or loss of dependent eligibility occurs.

Note. For the system to enforce ERISA (Employee Retirement Income Security Act) rules, you must define coverage codes at the Covered Person Type level, rather than by Total Persons Covered. The system ignores ERISA rules if the coverage codes are defined by Total Person Covered.

Covered Person Type

Select a person category that determines how the person is to be processed by the system. In using covered person types, each relationship type that is eligible to enroll in benefits must be mapped to a covered person type. A given relationship code can map to zero or one covered person type code, while a particular covered person type code can map to one or more relationship codes.

You specify the rate separately for each type of person. You can use the same rate table ID for both employees who have adult children and those who do not. The system accumulates the rates for each dependent who is enrolled on the employee’s health election. If an employee has an adult child, the system adds the rate to the deduction. If an employee only has children who are not adult children, it will accumulate only at the regular child rate.

The following values are defined in the Dependent Relationship table. This table makes consistency across all types of covered persons possible, while allowing for new types of covered persons to be added in the future. The table is used as a child table of the Coverage Codes table.

Child
Adult Child
Dom Partner (domestic partner)
Employee
NQ Dependent (nonqualified dependent)
Oth Q Dependent (other qualified dependent)
Spouse

Same, More, and Less

The Same, More, and Less check boxes apply if the employee is already enrolled in a plan.

Select Same to keep the same number of covered persons in the plan. You can enroll more, less, or the same number of a particular covered person type. An example of using the Same, More, and Less check boxes to define covered person type might be in the case of a divorce event class. In a divorce, you might have more, the same, or fewer children enrolled depending on the situation. So you would select all three check boxes for the Child person type option.

Continuing with the divorce event class example, you would add a row, select the Spouse person type in the Covered Person Type field, and select the Less check box because the spouse will no longer be covered. Finally, you would select the Employee person type and select the Same check box. The coverage code control rule allows for all variations of a particular event class, so you could allow more and less in the same event classification. In addition the same, more, or less applies if the employee is already enrolled in a plan. The Coverage indicator on the right applies if the employee is newly enrolled in the plan.

Select Same to keep the same number of covered persons in the plan.

Select More to allow more covered persons to be added to the plan.

Select Less to allow fewer covered persons to be enrolled in the plan.

If No Current Coverage

Indicate the status of the covered person type enrollment if the employee is enrolling in the plan for the first time.

Allowed: Select to indicate that enrollment for the covered person type is allowed.
Not Allowed: Select to indicate that enrollment for the covered person type is not allowed.
Required: Select to indicate that enrollment for the covered person type is required.

Applying Defaults

The system applies defaults during the Benefits Administration process as it validates, loads, or finalizes participant elections. When you post a participant's election information for open enrollment and other events, you might not have elections for all plan types. Plan type defaults are used as substitutes for a participant's election when you finalize the event.

If you select Finalize for the participant, election defaults are validated and loaded for the plan types without elections and the plan types that are still in error.

Participants who have reached a process status of at least Prepared are finalized unless Benefits Administration encounters major errors in the final preparation. The finalizing of the process would be prevented, for example, if Benefits Administration encountered pay calendar issues while attempting to determine deduction end dates.

Making a Certificate Available for Enrollment

Two pages are available to which you can attach a certificate: Event Rules and Dependent Relationship.

Use the Event Rules component (BAS_EVENT_RULES1) to apply rules for the plan type selected in the Benefit program table. Enter a certificate ID that will be associated with the plan type selected and event rule defined.

The participant enrolls himself or herself into a benefit plan and if an administrator has decided that the plan requires a certificate, the participant is presented initially with a certificate to answer. If the participant passes the certification, he or she is allowed to enroll in the benefit plan. If the participant fails the certification, he or she is not be allowed to enroll in that particular plan type.
Use the Dependent Relationships Table component (DEPBEN_TYPE_TBL) to map a certification ID to a relationship.

The participant enrolls himself or herself into a benefit plan and if an administrator has decided that the plan requires a certificate, the participant is presented initially with a certificate to answer. If the participant passes the certification, his or her dependent is accepted. If the participant fails the certification, his or her dependent is defined as a beneficiary.

See Setting Up Benefits Certifications.

See Setting Up Dependent Relationships.

See Setting Up eBenefits.

See Reviewing Benefit Information.

Setting EOI and Level Rules

Access the EOI and Level Rules page (Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, EOI and Level Rules).

Use the Event Classification field to select the event class for which you want to define rules.

If currently Enrolled, or not participating

Use this group box to define rules that apply to an employee's participation in a benefit option following an event when the employee is currently participating in a plan or is new to a plan. These rules commonly apply to life, accidental death and dismemberment, and disability plan types, and are used to indicate the types of changes that employees can make.

Max Number of Change Levels (maximum number of change levels)	Indicates how many levels a participant can change or jump.
Levels of Change w/o Proof (levels of change without proof)	Indicates how many levels a participant can change without proof of good health or insurability.
Proof Required at Plan Level	Indicates the initial level at which proof of good health or insurability is required.
Amt. Proof Required (amount at which proof is required)	Enter the amount of coverage above which proof of good health or insurability is required.

If currently Waived

Use this group box to define rules that apply to an employee's participation in a benefit option following an event if the employee is currently opted out of the program.

Max Number of Change Levels (maximum number of change levels)	Indicates how many levels a participant can change.
Proof Required at Plan Level	Indicates the initial level at which proof of good health or insurability is required.
Amt. Proof Required (amount at which proof is required)	Enter the amount of coverage above which proof of good health or insurability is required.

Defining Date Rules

Access the Event Rules Table - Date Rules page (Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, Date Rules).

Use this page to set up date information for benefits.

Coverage Begins

Indicate when coverage begins following an event.

Values are:

Month-Begin After Event Dt (month begin after event date): Coverage begins on the first day of the following month.

If the event date is equal to the first of the month, coverage still begins on the first day of the following month.
Month-Begin On/Aft Event Dt (month begin on or after event date): If the event date equals the first of the month, coverage begins on the event date; otherwise, coverage begins on the first day of the following month.
On Pay Pd Begin after Event Dt (on pay period begin after event date): Coverage begins on the first day of the pay period following the event date.

If the event date equals the first day of the pay period, coverage begins on the event date.
On the Event Date: Coverage begins on the day of the event.

Waiting Period...

To calculate the date that coverage begins when a waiting period exists, the system:

Begins with the event date.
Adds the number of months.
Adds the number of days.
Applies the Coverage Begins rule to the resulting date.

Use Exist?

Select to enable the system to search for any waiting periods on prior events. If this option is selected, and a waiting period is found, the system honors the prior event's waiting period if the prior event's coverage begins date is later than the coverage begins date normally associated with the current event.

For example, new hires have a three-month period before their benefits become effective. Under this rule, an employee hired on November 1 has a health benefit election with a coverage begin date and deduction begin date of February 1.

Now, suppose that you've scheduled an open enrollment for January 1. During that time, the employee was processed for an open enrollment event. If the event rules for the open enrollment specify that the coverage begin date equals the event date, January 1, the employee would have a health benefit election posted with a coverage and deduction begin date that is earlier than the health benefit coverage and deduction begin date that the employee originally received when hired.

Selecting Use Exist? for the OE event rule would prevent this from happening because the system would preserve the waiting period from the employee's previous HIR event.

Days and Months

Enter the number of days and months for the system to use as a waiting period to begin coverage.

Coverage Ends

Select when coverage ends. The coverage end date is used only when an existing election within a plan type is truly terminating and not simply being superseded by another election (benefit option). In this case, the system inserts a new election row with Coverage Election set to Terminated.

If you select either On Month - End after Event Date or On Pay Pd End after Event Dt, the coverage begin date of this new row is one day after the calculated coverage end date for the current election. This occurs because this is the first date for which coverage no longer exists.

Grace Period Days and Grace Period Months

To establish a grace period before coverage is terminated, enter the appropriate number of days or months that the system uses to calculate the resulting end date in a manner similar to Waiting Period.

Deduction + Flex Credits Begin

Use this group box to indicate when deductions and flexible benefit credits should be taken. Values are:

1st Full PayPd After Covg BgDt (first full pay period after coverage begin date): Credits and deductions begin on the first day of the pay period following the coverage begin date, regardless of when the coverage begin day occurs within the pay period.
On CovgBegin Date (on coverage begin date): Credits and deductions begin on the date that benefit coverage for the plan type begins.
Pay Pd Containing Covg BegDt (pay period containing coverage begin date): Credits and deductions begin on the first day of the pay period containing the coverage begin date, regardless of when the coverage begin date occurs within the pay period.
Pay Pd Preceding Covg BegDt (pay period preceding coverage begin date): Credits and deductions begin on the first day of the full pay period that precedes the coverage begin date.

Deduction + Flex Credits End

Use this group box to indicate when deductions and flexible benefit credits should end. Values are:

1st Full PayPd after Event Dt (first full pay period after event date): Credits and deductions end on the first day of the pay period following the coverage end date, regardless of when the coverage begin day occurs within the pay period.
On CovgEnd Date (on coverage end date): Credits and deductions end on the date that benefit coverage for the plan type ends.
Pay Pd Containing Event Date (pay period containing event date): Credits and deductions end on the first day of the pay period containing the event date, regardless of when the coverage begin date occurs within the pay period.
Pay Pd Preceding Covg EndDt (pay period preceding coverage end date): Credits and deductions end on the first day of the full pay period that precedes the coverage end date.

Processing Events for COBRA Administration

Consolidated Omnibus Budget Reconciliation Act (COBRA) administration uses Benefits Administration processes to identify and process:

Initial COBRA events, which provide initial COBRA coverage to qualified COBRA participants and their dependents.
Secondary COBRA events, which extend coverage for COBRA participants and their dependents.

The initiation of a COBRA event differs according to your current implementation:

If you are currently working only with the Manage Base Benefits business process, the COBRA event is initiated by online PeopleCode.
With Benefits Administration, the COBRA event is initiated by Benefits Administration when a recognized COBRA action event is finalized.

The only exception to this rule is the Overage Dependent event, which is initiated by the COBRA process for both the Manage Base Benefits business process and Benefits Administration.

This table describes qualified COBRA events delivered by PeopleSoft, actions that trigger Benefits Administration to recognize these events as qualified COBRA events, and potential COBRA beneficiaries of the events:

Qualifying COBRA Event	User Action Trigger	Potential COBRA Beneficiaries
Loss of eligibility due to termination.	Employee status changes to terminated or suspended.	Employee and dependents.
Loss of eligibility due to reduction in hours.	Employee status remains active; standard hours decrease.	Employee and dependents.
Loss of eligibility due to retirement.	Employee status changes to retired.	Employee and dependents.
Loss of eligibility due to military leave.	Leave of Absence/Military Leave action/action reason entered for employee.	Employee and dependents.
Death of employee.	Employee status changes to deceased or FSC/DEA entered as action/reason code in the Job table.	All dependents.
Divorce.	Change in marital status of employee to divorced; change in status of spouse to ex-spouse. Family Status Change/Divorce action/action reason entered for employee.	Spouse.
Marriage of dependent.	Marital status of dependent changes to married. Family Status Change/Married Dependents action/action reason entered for employee.	Individual dependent.
Dependent reaches coverage age limit (overage dependent).	Not identified by Benefits Administration. (Benefits Administration does not automate passage of time events for dependents.) You must run the COBRA process to identify overage dependents.	Individual dependent.
Employee becomes entitled to receive Medicare.	Medicare entitlement date is reached. Family Status Change/Medicare Entitlement action/action reason is entered.	All dependents.

Defining Rules for Benefits Billing

To define benefit billing parameters, use the Billing Parameters (BILLING_PARAMETERS) component.

This section provides an overview of event processing for Benefits Billing and removing participants from Benefits Billing and discusses how to set up Benefits Billing enrollments.

Understanding Event Processing for Benefits Billing

The application of event rules for Benefits Billing enrollment is overridden in certain situations:

The system does not start billing if the employee is not enrolled in a plan or has waived coverage.
The system does not insert a billing termination if the employee is not actively enrolled in billing.
The system terminates active billing if the employee loses or waives coverage, regardless of the settings on this page.

If none of these situations applies, the system inserts a record into the Billing Enrollment table and sets the:

EmplID field to the employee's ID.
Employee Record Number field to the employee's employment record number.
Plan Type field to the plan type to bill.
COBRA Event ID field to zero.
Billing Status field to Active.
Billing Reason field to Ben Admin.

The system overlays existing billing enrollments if it encounters duplicate effective dates and inserts new active billing records, even if the employee is already being billed. The system carries forward a hold status from a previous billing enrollment.

Billing records are inserted during the close and finalization of the event. The system backs out billing records if Benefits Administration reprocesses an event to a point prior to the insertion of the billing enrollments. Billing records are not inserted for general deductions, benefit programs, leave plans, or vacation buy or sell plans (plan types 00, 01, 5x, and 9x).

The system inserts flat amount billing rows for savings, FSA, retirement, and pension plans (plan types 4x, 6x, 7x, and 8x). The way in which the system calculates deductions for these plans is not compatible with billing when no gross wages exist and no updating of payroll deduction balances occurs. The system issues a message to update the billing enrollments.

Removing Participants from Benefits Billing

The system deactivates Billing Enrollment records if:

The value in the Effect on Billing field on the Billing Rules page is End Billing.
The employee loses eligibility for the plan type.
The employee waives or terminates coverage.

The system inserts a new enrollment row for the participant when the billing status is set to Inactive and the effective date is based on the date set for the Billing Ends field. If eligibility is lost or coverage waived, the system sets the billing end date to be the date on which coverage ends, unless specific instructions say not to do so.

The system does not insert an inactive Benefits Billing enrollment record if the employee is already designated inactive for billing.

See Also

Setting Up Benefits Billing

Pages Used to Define Rules for Benefits Billing

Page Name	Definition Name	Navigation	Usage
Billing Rules	BAS_EVENT_RULES3	Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, Billing Rules	Define rules for Benefits Billing enrollments.
Event Rules-Billing	RUNCTL_BAS703B	Set Up HRMS, Product Related, Automated Benefits, Reports, Event Rules-Billing, Event Rules-Billing	List the parameters in which billing enrollments are created or updated during the Benefits Administration process.

Setting Up Benefits Billing Enrollments

Access the Event Rules Table - Billing Rules page (Set Up HRMS, Product Related, Automated Benefits, Eligibility and Event Rules, Event Rules Table, Billing Rules).

You can define a different set of Benefits Billing enrollment event rules for each event classification.

Rate Qualifier

Determines how to modify the deduction calculation for billing purposes.

Percent Based On

Select if the system should use the employee rate or the total rate to determine total charges if you select both Percent Calculation and Flat Amount.

Billing Takes Effect

Select an option to indicate when the billing action takes effect.

See Also

Enrolling Participants

Managing Benefits Billing

(USF) Setting Up Multiple, Concurrent Open Seasons

In the federal government, open seasons for various plan types are usually scheduled independently of each other, and their solicitation periods often overlap. In other words, a FEGLI (federal employees group life insurance code) open season may begin after a FEHB (federal employee health benefits) open season solicitation period has started.

In Benefits Administration for U.S. Federal Government, the ability to successfully run multiple, concurrent open enrollment processes depends upon two fields: Event Class and Event Rules ID.

To set up multiple, concurrent open seasons:

Define open enrollment event classes for each open season scheduled for your employees on the Event Class Table page.
Define open enrollment processes for each scheduled open season, and link to them the appropriate open season event classes.

Use the Open Enrollment Definitions page.
Define individual event rule IDs for each plan type available to your employees.

Use the Event Rules page.
With each event rule ID, associate the entire set of open enrollment event classes that you defined in step 1, by using the Date Rules page.
For each event rule ID, use Ignore Plan and Default Method functionality to disable Benefits Administration processing for all event classes linked to open seasons for plan types other than the one linked to the event rule ID.

For example, if an event rule ID is associated with the FEHB plan type, select Ignore Plan for all event classes not associated with FEHB open season events.

Use the proper default method to ensure that your employees are not automatically moved in and out of plans that are not part of the open season. The suggested default method is Assign Current Coverage Else None.
Once you've finished defining your event rule IDs, link them to their corresponding plan types by using the Benefit Program page.

Place FEHB event rule IDs with FEHB plan types, TSP (Thrift Savings Plans) event rule IDs with TSP plan types, and so on.
Run open enrollment processes as planned for your various open season events.

If you set up the system correctly, open enrollment for a FEGLI open season processes only plan types linked to the FEGLI event rule ID, open enrollment for a TSP open season processes only plan types linked to a TSP event rule ID, and so on. Your open enrollment processes can run concurrently as long as each process is associated with a different plan type or set of plan types.