Skip to Content
Technical Articles
Author's profile photo Neelesh Kamath

Child Care Leave China Workaround in SuccessFactors

Overview of requirement


Childcare leave refers to a period of paid or unpaid leave granted to employees for the care and/or support of their children under a certain age. In China, we have a common requirement that each couple can enjoy five days’ childcare leave each year until their child reaches three years. In this blog, I am going to demonstrate a workaround solution to achieve this in EC Time Off.


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 childcare leave. Any more children need to be handled manually by adding the balance of 5 days to one of the existing accounts

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
  • 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 child birth date and this process needs to be repeated for the next three years i.e until the child turns 3 years old.


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

  • A custom MDF for every user having such a time profile. An integration center 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 childbirth details each time a child is born using relevant on Save Rules. 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.
  • 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 years for 3 children, we would need 9 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 where The field for Time account is not null. 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.

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



First, we would build a custom MDF with the following fields and structure

In total we would need 12 fields

External code: This is the user field. For each user we would need an instance of Custom MDF

Child Date of Birth: For each child we have three DOB fields

ChildTA1: We have to store the time account dates for each of the children. For example, Say the 1st child is born on 1st June 2022. Then we would need 1st June 2022, 1st June 2023 and 1st June 2024 to be stored as Time account dates for Child 1.  Since we support three children, this would need 9 dates for 3 years.


Now let’s get into the on Save Rules


The rule checks if this is the first child using count of dependents and gets the youngest dependent date which is the first child itself in this case. We also check for null case “child1DOB is null”. If this is null only then the Child 1 DOB and Time account 1 Date is updated. This is because, there can be cases like Hire, Migration, where the data needs to be fed in manually into this custom MDF (if the employee has existing children). In such manual cases, these on Save rules should not override existing data filled.


Similarly create the other two on save rules for child 2 and child 3


This is the final on Save Rule which populates fills Child Time Account Dates for year 2 and 3 as and when that birth year is reached

Time Account Type and Time Type Configurations


Since we have three children, we would need three time account types and three time types to be added in time profile. For demonstration purposes, I will be using only two-time account types for two children.

The following is the time account type structure for adhoc accounts











Similarly, create two-time types for 2 children and link them to corresponding time account types. I think this is straight forward and hence I am skipping this part

Integration Center 1


The first Integration center report is to create/update this custom MDF on daily basis. The starting entity is user, and the target is our custom MDF “cust_ChildDOBDetailsCHN”

Once the custom MDF is created or updated, the details like child’s DOB and relevant Time Account Dates are filled

Please note:  The custom MDF is saved only if there are new changes. If there are no changes since the last save from the job, the custom MDF is not saved again. This is necessary for other ICs (which I would explain shortly ) which would filter only recently modified records.

There is only field User ID from User entity which is mapped to externalcode (User field) of the Custom MDF

Integration Center 2


As I explained in above sections, we would need 9 ICs to create three accounts for three children for three consecutive years.  Also, the IC’s are built in such a way that only relevant records are read and only those which have Childs time account date fields filled in custom MDF.

For example, if there is no child born, None of the ICS would pick that user. If the user has only 1 child, IC meant to run for 2nd child will not even pick that user. Lastly if the user’s MDF has not gone through any changes since the last IC job run that, entire MDF record for that user is filtered out. So overall, this should take care of efficiency of IC runs

I will explain the concept of 1st IC. The remaining 8 ICS are basically clone of the 1st one with some attribute changes. If you can look at the 1st IC design , you can build the other ICs using Save as feature of Integration center in no time


IC to create 1st time account of 1st Child:

You would need to create a SF to SF OData Integration with Starting entity as “Custom Child MDF” and target as “Time Account”

1) External Code of Time account is a calculated field which concatenates the user ID with Child Birth of Date and Child No from custom MDF

2) Time Account Type can be hard coded with TAT you use. For example if its child 1 the use the Time account code for child 1, if its child 2 then use time account code for child 2

3) Booking possible from, account valid from and account valid to are all mapped to corresponding time account date field of each child. If we are dealing with child 1 and time account 1, then use child1TA1 from the custom MDF. If its child 1 and time account2 then child1TA2 and so on..

4) Booking Possible Until is mapped to child Time account date (refer to point 3) + 12 months – 1 day

5) User ID is mapped to external code of custom MDF

