Using Integration Center and/or Intelligent Services Centre to update Background Elements or MDF with Employee Central data
In this blog post, you can learn how to create an integration to populate the Employee Profile background elements with Employee Central data, using the Integration Center tool.
A common customer requirement is to have some Employee Profile background elements populated automatically based on Employee Central data. Based on this requirement, we documented a proposal solution, using the Background Element ‘Inside Work Experience’ as an example of destination data and the Job Information as of the Source data. In Summary, we will be sending from Job Information the following information: Job Title, Department and effective date.
The detailed solution is explained below:
Step 2. Define the type of integration that you want to create. In our use case, we have selected the below, because we aim to read data from Employee Central and populate it to an Employee Profile Background element.
Step 7. Now click in the ‘+’ icon, search and select the background element that will be used as the Destination.
Step 8. Now we need to do the mapping between the Job information fields and the background element. For this, you just need to drag and drop the source field into the destination field (example below). Once it is mapped, you will see the mapping icon beside each destination field.
The field ‘BackgroundElementId64’ doesn’t need to have any mapping because it is an autogenerated code from the system.
Step 9. After the fields are mapped, back to the ‘Detail View’, we have made the ‘End Date’ as a calculated field, because for the employee’s current record, it will not need any end date, but for past records, it should populate the effective end date based on the job info record. To achieve this requirement, in the calculated screen, we set up the rule to leave the ‘End Date’ empty in case the job information record is equal to 9999-12-31, as shown below:
The integration template is set up, and you can run to a sample user to check the results and after to all employees.
Step 10. After the first full run, you will need to set up the filter to only consider delta changes, otherwise, the system will keep creating the same value multiple times. For this, you have to go to the ‘Filter and Sort’ tab and select the ‘Time-Based Filters’. There you need to define the delta updates, by selecting the below set up.
Please remember to save the integration every time you conclude a step.
The scheduling is something that you need to agree with the customer, but we normally do not recommend running more than once a day.
Below we can see the result of the integration where the background element Inside Work Experience has been populated by the job information data:
This proposed integration also works for MDF Objects. The building idea is the same, maybe some additional set up would be required, depending on the customer requirement.
In the following link you can find a sample of the above Integration definition template to help you as a starting point.
Alternatively, you can use the Intelligent Services Centre (ISC) to trigger this Integration Job instead of scheduling it. In this case, you can use the ‘Change in Job Classification’ or ‘Change in Job Title’ events to trigger the background element update.
Step 1. Go to ISC and search for the ‘Change in Job Classification’ or ‘Change in Job Title’ event:
Step 2. In the ‘Change in Job Classification’ event, click in the ‘Integration’ option in the left side and prepare the IC job as described before.
Every time that there is a job classification the ISC will trigger the IC job updating the Inside Work Experience background. The result will be de same, but you need to analyze if the customer requirements fits the IC job schedule or the IC + ICS setup.
This blog post described how we can create an integration between Employee Central data and an Employee Profile background element.
With the solution proposed we aim to avoid having to update the system in two different places (Job information changes and Employee Profile background element update) within the same information.
For more information about when to use Integration Center and when CPI, I would definitely recommend checking out the SAP SuccessFactors Integrations: Integration Center and SAP Cloud Integration IDP (Implementation Design Principle).
Looking forward to your comments and questions.
Interesting read Karen – Thankyou!
Can we also use this approach to get some transient field data (like Time in Position) from EC to EP – where we get the data of Position Start Date in Integration Centre from EC. Do the calculation (Today’s Date minus Position Start Date) in Integration Centre itself and then push this data to an EP custom field?
Thank you Ankita.
To be honest, I didn't try this scenario, but I can already confirm that the transient fields are not available to be selected in the Integration Center, so maybe the best would be to try a calculation using the Position Entry Date as you mentioned. I will try to reserve some time to test it and provide feedback.
Thank you Karan, Well explained in 10 steps. It is good to have ISC rather job schedule.
Thank you, Murugan. I am glad to hear that this was useful to you!
Thanks Karen for the blog well articulated!
However, I have implemented it for one of the customers, but it failed in scenarios where there is a back-dated entry in Job Info (EC). I have played around with time filters, but that led to another challenge where everytime all the previous records will also be created in Background elements.
Please let me know if you have any workaround to above scenarios? thanks!
Thank you, Sudheer.
I replicated this scenario, changing the employee data in a past date (Sept 1st), and I was able to get it updated in the profile. I used the ISC 'Change in Job Title' with the below definition and any filter in the Integration. It works perfectly.
Image from Demo: ISC
One additional information is that before the customer goes live, a recommended approach would be to have this job created in IC, without ISC link, and you can run for all employees, to capture all their existing (past or current) jobs in the portlet. After go-live you can setup to be triggered by the ISC event.
Can you try in your demo and if you are not getting the same result, we can talk offline if needed.
Thanks for the sharing the article on IC + ISC with standard solutions. Had also designed and work on similar requirements and on Bidirectional data flows using Integration center.
The share the example of Job Classification. Ideally inside work experience covers other event as well hence would like to add upon an additional point to the above article. to bring in the additional events like promotion or pay grade or suspension etc. we can write a onsaverule in Job information and call the ISC event trigger.
Thank you. The intention was precisely to show a use case, as described above, and from there to help others to build scenarios for other cases, like yours, so thank you so much for sharing here in the comments, it will be for sure useful for the readers.
Hi there Karen Perez
Great work on the Blog!
I am attempting something similar with SF as the Source and Destination and Intelligent Services (ISC) as the Trigger. The task is to update the loginMethod to PWD. I have set up a Rule and connected the Integration Centre with ISC.
My issue is when I run the IC in isolation it only updates the 1st record successfully in the Preview payload. It ignores the rest of the items.
So I created a second IC with Trigger as Scheduled and SF as the Source and Destination and exact same mapping as the above and it picked up all the records in the system.
Why does IC exhibit different behaviour based on the Trigger? Any reason why this would be the case?
Thanks a lot for pointing this new use case, this for sure will be very useful to others. Can you give more details about how you did and the results as I was not able to understand fully.
Hello Karen Perez
So the use case is to update the loginMethod of factory workers who do not have a Business Email to PWD. This is because the Business Integration Builder sets the loginMethod to SSO (while replicating Employees from SAP HCM to SF) and factory workers cannot SSO as they do not have an Active Directory account nor a Business Email.
For this a Rule is set up in the ISC for Employee Hire that checks that the New Hire does not have a Business Email i.e. is a factory worker. Then it calls the IC with Trigger as ISC and Source and Destination as SF, Event as Employee Hire, and Base entity as EmpJob. We then map the mandatory fields in the User entity and update the loginMethod to PWD. Now when I run the IC it just picks up the first record from the Preview.
However, when I create another IC with Trigger as Scheduled and all else same it picks up all the records in the system.
So it seems that the behaviour is based on the Trigger. Of course, when triggered from the ISC there will ever be only a single record for Employee Hire, so it is perfectly fine but I would still like to know if this is indeed the reason for this behaviour.
Thank you for the detailed explanation and yes, you are right in relation to the ISC behavior. It will only run the IC for the employee that triggered the ISC, so do not expect to have a full run through the ISC. For this reason I normally run the IC as a first time separated (for go live) and after this I leave the ISC to care about new cases.
I hope this answers your question. If this is not the case, please let me know.
Thank you again,
Thank you Karen for the response!
Of course, the ISC would run the IC only for a single Employee as the New Hire Event that triggers the ISC is raised for an instance of an Employee.
However, I was surprised to see that when I tested the IC independently of ISC it emulated the expected behaviour as if it was being tested within the ISC framework and ran for just 1 record and not all the records.
So the Trigger setting of Scheduled or ISC for an IC dictates its behaviour when you test it in isolation and independent of the ISC. You can create 2 similar ICs - one with a Trigger of Scheduled and another with a Trigger of ISC - and test them in parallel and you will see the difference in the number of records processed in Execution Manager. The IC with Trigger as Scheduled will run for all the recs in the instance whereas the IC with Trigger as ISC will run for just 1 record.
Hope this helps to clarify the different behaviours of an IC with different Trigger settings.
Hello Karen Perez
This is becoming a very common requirement these days to establish an SF to SF Integration and has multiple use cases.
I am trying to upload data from Employee Biographical Information into a custom MDF but it doesn’t seem to update the values. Checked the Execution Manager and it says “No records found for integration”. The data exists for employees but it doesn’t seem to pick it up.
Have you seen this kind of behavior in your experience?
Dear Shubham Gupta,
I am really sorry for missing your post/question, I know that was a long time ago, but are you still facing the issue? I did replicate the case in my demo and it works from Biographical Info to a custom MDF. How did you create yours?
Dear Karen Perez and All,
Thanks for sharing this document.
We have a requirement to automatic update future records in Job Info.
I.e. my emp joins since 2019, have some records in 2020, 2022, 2025 (future records).
I am thinking to use Integration Center to update these future records in Job Info.
However seem currently IC only allow to update Job Info from hiring record.
I only want to update for some records (future records i.e.) in Job Info only, not all records since hiring.
Q1: So currently no way to update some records in Job Info from IC?
Q2: I want to delete records from MDF with IC, but seem i cannot not find this option in IC at the moment? It is correct ?
Please advise. Thanks so much for your help.
Dear Trong Nguyen,
First of all sorry my late reply, I was not notified about your post/question, so I have missed it.
The future records update is already something that happens by standard, so I am questioning myself how are you doing to not get it replicated to your future records. Can you please give more details (steps) on how are you doing?
Thanks for this detailed blog.
Could you please help on below scenarios?
If I follow the steps given, it is only inserting new record, not updating existing record.
Dear j c selvaraj,
Thank you for your post/question.
I was thinking about it and trying some stuff in my demo, also I double-checked with some colleagues and unfortunately could not find a way to fulfill these use cases as of today.
I will continue reviewing it and if anything comes to my mind or from other colleagues, I will write you here.
When we are trying to fulfill information into the Inside Work Experience for the first time, for some reason only information about current position is being pulled into the portlet, but past-dated records are not synchronized into it.
Do you know what could be the issue?
Dear Pavel Novikov,
The first run should not consider any filter, so please double-check this in your integration center and remove if any defined. Also remember that the first run must be done manually from the integration center page, not wait for the ISC to trigger it.