WORKFLOW IN OPEN ENROLLMENT

USING WORKFLOW WITH OPEN ENROLLMENT#

Workflow may be used in accordance with Open Enrollment to help make the process flow more fluidly and less cumbersome for the Benefit Administrator.

The following Workflow triggers have been added:



Suitable Workflow in Open Enrollment #

The following are example workflows that may be used to help ease the flow of the Open Enrollment process.

Notification of a Life / Work Event#

When an employee enters a qualifying life event, an email should be sent to the Benefit Administrator to notify them that the life event must be handled.
Step 1 - Define Workflow Action in IMWA
The first step is to define the workflow action in IMWA that will be triggered when an employee records a life or work event.
Action
Suggest prefixing all Open Enrollment workflow actions with OE. In this example, the where clause is named OE NEW L/W EVENT.
Status
The status must be set to “In Production” in order for IMUC to recognize the action.
Triggered in Product
This field should be set to WF_BEV since the email will fire when a new life event record is inserted in the P2K_BE_EVENTS table.
Action Directed To
Since this is going to a specific person, typically the person in charge of the benefit elections, Specific Employment should be chosen. The specific person code will be later defined in IMUC.
Type
The type can be email or message.
Email
If Email was specified for Type, the From email address must be specified. If Message was specified the Type, this field must be left blank.
Step 2 – Define UserCalc in IMUC
The second step requires a UserCalc to be created to send the email to the Administrator.
User Calc
It is suggested to prefix the UserCalc code with WF_OE to easily identify the workflow UserCalcs for Open Enrollment.
Description
Should state what the UserCalc is meant for.
Product
This field should be set to WF_BEV since the workflow action will fire when a new life event record is inserted in the P2K_BE_EVENTS table.
Status
In order for the action to be processed, the UserCalc must have a status of “In Production”. UserCalcs are published in IMUCA.
User Calc Type
All workflow UserCalcs must have the type set to ‘Calculation’.

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10IFCFINSERTINGEQBTRUE 15 99999
15IfDBBET.OPEN_ENROLLMENT_TYPEEQA02 2099999
20ACTACOE NEW L/W EVENTLOG$SCURRENT-DATERT4203299999 <<EID.FIRST_NAME>> <<EID.LAST_NAME>> has recorded a new life event, <<BET.BE_EVENT_TYPE_CODE>> <<BEV.DESCRIPTION>>.
99999EXITAC


Request Proof for Life or Work Events#

When a life or work event is entered that requires proof that the employee has not supplied, an email should be sent to the employee requesting proof.
Step 1 - Define Workflow Action in IMWA
The first step is to define the workflow action in IMWA that will be triggered when a life or work event is recorded that requires proof.
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE PROOF REQ is used as the Action.
Status
This field must be “In Production” in order for IMUC to recognize the action.
Triggered in Product
This field should be set to WF_BEV since the email will fire when a new life or work event is created.
Action Directed To
Since this is going to the user who created the life event, Current Identity should be chosen. Current Identity is used to display messages or emails to Self Service users.
Type
This field can be set to Email or Message.
Message
If Email was specified for Type, the From email address must be specified. If Message was specified the field must be left blank.
Step 2 – Define User Calc in IMUC
The second step requires a UserCalc to be created to send the email to the Administrator.
User Calc
It is suggested to prefix the UserCalc code with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For example, WF_OE_PROOF_REQ.
Description
This field should state what the UserCalc is meant for
Product
This field should be set to WF_BEV
Status
In order for the action to be processed the UserCalc must be published in IMUCA
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10IFCFINSERTINGEQBTRUE 2099999
20IFDBBET.PROOF_REQUIREDEQA1 3099999
30ACTACOE PROOF REQLOG$SCURRENT-DATERTCurrent Identity99999 Please submit proof of the event. Once proof has been submitted, the event will be processed and an Open Enrollment will be created.
99999EXIT

Notification of a New Open Enrollment Period#

