Understanding Temporal Life Events

Fusion HCM Benefits Cloud
Understanding and Using Temporal Life Events

ORACLE WHITE PAPER APRIL 2017
Table of Contents
Table of Contents 0
Understanding and Using Temporal Life Events 1
What Are Life Events? 1
Life Events Determine if a Participant can Make or Change Benefits Elections 2
Detecting Temporal Life Events – Run the Processes 2
Reporting Using OTBI 3
Predefined Temporal Life Events 3
Using Detection Rules 3
Timeliness Rules 4
Eligibility Components 5
Derived Factors 5
Examples of Derived Factors 6
Length of Service 7
Compensation 7
How Are Derived Factor Boundaries Read by the Application? 7
Eligibility Profiles, including Variable Rate and Variable Coverage Profiles 8
When do the Recalculations to Coverage or Rates Take Place? 9
Where Are Temporal Life Events Most Effective? 9
Track Ineligible 9
Summary of Things to Consider before Setting up a Temporal Life Event 10
Alternative Method to Triggering and Detecting Temporal Life Events 10
Set Up Steps for Creating Temporal Life Events and a Worked Example 11
FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Set up Scenario 11
Prerequisites 11
Initial Processing 18
Run the Evaluate Temporal Event Participation Process 18
Run the Evaluate Life Event Participation Process 19
Troubleshooting 20
What to do when derived factors are not evaluated upon conversion and elig_per
and elig_per_opt are not populated 20
What to do when Derived factors are added to setup post implementation? 20
What to do if life events are not triggering 20
Understanding and Using Temporal Life Events

This white paper explains what temporal life events are, explains the different components that make up temporal life
events, and walks you through how to set up a typical temporal life event using an example. This white paper also
provides a summary of things to consider before setting up a temporal life event, and provides you with an alternative to
using temporal life events if you decide that you don’t want to use them for any reason. And finally, we provide
troubleshooting information to help you resolve any temporal life event issues.
What Are Life Events?

A life event is a change to a person’s personal status or employment that affects benefits participation. For example, a change to a
person’s assignment, marriage, the birth of a child, and so on. In Oracle Fusion Benefits we use these life events to determine when a
participant can make or change benefits elections.

Table 1: Types of Life Events
Type of Life Event Description
Explicit Either personal or work-related changes, such as an address change or assignment

transfer.
Scheduled Can be administrative, such as the company-wide addition of a new benefit, or open,
as in an open enrollment
Unrestricted Do not need to be scheduled during particular time periods, and do not require explicit
life event triggers. Useful for possible daily updates like savings plan enrollments.
Temporal One that occurs with the passing of time, such as an age threshold (reaching age 65)
or an anniversary of hire (reaching the sixth month of employment), the anniversary of
the person’s employment or a probationary period reached.
Note: Unrestricted, scheduled and temporal life events are delivered with the application (seeded), but explicit life events are customer-
created.
Examples of using temporal events in your business include life insurance coverage reductions due to age, the ability to enrol into
benefits coverage when a probation period is reached, increased/decreased benefits cost due to dependent age or length of service,
and so on.
You can use temporal life events on participants, spouses or dependents. You might want to detect an age changed life event based on
the participant’s spouse where eligibility or rates vary for a compensation object based on a spouse’s age.
Life Events Determine if a Participant can Make or Change Benefits Elections

In a nutshell, the changes that a user or administrator enters into the application, such as the change of address, a new company-wide
benefit or the birth of a child all update data in the database tables and columns. Once these changes to the data are detected, the life
event is triggered in Detected status; the administrator can run a process, such as a participation evaluation process, which analyses
the life events and eligibility and opens up the enrollment flow if a participant can make or change benefits elections.
Triggering life events in this way works well where the data in the database actually changes, but where the only change is the passing
of time, life events cannot be triggered in this way. To trigger temporal life events, you also need to instruct the application how to
calculate this eligibility criteria that changes over time. You do this by defining rules, that we call derived factors, for example, a rule for
people aged 65 and over. We’ll explain how derived factors work with temporal life events later in this document, but for now, you just
need to understand that temporal life events notify the system when a person crosses the minimum or maximum boundary of a derived
factor when no other life events are happening for the person and a mid-year change is needed.
Detecting Temporal Life Events – Run the Processes

Once you have set up your temporal life events, you need to run the Evaluate Temporal Event Participation process to detect them,
because they cannot trigger on their own, unlike other types of life events.
You can schedule the process to run on a regular basis such as nightly or weekly, depending on your temporal setup requirements.
The Evaluate Temporal Event Participation process detects the events, but you then also need to run the Evaluate Life Event
Participation process to determine eligibility, to evaluate the impact of the life event on the participant’s benefit and rate information, to
recalculate coverage, and so on. See Diagram 1 Participation Flowchart.
Note: Temporal life events can also be triggered when you run the life event process online from the Benefit Service Centre, from the
Enrollment work area.
Diagram 1: Participation Process Flowchart

