[{TableOfContents }]

!!!USING WORK FLOW WITH OPEN ENROLLMENT

Work flow 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:
*WF_BEV on the	[P2K_BE_EVENTS] table
*WF_BOEE on the	[P2K_BE_OPEN_ENROLLMENT_EES] table


----
!!!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 |EVENT_CODE]:Suggest prefixing all Open Enrollment workflow actions with OE. In this example, the where clause is named OE NEW L/W EVENT.
;[Status|EVENT_STATUS]:The status must be set to “In Production” in order for [IMUC] to recognize the action.
;[Triggered in Product |WORKFLOW PRODUCTS]: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 |EVENT_RECIPIENT_TYPE]: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 |EVENT_MEDIA]:The type can be email or message.
;[Email|MEDIA_NAME]: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 User Calc in IMUC|]
The second step requires a user calc to be created to send the email to the Administrator. 

;[User Calc|USER_CALC_CODE]:It is suggested to prefix the user calc code with WF_OE to easily identify the workflow user calcs for Open Enrollment.
;[Description|DESCRIPTION]:Should state what the user calc is meant for.
;[Product|PRODUCT_CODE]: 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|USER_CALC_STATUS]: In order for the action to be processed, the user calc must have a status of “In Production”. User calcs are published in [IMUCA].
;[User Calc Type |USER_CALC_TYPE]:All workflow user calcs must have the type set to ‘Calculation’.

__Lines__


||Line||CMD||Type 1||Operand 1||OPER||Type 2||Operand 2||Type 3||Operand 3||If GOTO||Else GOTO||Description
|10|IF|CF|INSERTING|EQ|B|TRUE| | |15 |99999 |
|15|If|DB|BET.OPEN_ENROLLMENT_TYPE|EQ|A|02| | |20|99999|
|20|ACT|AC|OE NEW L/W EVENT|LOG|$S|CURRENT-DATE|RT|42032|99999| |<<EID.FIRST_NAME>> <<EID.LAST_NAME>> has recorded a new life event, <<BET.BE_EVENT_TYPE_CODE>>  <<BEV.DESCRIPTION>>.
|99999|EXIT|AC| | | | | | | | |

Line 10: This line checks to see if an insert into the table has been done.

Line 15: This line checks to see if the Open Enrollment Type is 02 (Life / Work Event).

Line 20: This line calls the workflow action (OE NEW L/W EVENT) which was defined in the first step and will send the email notice to employee 42032. 

Line 99999: This line will indicate the end of the usercalc. 

----

!!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 |EVENT_CODE]:It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE PROOF REQ is used as the Action. 
;[Status |EVENT_STATUS]:This field must be “In Production” in order for [IMUC] to recognize the action.
;[Triggered in Product |WORKFLOW PRODUCTS]: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|EVENT_RECIPIENT_TYPE]: 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 |EVENT_MEDIA]:This field can be set to Email or Message.
;[Message|MEDIA_NAME]: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 user calc to be created to send the email to the Administrator.

;[User Calc|USER_CALC_CODE]: It is suggested to prefix the user calc code with WF_OE to easily identify the workflow user calcs for Open Enrollment. For example, WF_OE_PROOF_REQ.
;[Description|DESCRIPTION]: This field should state what the user calc is meant for
;[Product |PRODUCT_CODE]:This field should be set to WF_BEV
;[Status |USER_CALC_STATUS]: In order for the action to be processed the user calc must be published in [IMUCA]
;[User Calc Type|USER_CALC_TYPE]: All workflow user calcs must have a type of Calculation

__Lines__

||Line||CMD||Type 1||Operand 1||OPER||Type 2||Operand 2||Type 3||Operand 3||If GOTO||Else GOTO||Description
|10|IF|CF|INSERTING|EQ|B|TRUE| | |20|99999|
|20|IF|DB|BET.PROOF_REQUIRED|EQ|A|1| | | 30|99999|
|30|ACT|AC|OE PROOF REQ|LOG|$S|CURRENT-DATE|RT|Current Identity|99999| |Please submit proof of the event. Once proof has been submitted, the event will be processed and an Open Enrollment will be created. 
|99999|EXIT| | | | | | | | | |