When a Benefit Administrator opens up an Open Enrollment period, an email should be sent to the employees involved to inform them of this event and direct them to Self Service to make their elections.
Step 1 - Define Workflow Action in IMWA
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example OE NEW PERIOD is used as the Action.
Status
This field must be set to 'In Production' in order for the action to be picked up in IMUC
Triggered in Product
This field should be set to WF_BOEE since the email will fire when a new Open Enrollment Period is created
Action Directed To
Since this action is going to the employees, ‘Employee’ should be chosen.
Type
‘Email’ should be selected in this field.
Email
The From email address must be specified.
Step 2 – Define UserCalc in IMUC
User Calc
It is suggested that the UserCalc code should prefixed with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For this example, it may called WF_OE_NEW_PERIOD.
Description
This field should state what the UserCalc is meant for.
Product
This field should be set to WF_BOEE.
Status
In order for the action to be processed, the UserCalc must be published in IMUCA.
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10IFCF INSERTINGEQBTRUE 2099999
20ACTACOE NEW PERIOD LOG$SCURRENT-DATERTEmployee99999 A new benefit open enrollment period has been created for <<BOE.ELECTION_OPEN_DATE>> to <<BOE.ELECTION_CLOSE_DATE>> . Once you have logged into Self Service please navigate to My Benefit Elections where you will be prompted with instruction to review and submit your benefit elections.
99999EXIT

Notification of Submission of Elections#

When an employee submits their elections for approval, an email should be sent to the Benefit Administrator to notify them of the activity.
Step 1- Define Workflow Action in IMWA
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE SUBMITTED will be used as the Action.
Status
This field must set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_BOEE since the email will fire when a new Open Enrollment Period is created.
Action Directed To
Since this is going to the administrator, Specific Employment should be chosen.
Type
‘Email’ should be selected
Email
The From email address must be specified
Step 2 – Define User Calc in IMUC
User Calc
It is suggested that the UserCalc code should prefixed with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For this example WF_OE_EMAIL_SUB is used.
Description
This field should state what the user calc is meant for.
Product
This field should be set to WF_BOEE.
Status
In order for the action to be processed the UserCalc must be published in IMUCA.
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.

Variables There are two variables required for this workflow UserCalc.

NameTypeInitial ValueLength
new_election_stageChar
old_election_stageChar

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10IFCFUPDATINGEQBTRUE 1599999
15LETVold_election_stageEQNLOVBOEE.ELECTION_STAGEA0116
16LETVnew_election_stageEQNLNVBOEE.ELECTION_STAGEA1017
17IFVnew_election_stageNEVold_election_stage 2099999
20IFNVBOEE.ELECTION_STAGEEQA10 3099999
30ACTACOE SUBMITTEDLOG$SCURRENT-DATERT4203299999 <<EID.FIRST_NAME>> <<EID.LAST_NAME>> has submitted their benefit elections.
99999EXIT

Notification of Approved/Not Approved Elections#

When elections have been approved and have been turned into enrollments or when an election has not been approved, an email is sent to an employee to notify them of the activity. One email should be sent for all the employee elections rather than one email per plan.

Two workflow actions are defined, one for the approved elections and one for the not approved elections.

Step 1 - Define Workflow Action in IMWA – Action for Approved Elections
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE ELECTION APR is used.
Status
This field must be set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_BOEE since the email will fire when the elections have been approved.
Action Directed To
Since this action is going to the employee, ‘Employee’ should be chosen.
Type
‘Email’ should be selected in this field.
Email
The From email address must be specified.
Step 2 - Define Workflow Action in IMWA – Action for Not Approved Elections
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE ELECT NOT APR is used.
Status
This field must be set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_BOEE since the email will fire when the elections are Not Approved.
Action Directed To
Since this is going to the employee, ‘Employee’ should be chosen.
Type
‘Email’ should be selected in this field.
Email
The From email address must be specified.

Step 3 – Define User Calc in IMUC

User Calc
It is suggested that the user calc code should prefixed with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For this example WF_OE_APR/NAPR is used.
Description
This field should state what the UserCalc is meant for.
Product
This field should be set to WF_BOEE.
Status
In order for the action to be processed, the UserCalc must be published in IMUCA.
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.

Variables There are two variables required for this workflow UserCalc.

NameTypeInitial ValueLength
new_election_stageChar
old_election_stageChar

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10IFCFUPDATINGEQBTRUE 2099999
20LETVold_election_stageEQNLOVBOEE.ELECTION_STAGEA1030
30LETVnew_election_stageEQNLNVBOEE.ELECTION_STAGE 35
35IFVold_election_stageNEVnew_election_stage 4099999
40IFVnew_election_stageEQA50 5060
50ACTACOE ELECTION APR LOG$SCURRENT-DATERTEmployee99999 Your benefit elections have been approved and will be processed into Payroll. You should expect to see these election changes for the pay period that includes <<BOE.COVERAGE_EFFECTIVE>>.
60IFVnew_election_stage EQA92 7099999
70ACTACOE ELECT NOT APRLOG$SCURRENT-DATERTEmployee99999 Your benefit elections have not been approved. Your Open Enrollment has been re-opened for corrections.
99999EXIT