Initial Processing
Once you’ve set up your temporal life events, you need to set the temporal boundaries to populate the Benefits tables initially. If these
markers are not set in the Benefits tables then ‘temporal’ cannot be calculated. To populate the table, just run any of the participation
evaluation processes, such as Evaluate Life Event Participation, Evaluate Scheduled Event Participation, Evaluate Temporal Event
Participation or Evaluate Unrestricted Event Participation. Run the process for everybody.
Once you’ve run the initial process, the tables are kept up to date by regularly running the participation evaluation processes as normal.
Reporting Using OTBI

You can use OTBI for reporting temporal life event data.
Predefined Temporal Life Events

The first component of temporal life events to discuss is what we deliver out of the box - we deliver six predefined temporal life event
types. You can use these predefined temporal life event types along with derived factors and eligibility profiles for the application to
detect data changes that occur with the passage of time, such as an age threshold or anniversar y of hire.
Table 2: Predefined Temporal Life Events
Name Type
Age Changed Derived age
Combined Age and Length of Service Changed Derived combination of age and length of service changed
Compensation Changed Derived compensation
Hours Worked in Period Changed Derived hours worked in period
Length of Service Changed Derived length of service
Total Percent Full Time Changed Derived total percent full time
You can also create your own temporal life events if you want to control triggering at a more granular level, or if you want to create a
combination for reporting flexibility that we don’t provide above. For example, you might need to report on the combination of age
change, location and becoming part time.
We describe setting up and using life events in Use Existing or Create New Temporal Life Event.
Using Detection Rules

When you run the participation evaluation process in temporal mode, a life event is created when the minimum or maximum boundary
is crossed as specified in the definition of the derived factor. The main question you need to ask is do you want these temporal life
events to be detected in all circumstances. If you do, do not use detection rules, but if you want to refine control, you can use these
detection rules identified in Table 2, When to use Detection Codes.

As a recommendation, we suggest that you do not leave the detection rule blank, and that you use ‘Do not detect past temporal events’
at the very least, otherwise all your temporal life events will be detected all the time when the participation processes run.
Table 3: When to use Detection Codes
Detection Code Business Reason
Do not detect past temporal events You want to prevent the detection of past temporal events while the application processes
the current life event. For example, if you need to correct old data from 2016 and this
change will now trigger the same temporal life event in 2017 (and you just want the 2017
temporal life event to trigger when appropriate).
Here is an example of when you might want to set to never detect past temporal events.
Let's say a person has 10 life events processed in the last decade. Depending on when a
past temporal event triggers, it might actually back out eight events. That causes a lot of
reprocessing work for the benefits administrator. They’ll probably need to go to the backed
up data to resolve.
Do not detect past or future temporal events Prevents temporal event detection while the application processes this life event. Use this
code with the delivered open and administrative events, or any other explicit events, when
you do not want to detect temporal events. For example, you don’t want to detect any
temporal life events during Open enrollment, as the Open enrollment process already
calculates age and any other time-based criteria anyway.
Never detect this temporal life event Prevents the automatic detection of a specific temporal event. Set this code for any
delivered temporal event, such as ‘Age Change’ or ‘Length of Service Change’, that you do
not want to detect, such as for mid-year changes.
For example, if the 'Age changed' life event is configured with "Never detect this temporal
life event" in the life event, while processing any other life events like 'new hire', 'open' or
while running the temporal process, this 'Age Changed' will not be detected.
Here is an example of when you might want to use the Never detect this temporal life event
detection code. Let's say it is 16th February 2017. Some temporal event occurs, such as
length of service or age change, and it becomes an Intervening event. You had a Gain
Dependent process on 15th January 2017. Then a Temporal event triggered on 14th
January. The intervening events can back out the already-processed event, since events
also need to process sequentially in time.
Note: The difference between Do not detect past or future temporal events and Never detect this temporal life event is that the
detection code, Do not detect past or future detection codes, can detect if the temporal life event is recognized on the exact day process
is run.
Timeliness Rules
You can use timeliness rules to configure the timing and processing of potential life events. For example, you can define the number of
days after the life event occurred beyond which the potential life event is not processed. You’d want to do this to handle old or stale
events due to data correction.
Then you can also define how you want the application to handle those potential life events that fall outside that time period. For
example, you can prevent the participation evaluation process from detecting them by configuring the application so that manual
intervention is required. Then the benefits specialist can decide how they should handle the event. Alternatively, you could void events
that fall outside the time period. However, if you want the participation evaluation process to detect all temporal life events, you would
not define a timeliness evaluation.
We describe setting up detection codes and timeliness rules in Set up Detection or Timeliness Rules.

Eligibility Components
The next component of temporal life events to consider is eligibility. To successfully set up and use temporal life events, you need to
understand how the eligibility components work together. Diagram 2, Eligibility Components, shows how all the eligibility components fit
together and the relationships between eligibility components. The components related to setting up temporal life events are circled.
Diagram 2: Eligibility Components
Derived Factors
The first eligibility component to describe is derived factors. A derived factor instructs the application how to calculate the eligibility
criteria that changes over time.
You can create six different types of derived factors.