6) 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 1)
  • External code – This is external code of child time account detail. Use the same code and calculation as described in point 1)
  • Amount posted – 5 days for child care per child per year. You can change it according to your requirement
  • Posting Date- Drag and drop effective start date from Child MDF
  • Posting Type – Defaulted as “MANUAL_ADJUSTMENT”
  • Posting Unit- Defaulted as “DAYS”

The payload looks like this

The payload looks like this
    "entityName": "TimeAccount",
    "payload": [
        "externalCode": "1032582021-04-01C1",
        "accountType": "Child Care CHN (Child1)",
        "bookingEndDate": "/Date(1648684800000)/",
        "bookingStartDate": "/Date(1617235200000)/",
        "endDate": "/Date(1617235200000)/",
        "startDate": "/Date(1617235200000)/",
        "userId": "103258",
        "timeAccountDetails": [
            "TimeAccount_externalCode": "1032582021-04-01C1",
            "externalCode": "1032582021-04-01C1",
            "bookingAmount": 5,
            "bookingDate": "/Date(1617235200000)/",
            "bookingType": "MANUAL_ADJUSTMENT",
            "bookingUnit": "DAYS",
            "__metadata": {
              "type": "SFOData.TimeAccountDetail",
              "uri": "TimeAccountDetail(TimeAccount_externalCode='1032582021-04-01C1',externalCode='1032582021-04-01C1')"


Last step is to add a filter. You can go with a combination of last modified date and a calculated filter

The last modified filter filters out only recently modified records of custom MDF. This ensures that not all user records are picked up unless a new child is born for them



The 1st IC (user to custom mdf) is run first in sequence and this should create the custom MDF for the user first.

Let’s assume that employee has 1 child first born on April 01,2021

The on save rules on custom MDF check youngest dependents and fill the child details as and when new childs are born.

Now I Run IC for time account 1 child 1 :


Next I  run IC for time account 2 Child 1:

Next lets say a new child is born today and dependent data is filled (child 2 should be filled by main IC1 when its scheduled and run)

Main IC1 would again fill the existing MDF with child 2 details for this year. See below TA1 date for child 2 is filled

Then IC for Time account 1 Child 2 runs and creates the relevant adhoc account too as you can see below


To summarize, the IC1 for creating custom MDF should be run first so that it periodically keep tracks of new children born and then remaining time account creation ICs should be run. These can be scheduled every day, week during non-business hours with a gap of say 2 hours between each of them


Other user cases and recommendations

  • Migration/ New hire :

For new hires, there can be two scenarios:

  1. New Hires without any children – This will work without any manual intervention and any new children born would be tracked via IC and MDF.
  2. New hires with existing children below three years – This info has to be fed manually in the custom MDF just like any migration scenarios….(The HR can maintain this info just like how they maintain for any new hire like job info, compensation info, dependents info etc). Once the information is fed in custom MDF, the time accounts would get created automatically via IC.  I guess it is reasonable for HR to do this since they anyways feed the other personal and employment details manually during new hire.
  • Twins – For twins only the 2nd child info is fed. You would need to fill the 1st child info manually.
  • This approach is recommended for a customer with relatively smaller employee size. If you have a larger employee size, then you can split the main IC (user to custom MDF) into multiple ICs depending on filters like legal entity, Department, Employee Class, type etc For example, if you have say 5000 employees who need this solution, split the main IC into 5 equivalent ICs and then schedule them with a gap of atleast 2-3 hours. I have tested this for a smaller sample size. For larger size, I would recommend you try out above options, test completely in a sandbox or QA and then deploy it
  • Also in the IC, we have operations listed as “Upsert Multiple” and “Upsert Single”. If there are data issues trouble shooting becomes difficult in Upsert Multiple Mode as the entire batch of records would fail. For initial load and testing, use Upsert Single to see if it works for majority of the population. Then once you have tested this and run it multiple times, you can try with Upsert Multiple.

Hope this helps to overcome this challenge

To Summarize, I want to reiterate again that this is merely a workaround solution and not a standard.

If you are implementing this approach, do thorough testing , adjust as per your needs, and then deploy

All the best


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jeeja bai T
      Jeeja bai T

      Hi Neelesh,

      Another great peace of work and superb way of explanation. Thanks again for sharing.

      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author

      Thanks Jeeja

      Author's profile photo sriram rajagopalan
      sriram rajagopalan

      Again a great blog Neelesh. Thanks for sharing.

      couple of questions:

      1. From your approach, employee(s) will see a new leave type whenever there is an eligible child and employee(s) have to selected the corresponding leave type when applying the timeoff, for ex if employee is applying for 1st child, childcare leave1 should be selected, if employee is applying for 2nd child childcare leave2 should be selected and so on. Please correct if my understanding is wrong.
      2. Can we attach all the time account type to single time type - say child care leave so employees can see only one leave type and increase the entitlement at the backend when there is eligible child birth and reduce the entitlement when the child cross the threshold limit. Not sure if this will work, have to try it out though. What's your thought
      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author

      Hi Sirram

      Thanks for the feedback

      Regarding your questions

      1. yes you are right. Each child will have a leave type.
      2. Yes you can have multiple time account types linked to one single time type. Please give it a try. The reason why I had seperate time types is only because this requirment came from China and some customers as per my understanding create seperate leave types for each child


      Author's profile photo Evangelia Panagiotou
      Evangelia Panagiotou

      Hi Neelesh this is a very interesting article but I am still puzzled with a specific thing... I have actually tried to configure something very similar a long long time ago, without the use of a custom Object or Integration Centre, I managed to do it, but it was a huge Business Rules, which only covered a maximum of three children, since I had to create combinations of the three children between them... too much fun! What I still cannot comprehend is the use of the function: Get Date of Birth of Youngest Dependent" --> Based on what you are saying, this function can actually read the dependent of a different dependent at each time, based on the first function you are using?? I Remember that this was not possible at the time I was testing it...



      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author

      Hi Evangelia,

      Yes this rule function is not the one which has Rank where you can order the dependents based on birth date and can check how many children are below a certain limit like 16 years at a point in time

      This workaround would work as and when new children are born.

      For example say the first child is born in July 2023. The youngest dependent would be this child itself and count is first condition of the on save rule is satisfied

      Next say a child is born in July 2024...The count would be 2 and youngest dependent would be the second one..The first conditon of the rule is then skipped and goes to second condition where count is 2

      So its important to note that this works only on incremental basis as and when new children are born

      And of course there are some limitations with the workaround which I have specified in notes


      Author's profile photo Evangelia Panagiotou
      Evangelia Panagiotou

      Thanks Neelesh! Of course that makes perfect sense and it's clever actually! Thanks again!



      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author



      Author's profile photo Abhineet Arora
      Abhineet Arora

      Hi Neelesh,
      Thanks for sharing the link to this blog post. It matches quite a bit to the requirements I am working on. However, in my requirements we only need 1 time account per child with the start date of the child and end date when the child turns 8. What changes do I need to make in the rule and the IC jobs? Please advice.


      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author

      Hi Abhineet

      In that case, you dont need 9 ICs..You need three accounts for three childern. Three ICs is needed. and the cutom MDF can store only TATchild1 , TATchild2, TATchild3.

      In the IC you can set the account valid until 8 years (you have the TATChild1 start date stored in custom MDF whichj is nothing but the birth date of child..

      Follow the same process for other TATs



      Author's profile photo Abhineet Arora
      Abhineet Arora

      Hi Neelesh, Thanks for your response.
      This is what I have done so far but it's not working.

      • Created 8 fields namely Child1DOB, Child2DOB and so on.
      • Created 8 Time Account fields namely Child1TA, Child2TA and so on.
      • Created same rule as "fillChild1DOB" for the 8 DOB fields.
      • Have not created same rule as "fillAccountDatesCHN" as I am not sure if that rule is going to help.
      • Time accounts are not getting created automatically when a child is added in dependents info.
      • Have created IC Job 1 where the entity is user and target is the custom object.
      • Have created IC Job 2 where the entity is the custom mdf object and target is time account. Mapped the fields according to the blog.

      I am not sure where I am going wrong. What do you think from the above, did i go wrong somewhere?


      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author

      Hi Abhineet,

      I would suggest you to touble shoot one IC at a time

      First please check after IC 1 is run , if you see the custom mdf created /updated for the user with child DOB. You can check the IC response after job is run. In "Review and Run " tab you can check the log by clicking on the last run link. The log should indicate if it successful or failed

      Then when running second IC, check if you see those user records in previiew,, And follow the same approach as first IC to check the logs.

      Without the logs, it is difficult to predict what is not working. Only the logs should help you to check what could be the issue you are facing


      Author's profile photo Abhineet Arora
      Abhineet Arora

      Hi Neelesh,

      I am working on the IC jobs.

      which option did you select while creating IC Job 1, SF to SF Odata v2 or something else?

      IC job 1 failing and giving this error.


      Any suggestions?

      This is what I mapped in the IC JOB1 but still the IC Job is failing with the above error