HR Changes Creating Open Enrollments #

Workflow may be used to trigger an open enrollment when an HR change is entered in the system. For example, an event and open enrollment may be automatically created when a new hire is entered in the system or when an employee is hired.

The event must be defined in IBET and the Allow Auto Open Enrollment toggle must be checked ON in IBET, in order for the open enrollment to be generated for the HR change. If the toggle is not checked, then the event will still be created but the Open Enrollment will not be. If proof is required for the event, the event will be created but not the Open Enrollment.

Scenario 1 – Employee Gets Married; the Married Date is Populated in IEPI:#

Step 1 – Define Workflow Action in IMWA
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, CREATE MAR OE will be used as the Action.
Status
This field must set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_EPS since the trigger will fire when a Marriage Date is entered in IEPI for the employee.
Action Directed To
Since this is going to the employee, ‘Employee’ should be chosen.
Type
‘Open Enrollment’ should be selected in this field.
Open Enrollment
The Event Code from IBET must be specified.

Step 2 – Define User Calc in IMUC
User Calc
It is suggested that the UserCalc code should prefixed with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For this example, it may called WF_OE_MARRIAGE.
Description
This field should state what the UserCalc is meant for.
Product
This field should be set to WF_EPS.
Status
In order for the action to be processed, the UserCalc must be published in IMUCA.
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTO
10IFOVEPS.MARRIED_DATENED02-JAN-0001 99999 20
20IFNVEPS.MARRIED_DATENED02-JAN-0001 3099999
30ACTACCREATE MAR OELOG$SAS-OF-DATERTEmployee99999
99999EXIT

Scenario 2 – An New Employee is Entered in Personality#

Step 1 - Define Workflow Action in IMWA
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE NEWHIRE will be used as the Action.
Status
This field must set to 'In Production' in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_EASD.
Action Directed To
Since this is going to the employee, ‘Employee’ should be chosen.
Type
‘Open Enrollment’ should be selected in this field.
Open Enrollment
The Event Code from IBET must be specified.

Step 2 – Define User Calc in IMUC
User Calc
It is suggested that the UserCalc code should prefixed with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For this example, it may called WF_OE_NEWHIRE.
Description
This field should state what the UserCalc is meant for.
Product
This field should be set to WF_EASD.
Status
In order for the action to be processed, the UserCalc must be published in IMUCA.
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTO
10IFCFNewHireEQBTRUE 2099999
20ACTACOE_NEWHIRELOG$SAS-OF-DATERTEmployee99999
99999EXIT


Suitable Proactive Workflow in Open Enrollment#

Detecting Life Events#

A proactive workflow is needed to detect significant milestones that affect benefits such as a child turning 18. An email should be sent to the Benefit Administrator to notify them that this event must be handled.

Scenario 1 - Student Recipient Will Surpass The Maximum Student Age Limit Next Month. #

Step 1 - Define Workflow Action in IMWA
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE STUDENT 2 OLD will be used as the Action.
Status
This field must set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_ECT since the workflow action is based on the P2K_HR_CONTACTS table.
Action Directed To
Since this is going to a specific person, typically the person in charge of the benefit elections, Specific Employment should be chosen. The specific person code will be later defined in IMUC.
Type
This field can be set to either Email or Message.
Email
If Email was specified for Type, the From email address must be specified. If Message was specified this field must be left blank.

Step 2 – Define User Calc in IMUC
User Calc
It is suggested to prefix the UserCalc code with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For example, WF_OE_STUD_2_OLD.
Description
This field should state what the UserCalc is meant for
Product
This field should be set to WF_ECT.
Status
In order for the action to be processed the UserCalc must be published in IMUCA
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.
Usage
Pro active workflow must have a usage of Pro-Active WF

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10ACTACOE STUDENT 2 OLD LOG$SAS-OF-DATERT4203299999 <<EID.FIRST_NAME>> <<EID.LAST_NAME>> student child recipient, <<ECT.FIRST_NAME>> <<ECT.LAST_NAME>> , is turning 25 next month. The student will surpass the maximum student age defined for the benefit.
99999EXIT