Table 4: Six Types of Derived Factors
Type of Derived Factor Description
Age The determination rule specifies the day on which to evaluate the person's calculated
age for eligibility.
Example: If the determination rule is set to the first of the year, then the person's age
as of the first of the year is used to determine eligibility
Length of service Unit of measure for time amounts
A combination of age and length of service Unit of measure for time amounts
Compensation Unit of measure for monetary amounts
Hours worked Unit of measure for time amounts
Full-time equivalent You specify the minimum and maximum full-time equivalent percentage and whether to

use the primary assignment or the sum of all assignments when evaluating eligibility.
Example: If 90 to 100 percent is the percentage range for the sum of all assignments,
then a person who works 50 percent full-time on two different assignments is
considered eligible.
There are also rounding rules and minimums and maximums you can use with derived factors.
Examples of Derived Factors

The following scenarios illustrate how to define different types of derived factors:
Age
Benefits administrators frequently use age factors to determine:

» Dependent eligibility
» Life insurance and coverage rates
Age factors typically define a range of ages, referred to as age bands, and rules for evaluating the person's age. For example, you
could set of age bands to determine eligibility for life insurance rates that vary based on age. In our worked example later on in this
white paper, we’ll use the derived factor of Age 60 to 65.
Table 5: Using Age Derived Factors
Derived Factor Name Greater Than or Equal To Age Value Less Than Age Value
Age Under 25 1 25
Age 25 to 34 25 35
Age 35 to 44 35 45
Age 45 to 54 45 55
Age 55 to 64 55 65
Age to Use: Points to Consider
The Age to Use value that you select for an age derived factor determines whose birth date is used to calculate the derived age. The
most common value is Person's. You usually use Person's as the Age to Use setting. With this setting, each person's own birth date is
used to calculate age for eligibility evaluation.
Scenario: You select person's as the Age to Use value, and associate the age derived factor with a participant eligibility profile.
Result: The person’s eligibility is evaluated based on the age calculated from his or her own birth date.
Other Age to Use
To evaluate participant or dependent eligibility or rates based on another person's age, such as a spouse, child, or other dependent,
select a value other than Person's. For example, Temporal can be used on employee, spouse, dependents. Benefits enable you to
detect temporal Age Change life events based on the age of the participant's spouse. Use this feature if you define objects where
eligibility or activity rates vary based on a spouse's age.
Scenario: You select Person's oldest child as the Age to Use value, and associate this derived factor with a dependent eligibility profile.
Result: Eligibility for all dependents is based on the age of the participant's oldest child. For example, all dependents become ineligible
when the oldest child reaches the maximum age of eligibility.
Note: If you choose Inherited Age, the evaluation is based on the date of birth as defined in the person extra information flexfield.

Length of Service
A derived factor for length of service defines a range of values and rules for calculating an employee's length of service. The following
table shows an example of a set of length-of-service bands. You can use the length-of-service bands to determine eligibility for
compensation objects such as bonuses or severance pay.
Table 6: Using Length of Service Derived Factors
Greater Than or Equal To Length of Service

Derived Factor Name Less Than Length of Service Value
Value
Service Less Than 1 0 1
Service 1 to 4 1 5
Service 5 to 9 5 10
Service 10 to 14 10 15
Service 30 Plus 30 999
Length of Service Value
Compensation
A derived factor for compensation defines a range of values and rules for recognizing when the employee's compensation amount
changes.
The following table shows an example of a set of compensation bands. You can use the compensation bands to determine eligibility for
compensation objects such as bonuses or stock options.
Table 7: Using Compensation Derived Factors
Derived Factor Name Greater Than or Equal To Compensation Less Than Compensation Value
Value
Less than 20000 0 20,000
Salary 20 to 34000 20,000 35,000
Salary 35 to 49000 35,000 50,000
Salary 50 to 75000 50,000 75,000
Salary 75 to 99000 75,000 100,000
Salary 100 to 200000 100,000 200,000
Salary 200000 Plus 200,000 999,999,999
How Are Derived Factor Boundaries Read by the Application?

The boundaries are 'inclusive'. That means that the application allows the maximum value until the next value is reached. For example,
if the maximum was the whole number five, then the boundary is not met until the associated temporal value reaches the whole number
six. This prevents any gaps from occurring between the maximum of one derived factor and the minimum of the next. That’s because it
would not make sense for a person to move from a 21-25 age range to a 26-30 range one day after their 25th birthday as it would also
not be intuitive to setup the ranges as 21-25, 25-30.
Lengths of Service temporal derived factors work the same as Age temporal.
We describe setting up derived factors in Step 2, Create Your Derived Factors.
Eligibility Profiles, including Variable Rate and Variable Coverage Profiles

