Overview of requirement

Parental leave lets parents take unpaid leave from work to spend time looking after their children. You can take up to 26 weeks’ parental leave for each eligible child before their 12th birthday. Generally, you must have been working for your employer for a year before you are entitled to parental leave. In this blog, I am going to demonstrate a workaround solution to achieve this in EC Time Off. The concept would have some elements from my previous blog on child care leave for china

Child Care Leave China Workaround in SuccessFactors | SAP Blogs

This solution is better since :

1. we could also integrate fields like Dependent names and DOB in time off screen which is currently not possible in standard. This allows the end user to know exactly for which dependent the leave is applied for and what is the balance for each dependent child.
2. No Manual intervention required. Works for Migration cases, works for Hire and also if twins are born. But if there are exceptions to above or a clean up job is required, admins may have to interact manually. But most normal cases like adding dependents incrementally or at one shot will work seamlessly.

Doesn’t this sound interesting? If yes, well read through the blog for a piece of magic. To be honest, I surprised myself with capabilities that we can leverage in SuccessFactors using MDF and Integration centre. I believe, You will be surely amazed with what this solution can offer and unearth. And I am very optimistic that many will use this solution.

Disclaimer: Please consult your partner before implementing this solution. Perform thorough testing including performance of the Jobs which are going to be listed here.  Reiterating that this is one of my workaround solutions and is not a standard approach. Please do your due diligence before adopting this approach.

For simplicity case, we would take only three children for this leave. Any more children need to be handled manually from your end. Based on my survey of various implementations in Ireland, 3 children are maximum some employees have. There are exception cases, but those cases are rare.

Hence this solution should work for most of the cases. I would say 90% of the cases. We also plan to ship this as part of best practices for Ireland in future

What are the key challenges here?

• Keeping track of every new child born along with youngest dependents
• Avoiding any manual intervention wherever a new child is born. For example, System should be able to detect a child born event and should generate the time account with balance automatically for 12 years validity.
• Time accounts are not fixed. They do not start with a fixed date like hire date or from Jan to Dec. Every account should start from the childbirth date and valid for 12 years for each child
• Hire case where all dependents are added in one shot.

Design

Keeping in mind above challenges the below would be the high-level design of my solution

• A custom MDF is created to store dependent child details for every user having such a time profile. An integration centre job would run daily to ensure that this custom MDF is created/updated whenever there is a new child born.
• The custom MDF is updated with child number to keep track of sequence. With every new child born we get a youngest dependent and the youngest dependent keeps changing as and when we progress through years and a new child is born.

Please note: Even if all dependents are added in one shot, this solution will work. In summary, Incremental cases where a child is added as and when they are born And one Shot case where All dependents are added during Hire or migration would work with this solution. That is the beauty of this aspect unlike my previous child care leave solution where some manual intervention was required for hire cases etc.

• Ad hoc accounts – Since every account should start from the child’s Date of Birth , adhoc account is best suited for this requirement .
• Since we need 3 accounts for 3 children, we would need 3 similar IC to create these individual accounts. All ICs are basically a copy of the first IC created with minor changes. This sounds alarming at first sight, but the good part is each IC has its own filter in such a way that it picks only relevant records . Also, they would filter records only for those users where the MDF was recently changed due to a new child. This is based on last modified date filter. This should take care of performance too. Also 3 ICs is relatively a less number.
• Employee Time MDF object has relevant custom fields to store Dependent Child Details and these fields are populated at run time using onChange Rules.
• Three leave types of Parental Leave 1,2,3 for 3 children is needed
• Each leave type is 1:1 mapping to three parental time account types.

The below is the High-Level Block Diagram

Since the design is clear, let’s look at configuration now.

Configuration

Custom MDF to track Dependents.

First, we would build a custom MDF with the following fields and structure. This MDF would store each dependent child of the user and is filled automatically by an Integration centre Job. This basically syncs HRIS Dependent Info to Custom Dependent MDF. Hence it’s called  cust_HrisDepToCustomDep

External ID is the person ID external of each dependent user. Cust_User field is the user ID of the employee itself. The child number field stores the child sequence as per the date of birth. For example, the child who was born first with earlier Date of Birth will have child number 1, the second child number 2 and so on.. The rest of the fields are self-explanatory

Create an On Save Rule to Populate the ChildNumber and add it onSave hook of the object definition of this custom mdf

The rule does the following

1. Dependents are sorted based on Date of Birth in ascending order per user and sent to MDF
2. The MDF looks up for child 1,2,3 via different variables.
3. Depending on different combinations, the child number is updated per child with the child who was born first getting child number 1 and so on..
4. Only for first time creation, the child number needs to be inserted. Hence data operation is create. This ensures we don’t have to repeatedly store this field for further updates unless its a manual change (correct)

For example: If PreviousChild1 is Null, it indicates that this is the first child => Child Number1

If PreviousChild1 is 1 and PreviousChild2 is Null , it indicates there is one child before this child’s DOB. So, Child Number 2

As you can see in Lookups, we try to fetch previous child  record where previous child’s DOB <= current Child’s DOB and the Previous child’s ID not equal to Current Child’s ID

The above rule works for both cases

1. Children are added incrementally as and when they are born
2. Children are added in dependent portlet in one shot during Hire or Mass migration (Imports)

Employee Time MDF

Create four custom fields to reflect dependent details like ID, Names, Date of Birth etc

Additional field criteria can be added so that these fields are only shown to relevant time types

Next create a on Change Rule to populate these fields. It has to be hooked to TimeType Field