Step 3 - Define Where Clause in IMWC or IMDAO Where Clauses are used in Personality to conditionally select data from a table. In the case of Pro Active WorkFlow, they are created to help the system filter data based on the specified criteria. This is done so that the UserCalcs do not have to be created with the conditions defined which helps ease the amount of work required by the back end processes. As a result, by the time the UserCalc is called the data has already been filtered down to the appropriate records.

This example first filters the all of the data in the P2K_HR_CONTACTS table for birth dates that are not null.

The system then filters the data to determine if any of the contacts are turning 25 next month. The system is told to do this by using the Operator ‘Formatted Equals’ and the value being <<AS_OF_DATE>> +1M-25y, the format symbol should be MMyyyy.

The system then filters the data further by checking to see which records have the student indicator turned on in IECT.

Data Source
The table in which the data in the where clause is retrieved from. For this example, the P2K_HR_CONTACTS table must be defined.
Where Clause
This field holds the name of the UserCalc. For this example, OE_STUDENT_2_OLD will be used.
Usage
The usage of the where clause is stated here. For this example, 'User Defined' must be selected.
Description
This field holds a brief description of the intent of the where clause.

TypePredefinedColumn NameOperatorValueFormat Symbol
Ad Hoc BIRTH_DATE Is Not Null
Ad Hoc BIRTH_DATEFormatted Equals <<AS_OF_DATE>>+1M-25yMMyyyy
Ad Hoc STUDENT_INDICATORIs Not Null


Step 4 - Run UMPWF to Start the Pro-active Workflow The UMPWF function must be run to start the pro-active workflow. The idea behind the UMPWF is that the pro active workflow UserCalcs can be scheduled to run on a regular basis.

The UMPWF would be run with the following parameters:

ProductWF_ECT
UserCalc CodeWF_OE_STUD_2_OLD
Where ClauseOE_STUDENT_2_OLD

Scenario 2 – Child Recipient Has Surpassed the Maximum Child Age Limit. #

Step 1 - Define Workflow Action in IMWA
Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE_CHILD_2_OLD will be used as the Action.
Status
This field must set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_ECT since the email will fire when a contact surpasses the coverage age restriction.
Action Directed To
Since this is going to a specific person, typically the person in charge of the benefit elections, Specific Employment should be chosen. The specific person code will be later defined in IMUC.
Type
This field can be set to either Email or Message.
Email
If Email was specified for Type, the From email address must be specified. If Message was specified this field must be left blank.

Step 2 – Define User Calc in IMUC
User Calc
It is suggested to prefix the UserCalc code with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For example, WF_OE_CHD_2_OLD.
Description
This field should state what the UserCalc is meant for
Product
This field should be set to WF_ECT.
Status
In order for the action to be processed the UserCalc must be published in IMUCA
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.
Usage
Pro active workflow must have a usage of Pro-Active WF

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10ACTACOE_CHILD_2_OLDLOG$SAS-OF-DATERT4203299999 <<EID.FIRST_NAME>> <<EID.LAST_NAME>> has a child recipient, <<ECT.FIRST_NAME>> <<ECT.LAST_NAME>>, who is turning 18 next month. This child may no longer qualify for their benefits.
99999EXIT

Step 3 - Define Where Clause in IMWC Where Clauses are used in Personality to conditionally select data from a table. In the case of Pro Active workflow, they are created to help the system filter data based on the specified criteria. This is done so that the UserCalcs do not have to be created with the conditions defined which helps ease the amount of work required by the backend processes. As a result, by the time the UserCalc is called the data has already been filtered down to the appropriate records.

Where clauses can be created in either IMWC or IMDAO.

This where clause filters the birth date and as of date to be next month minus 19 years ago. The where clause is also filtering for son, daughter, step-son and step-daughter.

This example first filters the data for birth dates that are not null.

The system then filters the data to determine who is turning 19 next month. The system is told to do this by using the Operator ‘Formatted Equals’ and the value being <<AS_OF_DATE>> +1M-19y, the format symbol should be ddMMyyyy.

The system then filters the data further by checking to see which contact records have the relation of 05 (daughter), 06 (son), 07 (step-daughter) and 08 (step-son).