There are different types of profiles you can create to use with temporal life events, depending on your business needs.
A regular eligibility profile makes an employee eligible or ineligible for a benefits offering. If you want to determine if a person is eligible
for something, such as eligible for benefits once they’ve worked for the organization for 90 days, or if they’ve reached a certain age use
a regular eligibility profile and include the appropriate derived factors.
But if you want to use temporal life events to change a rate or coverage when an age or length of service is reached, for example, not
only do you create an eligibility profile to determine eligibility but you also create a variable rate or variable coverage profile as well. For
example, use a variable rate profile where the cost of life insurance increases or decreases when you reach a certain age.
Alternatively, use a variable coverage profile where you want to adjust or replace the standard coverage calculation when age or length
of service changes. For example, you want to reduce coverage by 0,5% when the participant reaches the age of 65.
Diagram 3 provides an example of the different ways of creating profiles, depending on whether you are creating a regular eligibility
profile to determine temporal eligibility, or whether you are creating a variable rate or variable coverage profile. For the variable rate
profile, it shows one variable rate profile for one insurance plan. In reality you would create a different derived factor for each age range
that you will associate with each variable rate with a different eligibility profile for each age range basing each on the appropriate
derived factor. The example variable rate profile shows an increase in the rate for life insurance by 15% for participants over the age of
65. Alternatively, for variable coverage it shows a reduction in coverage amount by 65 percent for participants over the age of 65. The
coverage of a participant over 65 who elected the 2x compensation option would be reduced to 1.35 percent of stated compensation
rather than 200 percent.
Irrespective of whether you create a variable coverage or variable rate profile you need to configure the application to let it know what
the change to the coverage or rate is, and how to apply that change. You do this by applying a calculation method to change the rate or
coverage. You also need to define a treatment rule that tells the variable coverage or variable rate amount to add to, multiply by,
subtract from or replace the coverage or rate amount. For example, if you are reducing coverage by 65 percent at the age of 65 for
participants who elected the 2x compensation option, you need to tell the application that it is a plan contribution that is going to be
affected, that you are going to subtract the amount from the 2x compensation coverage using a multiplier and which profile to use. You
can of course use a different method to change the coverage or the rate, such as replacing the coverage or adding to it – use which
method suits your business requirements best..
We describe how to do this in Step 7, Create a Variable Coverage Profile.
Other things to consider are changes to the rates if the rate is based on coverage. If you are using variable rate profiles you’ll need to
vary your standard rates and specify eligibility criteria, calculation method and how the calculation affects the rate.
You can, of course, create both a variable rate and coverage profile that includes a rate and coverage change – you might want to do
this for life insurance, for example, where the rate increases when the participant reaches 65 years old and the coverage also reduces.
Diagram 3: Examples of the Different Setup for the Various Profiles

When do the Recalculations to Coverage or Rates Take Place?
As we’ve previously mentioned, you create a derived factor (or factors) to use with all temporal life events – what the derived factor
does is to enable the event to be triggered – it is only when you create a variable rate or variable coverage profile, link it to the derived
factors and the age or length of service takes place that those re-calculations take place. For example, when someone reaches 65 the
calculations take place and reduce life coverage.
Where Are Temporal Life Events Most Effective?

You need to determine the most appropriate place in the plan design hierarchy where you want the temporal life event to be effective. It
is recommended that you place the temporal life events at program level if the employee can be offered new choices and be
expected to be able to make a change. For example the length of service change may offer new choices, so set
temporal up at program level. Alternatively, an age change may reduce coverage and increase costs but as the
employee cannot make any changes or does not need to review the detail in Self-Service Benefits, set temporal up
at a lower level. Overall, the temporal life event must be set up at highest level if the employee is expected to be
able to make a change.
It might be appropriate to use a variable rate profile where the variability is controlled by age, for example, 2x salary up to 64 then
reduce by 60% after that, but still effective at the plan level.
If you offer more than one program, it might be more appropriate for the temporal life event to be effective at a
different level.
Track Ineligible
You also need to track ineligible people and set the temporal boundaries so that the application can enter the data into the Benefits
tables and then compare the data once the life event is detected. For example, the application needs to be able to compare the
previous values with the later values. If these markers are not already set in the Benefits tables then the temporal cannot be calculated.
You can track ineligible people at many levels, program, plan in program, plan type, and so on. We recommend that you don’t
necessarily track ineligible people at the highest level, because it can result in performance issues – that’s because the application has
to write a lot of data to work out new electable choices at all levels when the participation process runs. Instead, we recommend that
you set it at level that the plans are effective. For example if temporal affects entry into a program we track ineligible setting at program

level, but if it is only for one plan then you should set it up at plan in program level instead. Expect performance issues as a result of a
huge increase in data generation if you track ineligible person records at all levels.
In our setup scenario that follows, a life insurance plan that reduces the coverage amount by 65 percent for participants over the age of
65, we’ll track ineligible people at plan-in-program level.
Summary of Things to Consider before Setting up a Temporal Life Event