This rule lookups the relevant child of the employee from Dependent MDF and populates the values in time off screen.

Integration Center to Sync HRIS Dependent portlet to Custom MDF

This is the main step which syncs the HRIS Dependent Info to Custom MDF which was created in one of the above steps.

The starting entity is Dependents (PerPersonRelationShip) and Target Entity is Dependents Sync Custom MDF.

The mappings can be seen from the screenshot. Drag and drop the relevant fields from Source to Target

Please note the external code is filled with RelatedPersonIDExternal . This is nothing but ID of the dependent. Hence a record is created for each dependent child

And you need to drag and drop other dependent fields from relatedPerson Nav as shown

And Most Important point: Please ensure that the operation of IC is “Upsert Single”

Add filter to only select relationship child. That is picklist of personRelationShiptype.Externalcode = 2 is child

Also add time based filters only to read recently created dependent records

Finally Add the Sort order to sort the dependents based on Date of Birth in Ascending order (from RelPersonNave.DateofBirth field)

IC To Read the Custom MDF and create Adhoc Time Accounts

Like I said we need 3 ICs to create time accounts for 3 children. We would use 3 adhoc time account types for 3 children. The IC creation process is already explained in detail in my Child Care for China Blog. Hence, I would try to cover minimalist information here

This is how the first IC for child 1 looks like

The starting Entity is Dependents Sync Custom MDF and target is Time Account

Here is a brief of mappings.

External Code – It is a calculated field made up of dependent name and DOB which is almost unique

Time Account Type can be hard coded with TAT you use.

Booking possible from, account valid from and account valid to are all mapped from Date of Birth Field of Child in Custom MDF

Booking Possible Until is mapped to child Date of Birth + 12 years using calculation

User ID is mapped to external code of custom MDF

Time account Details (Child Object of Time account)

• Time_Account_External_Code – This is the external code of time account parent object. Use the same calculation and same code as described in point of Parent Time Account External Code
• External code – This is external code of child time account detail. Use the same code and calculation as described in above point
• Amount posted – 182 days (26 weeks) for the child. You can change it according to your requirement
• Posting Date- Same as Date of Birth of the child from Custom MDF
• Posting Type – Defaulted as “MANUAL_ADJUSTMENT”
• Posting Unit- Defaulted as “DAYS”

The payload looks like this

"__metadata": {
          "type": "SFOData.TimeAccount",
          "uri": "TimeAccount(externalCode='Sam2019-07-02Boulder')"
        }
      },
      {
        "externalCode": "Neel2023-10-01Child1",
        "accountType": "IRE_PACH1",
        "bookingEndDate": "/Date(2074809600000)/",
        "bookingStartDate": "/Date(1696118400000)/",
        "endDate": "/Date(1696118400000)/",
        "startDate": "/Date(1696118400000)/",
        "userId": "103249",
        "timeAccountDetails": [
          {
            "TimeAccount_externalCode": "Neel2023-10-01Child1",
            "externalCode": "Neel2023-10-01Child1",
            "bookingAmount": 182,
            "bookingDate": "/Date(1696118400000)/",
            "bookingType": "MANUAL_ADJUSTMENT",
            "bookingUnit": "DAYS",
            "__metadata": {
              "type": "SFOData.TimeAccountDetail",
              "uri": "TimeAccountDetail(TimeAccount_externalCode='Neel2023-10-01Child1',externalCode='Neel2023-10-01Child1')"
            }
          }
        ],

Last step is to add a filter. You can go with a modified date filter as explained in IC 1 design above

Additionally add a filter to pick only Child 1 Dependent Record (Since this IC is specific to Child 1 and its time account). This can be done using child number field.

Similarly create other two ICs for child 2 and 3. The only thing which would change is the filter childNumber and Time account Type mapping which now needs to be mapped to Child 2 and 3 TAT accordingly

That’s all we need from Config point of view.

Somethings to note:

Ensure that first the IC to update details from HRIS Dependents Portelt to Custom Dependent MDF is run first. Next the other three ICS related to child 1,2,3 can be run. These ICs can be run every day once. Keep sufficient Gap Between Dependents Sync MDF IC and The other three ICs to create Time accounts. For example schedule Dependents Sync MDF IC in the beginning/mid of the day and other three time account ICs towards end of the day or near midnight.

Testing

Child 1 was added for a test employee with DOB on July 02,2019

IC to update dependents MDF was run and the below record was created with Child Number

And then the IC for Child 1 to create Time account was run and it created the corresponding time account

Similarly the second child was added and the ICs for Dependent and Child 2 were run and and it created the corresponding records.

Here is how it looks now in Time Account Screen for the employee with three children (with corresponding balances for each child)

As you can see the time account is bookable for 12 years and corresponding balance for each child is shown. The start date of time account is DOB of the child

If the employee now requests parental leave 1, then the child 1 details with its balance would appear (Balance for child 1 is 152 since some leaves were consumed already for Child 1)

And if child 2 parent leave is selected, the below

As you can see the correct balance and dependents names are shown on selecting the corresponding Parental Child Time Type. For child 1 balance of 152 days was shown and for Child 2 a balance of 182 days.

Hence this is a complete workaround solution with a very good user experience where the end user knows in detail the child details when requesting the Parental leave and the good part is each child has its own Ad hoc time account whose balances can be tracked easily from UI and also reported since these are dedicated time accounts

To Summarize, I want to reiterate again that this is merely a workaround solution and not a standard. I have tested this to best of my knowledge for both incremental birth and one shot updates. If you are implementing this approach, do thorough testing , adjust as per your needs, and then deploy

All the best