Skip to Content
Personal Insights
Author's profile photo Stephanie Bourgault-Mongeau

Understanding the insurance benefits type in SAP SuccessFactors Employee Central Global Benefits

In this blog entry, we will focus on one particular benefit type being supported in SAP SF EC Global Benefits: insurance. Insurances are a big part of enterprises the employee’s perk package that help attract and retain clients but to this date, there are very few references or blog on SAP SF Insurances. Therefore, I’m hoping to fill some of this gap with this entry.

The insurance benefit type is very flexible and can cover the typical insurance uses cases such as:

  • Life
  • Health care
  • Dental care
  • Short Term Leave (STD)
  • Long Term Leave (LTD)
  • Accidental Death and mutilation
  • Travel
  • And more

Insurance objects

There are a lot of objects to understand when configuring insurances in global benefits. The picture below is an overview of all the main objects and how they are connected together. In this section, we will do a brief overview of every object and show how it looks configured in SAP SuccesFactors Global Benefits.

Insurance Coverage

Insurance coverage is the inclusion of an insurance policy or the amount available to meet liabilities. There are 4 coverage options within SAP SuccessFactors:

  • Amount:
    The coverage amount is a specific amount of coverage. For example, a basic life insurance of 100,000$.

Example of amount coverage:

  • Percentage:
    The coverage amount is a percentage of a pay component group or a pay component within Employee Central. The final amount of the coverage therefore varies for each employee. For example, LTD insurance of 70% of the weekly salary.

Percentage coverage type allows to specify a minimum or a maximum coverage amount. For example, LTD insurance of 70% of the weekly salary with a maximum of 2,000$.

There is also the possibility to apply Benefit Salary calculation rule or a Coverage Rounding rule to the coverage. Benefit Salary Calculation rule makes it possible to “adjust the salary” before the calculation of the % (e.i. 70% of the weekly salary + $500) while the Coverage Rounding rule “adjust the coverage amount” after the % calculation (e.i. 70% of the monthly salary rounded up to the nearest thousand).

Example of percentage coverage:

  • Factor

The coverage amount is a multiply quantity of a pay component group or a pay component within Employee Central. For example, AD&D insurance of 2.5 times the employee’s annual salary. Just like percentage, factor can have a maximum and a minimum and salary & coverage calculation rules.

Example of factor coverage:

Example of benefit salary calculation rule:

  • Other

Anything else can fall into this category. For example, Family Medical Care coverage.

Example of other coverage:

Eligible Enrollee Options

Eligible enrollee options define which dependents are eligible for an insurance. This object will be used within the insurance plan object configuration. Once all set-up, when the employee will try to add dependent to a benefit insurance enrollment, the system will check if the dependent is eligible based on the eligible enrollee option object, if not the system will throw an error pop-up message.

In the eligible enrollee option, we will define which dependent relationship type (from the personRelationshipType picklist of the dependent portlet) can be added when enrolling to an insurance, if there is a maximum or a minimum number of dependent to be added when enrolling and a rule to validate the dependent is eligible. For example, you can specify that if the employee enroll to an Employee and Family eligible enrollee option for an insurance, the employee must enroll at least 1 dependents in the benefit enrollment and only Spouse or Children under 18 years old are allowed to get the benefits.

Example of other eligible enrollee options:

Example of eligible enrollee options rule:

Note that right now, the Eligible Enrollee Option name is not translatable field and appears in the Benefit Overview screen.

Rate Chart

Rate chart is used to determine the premium and employee and the employer will pay for a specific coverage within an insurance and the factor used in the calculation.

A rate chart can be for an Employee & Dependents or for Dependent Only.

Employee & Dependent rate chart calculates the premium before employees adds (or don’t if employees only insurance) eligible dependents when enrolling to the insurance. Criteria that can be used in defining the rate chart premium are Age, Smoker, Employee’s Location and Gender of the employee. Currently, it is not possible to add more custom criteria.

Example of rate chart for Employee & dependents:

Dependent Only rate chart calculates the premium after enrolling a dependent to an insurance. It can calculate premium per dependents or per group of dependents (e.i. child life insurance where the employee pays the premium for each child he enrolls versus child life insurance where the employee pays the premium 1 time regardless of how many children he has and all are covered). Criteria that can be used in defining the rate chart are Age, Smoker, Dependent Type and Gender of the dependent. Currently, it is not possible to add more custom criteria.

Example of rate chart for dependents only:

There is also the option to specify at what time to evaluate the employee’s / dependent’s age when calculating the premium which is either a specific day and month of the enrollment year or the enrollment effective year.

Insurance Provider

Insurance provider object identify the insurance provider, their contact information and allows to add a link or a document describing the provider

Example of insurance provider:

Insurance Plan Eligibility Rule

Insurance eligibility rule defines which employee is eligible to a specific insurance plan. Rule uses the SuccessFactors rule engine.

Example of eligibility rule:

Insurance Plan

Insurance plan is where all objects described so far connects together. The insurance plan specifies the provider, the eligibility rule, the pay components to be used for the employee & employer premiums, the coverage options and the rate charts to be used for a specific insurance.

Example of a basic life insurance plan:

Example of a health care insurance plan:

Benefit

Finally, once the set-up of the insurance plans is done, we need to create a benefit object to encapsulate all of it and make it available to employees. The benefit object will specify the benefit name (that will be displayed in the employee people profile benefits tiles and the employee benefit overview screen; note that currently this field is not translatable), the benefit schedules (that specify the benefit enrollment period), if there is payroll integration for the benefit (to the EC deduction portlet for the employee contribution only), whether the employee will enroll manually during the enrollment period or automatically through the auto-enrollment job (auto-enrollment job enrolls the employee the day he becomes eligible for the benefit and un-enrolled the employee if he’s not eligible anymore), the benefit screen (config UI) that will be used when the employee enrolls to or edit the benefit enrollment, it also specifies some benefit permissions and workflows to be used when enrolling.

Also, there is some insurance specific fields in the benefit object such as if the insurance is nominee relevant (does it require the employee to identify beneficiary for the insurance when enrolling), the insurance plans that are available in the benefits and the default insurance option (when enrolling manually, the enrolling screen will default the insurance, coverage option and coverage field to the default option; when enrolling with the auto-enrollment job, this is the insurance, coverage option and coverage that the employee will be enrolled to. Note: currently, it is only possible to specify one default option per benefits).

It’s a brief overview of the benefit object, they are a lot to say about the benefit object, perhaps in another blog ?.

Insurance Structure Example

Now that we understand the objects and the structure, let see some example of potential configuration of specific insurances. There is a lot that can come into account when deciding how to configure specific client benefits (will it be a new coverage option within an insurance plan? a second insurance? If we have multiple insurance plans should we put the plans in same benefit? or different benefits?). It really depends on the different requirements, but I hope to highlight some good use cases in this section.

Basic Life Insurance

Use case: All employees are eligible to basic life. During enrollment period, employees can choose between coverage from 1 time their salary to 5 times their salary.

This a simple straight forward case. We would build one insurance plan containing the five coverage options (from 1 to 5 times the salary) and 1 benefit for the plan.

Medical Care Insurance

Use case: Employee can choose between single or family medical care coverage. All employees (permanent and temporary) are eligible to the 70% reimbursement of medical fee option. Only permanent employee can choose the 90% reimbursement of medical fee option.

This is a bit more complex case. Since the eligibility of the 70% and 90% reimbursement plan is different, we would need to create two insurance plans each with a different eligibility rule. Each plan would be grouped together under one single benefit object and each plan would have both single and family coverage options.

Mandatory basic accidental death and mutilation (AD&D)

Use case: All employees must have AD&D insurance. Employee under 65 years old are covered for 100,000.00$ while this amount is reduced to 5,000.00$ when the employee is turning 65 years old.

Since we want to use the auto-enrollment job (automatically enrolled when eligible) and in the benefit object, we can only specify 1 default insurance plan, coverage option and coverage per benefit, we need to create two different benefits each with a different default option. Each benefit would have their own insurance plan, with different eligibility rules and coverage options/

Conclusion

This is really a quick overview of how does the benefit type insurance works in SAP SuccessFactors Global Benefits. Although, creating the benefits objects in the system is not that complicated, there are lots of objects and relationship that needs to be understood. Also, as highlight with a few use case examples, there is a few subtle choices to be made when configuring that can have impact on the system usability and the user experience. Thanks for reading.

If you are preparing a SAP SuccessFactors Employee Central Global Benefits implementation or want to learn more about the Employee Central Global Benefits, contact us at IN-RGY!

https://www.in-rgy.com/en/contact/