Line 10 : This field checks to see if an insert into the table has been done

Line 20 : This field checks to see if the event requires proof

Line 30: This field calls the workflow action defined in the first step (OE PROOF REQ) and will issue a message to the current identity logged into the application. 

Line 99999: This line will indicate the end of the usercalc. 
----
!!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|EVENT_CODE]:It is suggested to prefix all Open Enrollment workflow actions with OE. For this example OE NEW PERIOD is used as the Action. 
;[Status |EVENT_STATUS]:This field must be set to In Production in order for the action to be picked up in [IMUC]
;[Triggered in Product |WORKFLOW PRODUCTS]:This field should be set to WF_BOEE since the email will fire when a new Open Enrollment Period is created
;[Action Directed To |EVENT_RECIPIENT_TYPE]:Since this action is going to the employees, ‘Employee’ should be chosen. 
;[Type |EVENT_MEDIA]:‘Email’ should be selected in this field.
;[Email |MEDIA_NAME]:The From email address must be specified. 
\\
;[Step 2 – Define User Calc in IMUC|]
;[User Calc|USER_CALC_CODE]: It is suggested that the user calc code should prefixed with WF_OE to easily identify the workflow user calcs for Open Enrollment. For this example, it may called WF_OE_NEW_PERIOD. 
;[Description |DESCRIPTION]: This field should state what the user calc is meant for.
;[Product|PRODUCT_CODE]:This field should be set to WF_BOEE.
;[Status|USER_CALC_STATUS]: In order for the action to be processed, the user calc must be published in [IMUCA].
;[User Calc Type|USER_CALC_TYPE]: All workflow user calcs must have a type of Calculation.

__Lines__

||Line||CMD||Type 1||Operand 1||OPER||Type 2||Operand 2||Type 3||Operand 3||If GOTO||Else GOTO||Description
|10|IF|CF |INSERTING|EQ|B|TRUE| | |20|99999| 
|20|ACT|AC|OE NEW PERIOD| LOG|$S|CURRENT-DATE|RT|Employee|99999| |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. 
|99999|EXIT| | | | | | | | | | 


Line 10 : This line checks to see if an insert into the table has been done, if so proceed with the rest of the user calc if not exit. 

Line 20: This line calls the workflow action (OE NEW PERIOD) defined in the first step and will send the email to the employees. 

Line 99999: This line will indicate the end of the usercalc.
----
!!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|EVENT_CODE]:It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE SUBMITTED will be used as the Action. 
;[Status|EVENT_STATUS]:This field must set to In Production in order for the action to be picked up in [IMUC].
;[Triggered in Product |WORKFLOW PRODUCTS]:This field should be set to WF_BOEE since the email will fire when a new Open Enrollment Period is created.
;[Action Directed To|EVENT_RECIPIENT_TYPE]:Since this is going to the administrator, Specific Employment should be chosen. 
;[Type|EVENT_MEDIA]:‘Email’ should be selected
;[Email|MEDIA_NAME]:The From email address must be specified
\\
;[Step 2: – Define User Calc in IMUC|]

;[User Calc|USER_CALC_CODE]: It is suggested that the user calc code should prefixed with WF_OE to easily identify the workflow user calcs for Open Enrollment. For this example WF_OE_EMAIL_SUB is used. 
;[Description |DESCRIPTION]: This field should state what the user calc is meant for.
;[Product |PRODUCT_CODE]: This field should be set to WF_BOEE.
;[Status |USER_CALC_STATUS]: In order for the action to be processed the user calc must be published in [IMUCA].
;[User Calc Type|USER_CALC_TYPE]:All workflow user calcs must have a type of Calculation.
\\
__Variables__

There are two variables required for this work flow user calc.