So, to summarize, these are the main things to consider before setting up your temporal life events.
Table 2: Summary of Decisions Before Setting Up Temporal Life Evets
Decision Explanation
Whether to use the delivered temporal life Create your own if you want to control triggering at a more granular level than at which
events or create your own the delivered events provide. For example, to combine age change, location and
becoming part time.
Whether to use temporal detection rules If you want to control some, or all, temporal life events, such as the suppression of
automatic detection of specific temporal event or suppression of detection while the
application processes a specific life event, use temporal detection codes. As a
recommendation, we suggest that you do not leave the detection rule blank, and that
you use ‘Do not detect past temporal events’ at the very least, otherwise all your
temporal life events will be detected all the time when the participation processes run.
Where you want the temporal life event to be Overall, temporal life events must be setup at highest level if the employee is expected
effective to be able to make a change.
Where you want to track ineligible people We recommend that you don’t necessarily set it at the highest level, because it can
result in performance issues by writing a lot of data to work out new electable choice at
all levels. Instead, we recommend that you set it at level that the plans are effective.
Whether to create a variable rate or variable You would create a variable rate profile where the variability is controlled by age, such
coverage profile as 2x salary up to 64 years of age then reduce by 60% after that, or where coverage
increases or reduces based on length of service. If you want to use temporal life events
to determine if a person is eligible for something, such as being eligible for benefits
once they’ve worked in the organization for 90 days, or if they’ve reached a certain
age, create a regular eligibility profile instead and include the appropriate derived
factors.
Alternative Method to Triggering and Detecting Temporal Life Events

If triggering temporal life events is a concern for your organization, or if you want complete control of event detection instead of running
the Evaluate Temporal Event Participation process, don’t set up temporal life events but perform these steps instead:
1. Write a person selection rule that will determine who has an age change or the temporal event you are looking for.
2. Use the selection rule as a parameter in the Assign Corrective Potential Life Event process - this process will assign an event
to the person with an age change.
3. Schedule the Evaluate Life Event Participation process to run nightly. This process will pick up the event(s) created in step 2
and process them.
4. Based on your configuration the rates or coverage will be re-calculated appropriately.
However, there are some limitations if you use this method:

1. Selection rule has some limitations on events it can find
2. Can only assign one temporal life event at a time
3. Can only assign events as of date of run
4. Additional setup in plan design is required
Set Up Steps for Creating Temporal Life Events and a Worked Example
This section walks you through how to set up a typical temporal life event, using an example of an life insurance plan. It provides a
summary of things to consider before setting up a temporal life event, and the steps to go through to set one up. This white paper will
not cover the details of setting up benefit objects, such as plans, rates and eligibility profiles. These are already covered in the Global
Human Resources Cloud Implementing Benefits guide. However, we'll highlight the important fields to complete for setting up temporal
life events.
Set up Scenario
We’ll use the example of a life insurance plan. It will reduce the death coverage amount by 65 percent for participants over the age of
65. The coverage of a participant over 65 who elected the 2x compensation option would be reduced to 1.35 percent of stated
compensation – they’d receive that rather than the 200 percent they would have received under 65. The setup steps walk you through
exactly what you need to do. We’ll also explain how the temporal event runs at defined intervals to detect which participants have
reached the age of coverage reduction.
We’ll create a derived factor for each age range that we’ll associate with the variable coverage profile. We’ll create an eligibility profile
for each age range we create, basing each on the appropriate derived factor. The setup flowchart shows the overall flow for creating an
eligibility profile, and then creating both a variable rate and variable coverage profile for temporal life events, but in our example steps
we’ll only show you how to go through the variable coverage part of the flow.
Diagram 4: Setup Flowchart
Prerequisites

Before you create your temporal life events, you should have already created your programs, plans, standard rates, coverage and your
payroll elements.
1. Use Existing or Create New Temporal Life Event
If you want to create a new life event, such as to combine age change, location and becoming part time, use the Manage
Benefit Life Events task from the Plan Configuration work area. However, in our worked example, as we are setting up a life
insurance plan that reduces the coverage amount by 65 percent for participants over the age of 65, we can use the delivered
Age Changed temporal life event, and we don’t need to create a new life event.
2. Set up Detection or Timeliness Rules
Follow these steps if you want to use temporal detection or timeliness rules. We recommend that you do not leave the
temporal detection rules blank, otherwise temporal life events will be detected under all circumstances - we suggest at the
very least that you use “Do not detect past temporal events” which prevent the detection of past temporal events while the
application processes this life event. We also recommend that you set up timeliness rules for temporal processing, at the very
least.
In our worked example, we set up a temporal life event that triggers when the participant reaches 65. We do not want to
prevent the life event from triggering, but we don’t want them triggering under every circumstance, so we’ll use the detection
rule “Do not detect past temporal events”. We also want to set the number of days after the life event occurred beyond which
the potential life event is not processed.
a. Select the task Manage Benefit Life Events from the Plan Configuration work area, search for the predefined Age
Changed life event and click on the link. The Edit Life Event: Age Changed page displays.
b. Select Edit from the Actions menu and expand the Additional Information section.
c. These are the important fields for temporal:
 Select Do not detect past temporal events as the Temporal Detection Rule.
 Select Process potential life events manually as the Timeliness Evaluation. We are selecting this option
