Wiki: WORKFLOW IN OPEN ENROLLMENT

This is version . It is not the current version, and thus it cannot be edited.

Back to current version Restore this version

USING WORKFLOW WITH OPEN ENROLLMENT
Suitable Workflow in Open Enrollment
Notification of a Life / Work Event
Request Proof for Life or Work Events
Notification of a New Open Enrollment Period
Notification of Submission of Elections
Notification of Approved/Not Approved Elections
HR Changes Creating Open Enrollments
Scenario 1 – Employee Gets Married; the Married Date is Populated in IEPI:
Scenario 2 – An New Employee is Entered in Wiki
Suitable Proactive Workflow in Open Enrollment
Detecting Life Events
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
Notes

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:

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: 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

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: 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

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: 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

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 UserCalc 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: 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 work flow UserCalc.

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: 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 work flow UserCalc.

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 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

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 UserCalc.

Scenario 2 – An New Employee is Entered in Wiki#

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

Line	CMD	Type 1	Operand 1	OPER	Type 2	Operand 2	Type 3	Operand 3	If GOTO	Else GOTO
10	IF	CF	NewHire	EQ	B	TRUE			20	99999
20	ACT	AC	OE_NEWHIRE	LOG	$S	AS-OF-DATE	RT	Employee	99999
99999	EXIT

Line 10: This line checks to see if the custom function, NEWHIRE, equals True.
Line 20: This line will call the workflow action defined in IMWA for the new hire.

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

Line	CMD	Type 1	Operand 1	OPER	Type 2	Operand 2	Type 3	Operand 3	If GOTO	Else GOTO	Description
10	ACT	AC	OE STUDENT 2 OLD	LOG	$S	AS-OF-DATE	RT	42032	99999		<<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.
99999	EXIT

Line 10: This line calls the workflow action defined in IMWA (OE STUDENT 2 OLD) during the first step and will send an email to person code 42032.

Step 3 - Define Where Clause in IMWC or IMDAO Where Clauses are used in Wiki to conditionally select data from a table. In the case of Pro Active Work Flow, 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.

Type	Column Name	Operator	Value	Format Symbol
Ad Hoc	BIRTH_DATE	Is Not Null
Ad Hoc	BIRTH_DATE	Formatted Equals	<<AS_OF_DATE>>+1M-25y	MMyyyy
Ad Hoc	STUDENT_INDICATOR	Is Not Null

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

The UMPWF would be run with the following parameters:

Product	WF_ECT
UserCalc Code	WF_OE_STUD_2_OLD
Where Clause	OE_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

Line	CMD	Type 1	Operand 1	OPER	Type 2	Operand 2	Type 3	Operand 3	If GOTO	Else GOTO	Description
10	ACT	AC	OE_CHILD_2_OLD	LOG	$S	AS-OF-DATE	RT	42032	99999		<<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.
99999	EXIT

Line 10: This line calls the workflow action defined in IMWA (OE STUDENT 2 OLD) during the first step and will send an email to person code 42032.

Step 3 - Define Where Clause in IMWC Where Clauses are used in Wiki to conditionally select data from a table. In the case of Pro Active Work Flow, 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.

Type	Column Name	Operator	Value	Format Symbol
Ad Hoc	BIRTH_DATE	Is Not Null
Ad Hoc	BIRTH_DATE	Formatted Equals	<<AS_OF_DATE>> 0D+1M-19Y	ddMMyyyy
Ad Hoc	RELATION	In	05, 06, 07, 08

The UMPWF would be run with the following parameters:

Product	WF_ECT
UserCalc Code	WF_OE_CHD_2_OLD
Where Clause	OE_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

Line	CMD	Type 1	Operand 1	OPER	Type 2	Operand 2	Type 3	Operand 3	If GOTO	Else GOTO	Description
10	ACT	AC	OE REMINDER	LOG	$S	CURRENT-DATE	RT	Employee	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.
99999	EXIT

Line 10: This field calls the workflow action defined in IMWA.

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.

Type	Column Name	Operator	Value	Format Symbol
Ad Hoc	BOE_ID.ELECTION_CLOSE_DATE	Formatted Equals	<<AS_OF_DATE>> +7d	ddMMyyyy
Ad Hoc	ELECTION_STAGE	Equals	01
Ad Hoc	BOE_ID.OPEN_ENROLLMENT_STATUS	Equals	01

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

The UMPWF would be run with the following parameters:

Product	WF_BOEE
UserCalc Code	WF_OE_REMINDER
Where Clause	OE REMINDER

Notes #

Click to create a new notes page

Table of Contents

USING WORKFLOW WITH OPEN ENROLLMENT#

Suitable Workflow in Open Enrollment #

Notification of a Life / Work Event#

Request Proof for Life or Work Events#

Notification of a New Open Enrollment Period#

Notification of Submission of Elections#

Notification of Approved/Not Approved Elections#

HR Changes Creating Open Enrollments #

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

Scenario 2 – An New Employee is Entered in Wiki#

Suitable Proactive Workflow in Open Enrollment#

Detecting Life Events#

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#

Notes #