Data Source
The table in which the data in the where clause is retrieved from. For this example, the P2K_HR_CONTACTS table must be defined.
Where Clause
This field holds the name of the UserCalc. For this example, OE_CHILD_2_OLD will be used.
Usage
The usage of the where clause is stated here. For this example, User Defined must be selected.
Description
This field holds a brief description of the intent of the where clause.

TypePredefinedColumn NameOperatorValueFormat Symbol
Ad Hoc BIRTH_DATEIs Not Null
Ad Hoc BIRTH_DATEFormatted Equals<<AS_OF_DATE>> 0D+1M-19YddMMyyyy
Ad Hoc RELATIONIn05, 06, 07, 08

Step 4 - Run UMPWF to Start the Pro-active Workflow The UMPWF function must be run to start the pro-active workflow. The idea behind the UMPWF is that the pro active workflow UserCalcs can be scheduled to run on a regular basis.

The UMPWF would be run with the following parameters:

ProductWF_ECT
UserCalc CodeWF_OE_CHD_2_OLD
Where ClauseOE_CHILD_2_OLD


Election Reminder#

Reminder emails should be sent to employees who have not yet completed their elections, as requested by Benefit Administrators.

Step 1 - Define Workflow Action in IMWA

Action
It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE REMINDER will be used as the Action.
Status
This field must set to In Production in order for the action to be picked up in IMUC.
Triggered in Product
This field should be set to WF_BOEE since the email will fire when a new Open Enrollment Period is created.
Action Directed To
Since this action is going to the employees, ‘Employee’ should be chosen.
Type
Email should be specified in this field.
Email
Since Email was specified for Type, the From email address must be specified.

Step 2 – Define User Calc in IMUC
User Calc
It is suggested to prefix the UserCalc code with WF_OE to easily identify the workflow UserCalcs for Open Enrollment. For example, WF_OE_REMINDER.
Description
This field should state what the UserCalc is meant for
Product
This field should be set to WF_BOEE.
Status
In order for the action to be processed the UserCalc must be published in IMUCA
User Calc Type
All workflow UserCalcs must have a type of 'Calculation'.
Usage
Pro active workflow must have a usage of Pro-Active WF

Lines

LineCMDType 1Operand 1OPERType 2Operand 2Type 3Operand 3If GOTOElse GOTODescription
10ACTACOE REMINDERLOG $SCURRENT-DATERTEmployee 99999 This is a reminder that the benefit open enrollment period will be closing on <<BOE.ELECTION_CLOSE_DATE>>. Please ensure that you make your election decisions and submit your choices on or before this date.
99999EXIT

Step 3 - Define Where Clause in IMWC Where Clauses are used in Personality to conditionally select data from a table. In the case of Pro Active workflow, they are created to help the system filter data based on the specified criteria. This is done so that the UserCalcs do not have to be created with the conditions defined which helps ease the amount of work required by the backend processes. As a result, by the time the UserCalc is called the data has already been filtered down to the appropriate records.

Where clauses can be created in either IMWC or IMDAO.

The where clause would filter through the open enrollment periods to locate those that are 'open' and whose close date is one week away from the as of date. The system will then filter through the open enrollment to locate employee open enrollments which are 'open' meaning they have not been submitted yet.

Data Source
The table in which the data in the where clause is retrieved from. For this example, the P2K_BE_OPEN_ENROLLMENT_EES table must be defined.
Where Clause
This field holds the name of the UserCalc. For this example, OE REMINDER will be used.
Usage
The usage of the where clause is stated here. For this example, User Defined must be selected.
Description
This field holds a brief description of the intent of the where clause.

TypePredefinedColumn NameOperatorValueFormat Symbol
Ad Hoc BOE_ID.ELECTION_CLOSE_DATEFormatted Equals<<AS_OF_DATE>> +7dddMMyyyy
Ad Hoc ELECTION_STAGEEquals01
Ad Hoc BOE_ID.OPEN_ENROLLMENT_STATUSEquals01

Step 4 - Run UMPWF to Start the Pro-active Workflow The UMPWF function must be run to start the pro-active workflow. The idea behind the UMPWF is that the pro active workflow user calculations can be scheduled to run on a regular basis.

The UMPWF would be run with the following parameters:

Product WF_BOEE
UserCalc CodeWF_OE_REMINDER
Where ClauseOE REMINDER

Notes #

Click to create a new notes page