because we want the administrator to manually handle this life event rather than the participation evaluation
process detecting the potential life event if it falls outside the time period. (Alternatively, you could void all
potential life events of this type).
d. Enter 60 In the Timeliness Days field. This means, the application will continue to process that life event until 60
days after the life event occurred date. Best practice is to set 60 or 90 days for all events or as dictated by carrier or
business processes.
e. Save your changes.

3. Create Your Derived Factors
You create a derived factor (or factors) to use with all temporal life events. What the derived factor does is to enable the
events to trigger when the temporal processes are run.
You would create the appropriate derived factors for your business requirements, for example, you might need to create them
for age band 20 – 29, age band 30 – 39, and so on. But as our example is to create life insurance that reduces the coverage
amount by 65 percent for participants over the age of 65, we are only going to create two derived factors; one for 60 – 64 and
the other 65 and over, because the only change we need to trigger is when the participant reaches 65.
a. Select the task Manage Derived Factors from the Plan Configuration work area. The Age tab is the default, so
remain on the Age tab and click the Create button. The Create Derived Factor Age popup displays.
b. These are the important fields for temporal:
 As we are going to define two range of ages for our example, referred to as age bands, for age band 60 to 64
then age band 65 and Over, enter the first name which is Age 60 to 64 in the Name field.
 Select Person’s in the Age to Use field as we are creating a derived factor for the person’s age change. (This
field is used to indicate the kind of person, such as the participant, participant’s child, participant’s spouse, for
whom you are defining a derived age factor.)
 You could enter a calculation formula to calculate the person’s age, but there is no need in our example, so leave
this field blank.
 Select Years from the Units field.
 Enter 60 in the Greater than or Equal To Age, and enter 64 in the Less Than Age fields.
 Select First of Calendar Year from the Determination Rule field. (This rule defines how the system calculates an
employee’s length of service.) First of calendar year means that the person’s age as of the first of the year is
used to determine eligibility.
 Leave all other fields, including Rounding, blank. (The rounding rule specifies the level to which the application
rounds the results of this age factor calculation, but it isn’t required in our example).

c. Click Save and Close. Alternatively, click Save and Next to create the next age range which is Age 65 and over.
Remember the determination rule and other settings for each age band, apart from the name and years, are the
same.)
d. Once you’ve created your derived factors, you add them to eligibility profiles that define how eligibility is determined.
4. Create Eligibility Profiles

You now need include the derived factor you previously created in eligibility profiles. In our example, we’ll just walk you
through creating one Participant Eligibility Profile for Age 60 to 64, but we would also need to create one for Age over 65 too.
You would create as many eligibility profiles as required.
a. Select the task Manage Eligibility Profiles from the Plan Configuration work area and click the Create Participant
Profile button. (If you were using temporal life events on spouses or dependents, you would select Dependent
instead). .
b. The Create Participant Eligibility Profile page appears.
c. Name the eligibility profile in the Name field. In our example, we’ve called it Life Insurance Age 60 – 64.
d. As we are going to define a range of ages, referred to as age bands specifically the age band for 60 - 64, select the
Derived Factors tab, and then the Age tab.
e. Click the Create button on the Age tab, and the Sequence and Age fields appear.
f. This is the important field for temporal:
 Select the derived factor you previously created, which was Age 60 – 64 in the Age field, and 1 in the Sequence
field.
g. Save your changes. We’d follow the same steps to create an eligibility profile for over 65. Continue to create
eligibility profiles for each age band you created.

5. Create a Variable Rate Profile (Optional)
In our example, we don’t need to create a variable rate profile, so skip this step. But if you were creating a variable rate
profile, you could follow the same steps as defined in the section to create a variable coverage profile, then create or use a
standard rate and associate it with the variable rate profile.
6. Create a Standard Rate and Associate with Variable Rate Profile (Optional)
In our example, we don’t need to create a variable rate profile, so skip this step.
7. Create a Variable Coverage Profile (Optional)

You need to create a variable coverage profile if you want variability controlled by age or length of service, for example, to
increase or reduce coverage, otherwise skip this step. In our example, because we want to decrease the coverage by 65%
once the participant reaches 65, we’ll create a variable coverage profile. Coverage is calculated by applying a calculation
method. You also need to define a treatment rule that tells the variable coverage amount to add to, multiply by, subtract from
or replace the coverage amount.
a. Go to the Manage Benefits Rates task from the Plan Configuration work area.
b. Click the Variable Coverage Profiles tab and select Create.
c. These are the important fields for temporal:
 Enter the name of the variable coverage profile you are creating in the Profile Name field, for example, Life
Insurance – Age Reduction Over 65.
 Select After Tax in the Tax Type Rule field.
 Select Plan Contribution in the Activity Type field.
 Select Subtract From in the Treatment Rule field. This is because we want to subtract the amount from the