||Name||Type||Initial Value||Length
|new_election_stage|Char| |
|old_election_stage|Char| |


__Lines__
||Line||CMD||Type 1||Operand 1||OPER||Type 2||Operand 2||Type 3||Operand 3||If GOTO||Else GOTO||Description
|10|IF|CF|UPDATING|EQ|B|TRUE| | |15|99999|  
|15|LET|V|old_election_stage|EQNL|OV|BOEE.ELECTION_STAGE|A|01|16| |
|16|LET|V|new_election_stage|EQNL|NV|BOEE.ELECTION_STAGE|A|10|17| |
|17|IF|V|new_election_stage|NE|V|old_election_stage| | |20|99999| 
|20|IF|NV|BOEE.ELECTION_STAGE|EQ|A|10| | | 30|99999|
|30|ACT|AC|OE SUBMITTED|LOG|$S|CURRENT-DATE|RT|42032|99999| |<<EID.FIRST_NAME>> <<EID.LAST_NAME>> has submitted their benefit elections. 
|99999|EXIT| | | | | | | | | | 


Line 10 : This line checks to see if an update has been done.

Line 15 :This line sets a variable equal null to the old election stage.

Line 16 :This line sets a variable equal null to the new election stage.

Line 17: This line checks if the variable for old election stage does not equal the variable for the new election stage.

Line 20: This line checks if the new election stage equals 10 (Submitted).

Line 30: This line calls the workflow action defined in [IMWA] (OE SUBMITTED) and will email person code 42032. 

Line 99999: This will end the user calc. 


----
!!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 |EVENT_CODE]: It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE ELECTION APR is used. 
;[Status|EVENT_STATUS]: This field must be set to In Production in order for the action to be picked up in [IMUC].
;[Triggered in Product |WORKFLOW PRODUCTS]: This field should be set to WF_BOEE since the email will fire when the elections have been approved.
;[Action Directed To|EVENT_RECIPIENT_TYPE]: Since this action is going to the employee, ‘Employee’ should be chosen. 
;[Type|EVENT_MEDIA]:‘Email’ should be selected in this field.
;[Email|MEDIA_NAME]: The From email address must be specified. 
\\
;[Step 2: Define Workflow Action in IMWA – Action for Not Approved Elections|]
;[Action|EVENT_CODE]:It is suggested to prefix all Open Enrollment workflow actions with OE. For this example, OE ELECT NOT APR is used. 
;[Status|EVENT_STATUS]: This field must be set to In Production in order for the action to be picked up in [IMUC].
;[Triggered in Product |WORKFLOW PRODUCTS]:This field should be set to WF_BOEE since the email will fire when the elections are Not Approved.
;[Action Directed To|EVENT_RECIPIENT_TYPE]: Since this is going to the employee, ‘Employee’ should be chosen. 
;[Type|EVENT_MEDIA]: ‘Email’ should be selected in this field.
;[Email|MEDIA_NAME]: The From email address must be specified. 
\\

;[Step 3: – Define User Calc in IMUC|]

;[User Calc|USER_CALC_CODE]:It is suggested that the user calc code should prefixed with WF_OE to easily identify the workflow user calcs for Open Enrollment. For this example WF_OE_APR/NAPR is used. 
;[Description |DESCRIPTION]: This field should state what the user calc is meant for.
;[Product |PRODUCT_CODE]: This field should be set to WF_BOEE.
;[Status |USER_CALC_STATUS]: In order for the action to be processed, the user calc must be published in [IMUCA].
;[User Calc Type |USER_CALC_TYPE]: All workflow user calcs must have a type of Calculation.
\\
__Variables__

There are two variables required for this work flow user calc.

||Name||Type||Initial Value||Length
|new_election_stage|Char| |
|old_election_stage|Char| |

__Lines__