Assigned tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Antonio Vicente Ferreira
      Antonio Vicente Ferreira

      Stephanie,

      Thank you so much for sharing. It's very important !!

      Author's profile photo Siddharth Rajora
      Siddharth Rajora

      Wow you have gone a great length in presenting in such lucid terms and clear cut steps for configuration

      Nice to see your blog Stephanie, Hope alls well!

      Author's profile photo Stephanie Bourgault-Mongeau
      Stephanie Bourgault-Mongeau
      Blog Post Author

      Hi Siddarth,

      It's been a long time! Thanks for the comments. I'm always happy to share, especially less knows subjects where not much as been written yet!

      Stéphanie

      Author's profile photo Dibyendu Mahata
      Dibyendu Mahata

      Very Nice and insight blog Stephanie.

       

      I have a question regarding automatically through the auto-enrollment job (auto-enrollment job  enrolls the employee the day he becomes eligible for the benefit and un-enrolled the employee if he’s not eligible anymore).

      Can you please provide some insight about automatically un-enrolled from a plan when the employee is not eligible anymore and re-enrolled on some other plan based on current eligibility.

       

      Thank you.

      Author's profile photo Stephanie Bourgault-Mongeau
      Stephanie Bourgault-Mongeau
      Blog Post Author

      Hello Dibyendu,

      There is a limitation when the EE switch Legal Entity, so there is 2 cases:

      1. EE is staying in same LE becoming not eligible to "current" insurance plan and eligible to "new" insurance plan

      • The delimit of "current" plan and the create of the "new" plan will occur depending on your jobs set-up. For one of my clients, we had plans based on location (they had plant based collective agreements with a different package/rates for each plant), I created 1 job per benefits per location to reduce job run time. Sometimes EE switched from 1 plants to another, and the jobs un-enrolled the EE to previous benefits and enrolled them to new one. Therefore, depending on the run sequence you might get create "new benefits" first and then delimit "previous benefits" after or vice-versa, and depending on job run sequence.
      • Auto-Enrollment jobs, only enrolled to default coverage set in the benefit object, therefore, if you have a plan with 2 coverages options like Medical - Single, Medical - Family, the "new" enrollments will be either Single or Family based on the set-up of the default coverage (there are ways to be creative and use 2 benefits instead of one to avoid this and a "preference" portlet but it really depends on a lot of factors and the complexity of the company's benefits, and there is next point to consider)
      • If you have a dependent coverage option, the eligible dependents are not enrolled to the benefits, it needs to be done after the job is ran. If we keep our Medical - Family example above, it means that we could use Family has default coverage option, the job would set the enrollment to Medical - Family, but the EE or an admin would still need to attach the dependent to the enrollment after the enrollment is created (I wish there was a config setting where we could auto-enroll all eligible dependents during the job run...)

       

      2. EE is changing LE becoming not eligible to "current" insurance plan and eligible to "new" insurance plan

      • There is a limitation here and the "previous" benefits are not getting delimited. I believe that will get improved by SAP soon.
      Author's profile photo Dibyendu Mahata
      Dibyendu Mahata

      Wish you a happy New Year and thank you Stéphanie for your details explanation.

      I have a another follow-up question on regarding dynamic calculation of Insurance premium.

      As an example : Employee Insurance Coverage is 2 times of Annual Salary which is 100000.Now Premium for each 1k its 0.22 CAD and first 25K coverage given by Employer which is =25*.22=5.5 CAD and rest coverage premium should be contributed by Employee which is =(200000-25000)=175000*.22=38.5 CAD.

       

      Currently I dont find any options available in system to handle this situation. Do you think can above example can be handle in EC Benefit or any other other thought to handle this situation.

      Appreciate your insight on this scenario.

       

      Thank you,

      Dibyendu

       

      Author's profile photo Stephanie Bourgault-Mongeau
      Stephanie Bourgault-Mongeau
      Blog Post Author

      Hey Dibyendu,

       

      you are right, the rate charts aren't "dynamic". So, to propose a solution to your use case, you could create 2 plans, with benefit dependencies, the 1st one for the first 25k and the second for the rest. The inconvenient are that you have more benefits to handle.

      Cheers,

      Stéphanie

      Author's profile photo Dibyendu Mahata
      Dibyendu Mahata

      Thanks Stéphanie for your quick response.

      I able to handle the situation with a business rule tagged with Benefit Enrollment Object (On Save) but only disadvantage for that Calculated Employee Contribution will not be able to show when employee select the “Insurance Coverage Option” during Enrollment and it can only be shows in your Active Enrollment section.

       

      Thanks,

      Dibyendu.