coverage.
 Select Monthly in the Defined Rate Frequency field. If you set up the frequency here, the imputed plan
uses the frequency defined for the variable rate.
 Select the profile you previously created in the Eligibility Profile field, for example, Life Insurance Age Over 65.
 Select Active in the Status field.
 Select Multiple of Compensation in the Calculation Method field.
 In the Multiplier region, enter .65 in the Multiplier field.
 In the Multiple of Compensation section, select Multiply by in the Operator field.
 Select Annual Stated Compensation in the Compensation Factor field.
d. Click Save and Close to return to the Variable Coverage Profiles tab.

e. Repeat the steps to create the additional variable coverage profiles, one for each age band. Remember to enter
new names in the Profile Name and Value fields to reflect the age bands.
8. Link the Eligibility Profile to a Compensation Object and Track Ineligible People
Irrespective of whether you create a variable rate or variable coverage profile or not, you now need to associate your eligibility
profiles with the programs and plans where you want to restrict or give eligibility. You must do this for each program or plan
for which you want to associate with temporal life events. In our example, you need to attach the eligibility for a life insurance
plan.
You also need to track ineligible people and set the temporal boundaries so that the application can enter the data into the
Benefits tables and then compare the data once the life event triggers. For example, the application needs to be able to
compare the pre under 65 age with the post 65 age. If these markers are not already set in the Benefits tables then the
temporal cannot be calculated.
a. Select the Plans task from Overview, Plan Configuration work area. Search for the plan you want to track ineligible
people and add the eligibility profile to and click on the link. In our example, that is Life Insurance.
b. Select the Eligibility train stop, and the Edit Plan Eligibility page opens.
c. Select the Life Events tab and select Add Life Event. The life event popup displays.
d. Select the Age Changed life event.
e. Select As of event date in the Start Date field – this is used as the date by which the participant can make changes
to their enrollments, or not, or as the date the new coverage or rate starts.
f. Save your changes.

g. Select the Configuration tab to track ineligible people. Specify this setting in the Eligibility Overrides section for the
plan or option.
h. Select the Track Ineligible Person check box to cause the system to track people who are found ineligible for
participation in this plan when the Participation batch process is run. You must check this field if you determine
benefits eligibility based on temporal factors, such as age or length of service.
i. Save your changes.

j. Select the Participation tab and select the Actions menu and select Update, and select the eligibility profile in the
Profile Name field you created, for example, Life Insurance Age Over 65.
k. Save and close.

9. Process Temporal Life Events
Initial Processing
Once you’ve set up your temporal life events, you need to set the temporal boundaries to populate the Benefits tables initially.
If these markers are not set in the Benefits tables then ‘temporal’ cannot be calculated. To populate the table, just run any of
the participation processes, such as the Life Event Participation. Run it for everybody in a scheduled process. Once you’ve
run this initial process, the tables are kept up to date by regularly running the evaluation processes as normal.
Run the Evaluate Temporal Event Participation Process

Run the Evaluate Temporal Event Participation Process to detect temporal life events, such as age or length of service
changes, for participants. The process determines temporal life events based on the derived factors on compensation level,
percent of full-time employment, and so on.
You can schedule the process to run on a regular basis such as nightly or weekly, depending on your temporal setup
requirements.
a. Run the Evaluate Temporal Event Participation process from the Evaluation and Reporting work area, Processes
tab.
b. Enter the Effective Date from which to processes participants temporal life events.
c. Select Age, service, compensation, hours worked, full-time percentage in the Detect Temporal Events parameter
field.
d. You can leave all the other fields blank, unless you have specific participants or life events to process, and select
Yes for Audit Log. If you set audit log to yes you will receive and informative log when you need to triage and test.
This log is quite helpful and will provide results that enable you to resolve issues.
e. Select Submit.

Run the Evaluate Life Event Participation Process
Run the Evaluate Life Event Participation process to determine eligibility, to evaluate the impact of the life event on the
participant’s benefit and rate information, to recalculate coverage, and so on.
You can schedule the process to run on a regular basis such as nightly or weekly, depending on your temporal setup
requirements.
Note: The Participation batch process only processes benefits objects with an active status.
a. Select the Evaluate Life Event Participation process from the Evaluation and Reporting work area, Processes tab,
and select Submit.
b. Select the Effective Date to use for the Participation process. It is used for determining eligibility, electability, and as
a reference point for determining other dates such as start and stop dates for enrollment/coverage and rates. If you
select a mode of Life Event, the Effective Date refers to the date the life event occurs. If you select a mode of
Scheduled or Selection, the Effective Date refers to when this person's elections take effect, such as 1 Jan 2000.
c. Select Age, service, compensation, hours worked, full-time percentage in the Detect Temporal Events parameter
field
d. You can leave all the other fields blank, unless you have specific participants, program or plans or life events to
process, and select Yes for Audit Log. If you set audit log to yes you will receive and informative log when you need
to triage and test. This log is quite helpful and will provide results that enable you to resolve issues.
e. Select Submit.