||Line||CMD||Type 1||Operand 1||OPER||Type 2||Operand 2||Type 3||Operand 3||If GOTO||Else GOTO||Description
|10|IF|CF|UPDATING|EQ|B|TRUE| | | 20|99999|
|20|LET|V|old_election_stage|EQNL|OV|BOEE.ELECTION_STAGE|A|10|30| | 
|30|LET|V|new_election_stage|EQNL|NV|BOEE.ELECTION_STAGE|  | |35| |
|35|IF|V|old_election_stage|NE|V|new_election_stage| | | 40|99999|
|40|IF|V|new_election_stage|EQ|A|50| | |50|60|
|50|ACT|AC|OE ELECTION APR| LOG|$S|CURRENT-DATE|RT|Employee|99999| |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>>. 
|60|IF|V|new_election_stage| EQ|A|92| | | 70|99999|
|70|ACT|AC|OE ELECT NOT APR|LOG|$S|CURRENT-DATE|RT|Employee|99999| |Your benefit elections have not been approved.  Your Open Enrollment has been re-opened for corrections.
|99999|EXIT| | | | | | | | | |


Line 10: This line checks to see if an update has been done.

Line 20: This line sets a variable equal null to the old election stage.

Line 30: This line sets a variable equal null to the new election stage.

Line 35: This line checks if the variable for old election stage does not equal the variable for the new election stage.

Line 40: This line checks if the new election stage equals 50 (Approved).

Line 50: This line calls the Approved workflow action defined in [IMWA]. 

Line 60: This line checks if the new election stage equals 92 (Not Approved).

Line 70: This line calls the Not Approved workflow action defined in [IMWA]. 


----
!!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|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|EVENT_CODE]: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|EVENT_STATUS]:This field must set to In Production in order for the action to be picked up in [IMUC].
;[Triggered in Product |WORKFLOW PRODUCTS]: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|EVENT_RECIPIENT_TYPE]:Since this is going to the employee, ‘Employee’ should be chosen. 
;[Type|EVENT_MEDIA]:‘Open Enrollment’ should be selected in this field. 
;[Open Enrollment|MEDIA_NAME]:The Event Code from [IBET] must be specified. 
\\
;[Step 2 – Define User Calc in IMUC|]
;[User Calc|USER_CALC_CODE]: It is suggested that the user calc code should prefixed with WF_OE to easily identify the workflow user calcs for Open Enrollment. For this example, it may called WF_OE_MARRIAGE. 
;[Description |DESCRIPTION]: This field should state what the user calc is meant for.
;[Product|PRODUCT_CODE]:This field should be set to WF_EPS.
;[Status|USER_CALC_STATUS]: In order for the action to be processed, the user calc must be published in [IMUCA].
;[User Calc Type|USER_CALC_TYPE]: All workflow user calcs must have a type of Calculation.


__Lines__


||Line||CMD||Type 1||Operand 1||OPER||Type 2||Operand 2||Type 3||Operand 3||If GOTO||Else GOTO
|10|IF|OV|EPS.MARRIED_DATE|NE|D|02-JAN-0001| | |99999| 20
|20|IF|NV|EPS.MARRIED_DATE|NE|D|02-JAN-0001| | |30|99999
|30|ACT|AC|CREATE MAR OE|LOG|$S|AS-OF-DATE|RT|Employee|99999| 
|99999|EXIT| | | | | | | | |

Line 10: This line checks to see if the old value for Married Date in [IEPI] does not equal 02-Jan-0001.

Line 20:This line checks to see if the new value for Married Date in [IEPI] does not equal 02-Jan-0001.

Line 30:This line calls the work flow action, CREATE MAR OE, that was defined in step 1 in [IMWA] which will cause an open enrollment for the marriage life event to be created.

Line 99999: This will end the user calc. 


!Scenario 2 – An new employee is entered in [{$applicationname}]

;[Step 1 - Define Workflow Action in IMWA|]
----
!!Proactive Workflow to Detect 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. 




!Scenario 2 – Child Recipient Has Surpassed the Maximum Child Age Limit. 
----
!Election Reminder
Reminder emails should be sent to employees who have not yet completed their elections, as requested by Benefit Administrators.