Troubleshooting
Several problems can occur when setting up and using temporal life events, including issues related to running conversions, ineligibility,
and so on. This section identifies some of the most common issues and their solutions.
What to do when derived factors are not evaluated upon conversion and elig_per and elig_per_opt are not populated
Problem: Often in conversion, enrolments are converted but administrators don’t run any processes afterwards, such as the life event
processes, to set the temporal boundaries and to enter the data into the Benefits tables. If these markers are not already set in the
Benefits tables then the temporal cannot be calculated.
Solution: Run the Administrative then Temporal life event processes to establish a healthy population of elig_per and elig_per_opt. Or
selection will update as long as it is run with effective date after any life event.
What to do when Derived factors are added to setup post implementation?

Problem: Some organizations don’t initially have any temporal setup when they go live, but they set them up later, including derived
factors. This can result in temporal life events not being triggered, or not triggering at the right time, because the temporal boundaries
have not been set and the data not entered into the Benefits tables. If these markers are not already set in the Benefits tables then the
temporal cannot be calculated
Solution: Run the Administrative life event processes. Once you run the process, it will establish a healthy population of elig_per and
elig_per_opt records which can be used for temporal tracking.
What to do if life events are not triggering

Problem: If life events are not triggering, the first thing to check is that the life event setup is correct, especially for any updated seeded
events, or events you created. In the Many Life Events user interface, check that there are no values in the Temporal Detection Rule,
Timeliness Period and Timeliness Period Formula fields.
Also check that Track Ineligible flags are blank for the program and at plan level too in plan design.
Solution: Run Temporal Triage

Problem: If something is not working, such as the person’s eligibility or ineligibility for a plan.
Solution: In the Benefits Service Centre, Override Enrollment, check the Override Through Date field from the Benefits Service Centre
to see if this person's eligibility or ineligibility for option in plan remains in force for an indefinite period of time regardless of changes to
this person's derivable or temporal information.

Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200
CONNECT W ITH US
blogs.oracle.com/oracle Copyright © 2017, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
facebook.com/oracle fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
twitter.com/oracle means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
oracle.com
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.0115
Fusion HCM Benefits Cloud

April 2017
Author: Lynda Tollefson, Louise Raffo

Understanding Temporal Life Events

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding Temporal Life Events

Uploaded by

Copyright:

Available Formats

Fusion HCM Benefits Cloud

Understanding and Using Temporal Life Events

Understanding and Using Temporal Life Events 1

What Are Life Events? 1

Life Events Determine if a Participant can Make or Change Benefits Elections 2

Detecting Temporal Life Events – Run the Processes 2

Reporting Using OTBI 3

Predefined Temporal Life Events 3

Using Detection Rules 3

Examples of Derived Factors 6

How Are Derived Factor Boundaries Read by the Application? 7

Eligibility Profiles, including Variable Rate and Variable Coverage Profiles 8

When do the Recalculations to Coverage or Rates Take Place? 9

Where Are Temporal Life Events Most Effective? 9

Summary of Things to Consider before Setting up a Temporal Life Event 10

Alternative Method to Triggering and Detecting Temporal Life Events 10

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Run the Evaluate Temporal Event Participation Process 18

Run the Evaluate Life Event Participation Process 19

and elig_per_opt are not populated 20

What to do when Derived factors are added to setup post implementation? 20

What to do if life events are not triggering 20

Understanding and Using Temporal Life Events

What Are Life Events?

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Type of Life Event Description

Explicit Either personal or work-related changes, such as an address change or assignment

Life Events Determine if a Participant can Make or Change Benefits Elections

Detecting Temporal Life Events – Run the Processes

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Reporting Using OTBI

Predefined Temporal Life Events

Table 2: Predefined Temporal Life Events

Age Changed Derived age

Compensation Changed Derived compensation

Hours Worked in Period Changed Derived hours worked in period

Length of Service Changed Derived length of service

Using Detection Rules

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Detection Code Business Reason

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

You can create six different types of derived factors.

Type of Derived Factor Description

Length of service Unit of measure for time amounts

Compensation Unit of measure for monetary amounts

Hours worked Unit of measure for time amounts

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Examples of Derived Factors

Benefits administrators frequently use age factors to determine:

Age to Use: Points to Consider

Other Age to Use

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE

Greater Than or Equal To Length of Service

Service Less Than 1 0 1

Service 30 Plus 30 999

Length of Service Value

Salary 20 to 34000 20,000 35,000

Salary 35 to 49000 35,000 50,000

Salary 50 to 75000 50,000 75,000

Salary 75 to 99000 75,000 100,000

Salary 100 to 200000 100,000 200,000

Salary 200000 Plus 200,000 999,999,999

How Are Derived Factor Boundaries Read by the Application?

FUSION HCM BENEFITS CLOUD: EXTRACTS USER GUIDE