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

Perform Cost of Living Adjustment using SuccessFactors Integration Center

This blog is co-authored by Gobinder Sandhu  (Gobinder Singh Sandhu) and Stéphanie Bourgault-Mongeau


The use case is very simple and very common: every year all the employees’ salaries needs to be adjusted by x% because of a cost of living adjustment. Yet, in Employee Central, the mass change transaction can’t be used to do so (as it is only available for the Job Info and Job Relationship portlet mass changes), and customer in the end usually opt for a process where they create a report, do some transformation in Excel and load the data back into EC compensation and recurring pay component portlet. This is time consuming, error prone manual process.

Integration Center, using the SF to SF integration, offers a safer and less time-consuming alternative to the extract/transform/load (ETL) process. This blog explains how integration center can be leveraged to automate the Cost of living adjustment in Employee Central and similar use cases.

On similar note, Integration center opens a door to do more ETL kind of processes

Creating a new integration in Integration Center

1.     Selecting the Integration Type

After Integration Center is provisioned and security is configured, it is ready to be used. For our Cost of living adjustment use case, we will need to use More Integration Types when creating the integration as we want to use the SuccessFactors (Source) to SuccessFactors (Destination) integration type. This means that we will use Employee Central data for the outbound integration (send the data out of SF) and use Employee Central to catch the inbound integration (getting the data back in SF). The goal is just to do some simple transformation when we send the data out so that when it comes back, the newly calculated data value is captured in the Compensation and Recurring Pay Comp portlet!

Figures: Create Integration Type

2.     Selecting the Starting Entity

For our integration, our goal is to create a record in the Compensation Information portlet with an effective date and a specific event reason as well as to create a record in the Recurring Pay Component portlet with the new rate against the pay component. Therefore, our starting entity for the integration is the Compensation Information (empCompensation) and we will add the Compensation (EmpPayCompRecuring) entity in the Configure Fields step. The two screenshots below illustrate how to select the starting entity and adding an entity in integration center:

Figure: Selecting the starting entity

Figure: Adding an entity to an integration

3.     Mapping the fields

Now that we have selected our entities, the next step is to map all the fields from the selected entities from what the current values are to the targeted values. There is three mapping type that can be used and we will present each of them in this section.

Associated Field Mapping

Associate field is the simplest mapping type which means that we want to keep the current field value. It is like a direct mapping of a field in the source to the destination without any transformation. In case you are familiar with data imports to Employee Central, associated field mapping is just like using the &&NO_OVERWRITE&& tag when loading data. It is going to be the mapping that we need to use for most fields in our use case. In the example below, we are mapping the User ID (step 1,2) field from the source to the User ID in the destination (step 3,4).

Figure: 1-Selecting the destination field to map; 2- Select associated field

Figure: 3- Selecting the source field to map; 4- Change Association

Edit Calculation

There is the possibility to add some calculation to associated field mapping by using Edit Calculation option. This is useful for Cost of Living adjustment, in this example below we are fixing the new pay component Amount to be the current pay component Amount multiply by 1.03 (for a 3% increase)

Figure: Edit Calculation

Figure: Simple Calculation screen

Fix Value Mapping

Fix value mapping allows to set a default or a fixed value in the integration. In our Cost of living adjustment use case, we will use fix value for Start Date and Event-Reason. This will allow us to fix the effective date of the Cost of living adjustment in the Compensation Portlet and the event reason to justify the portlet change. In the example below, we are fixing the value of the Start Date to 10/01/2011.

Figure: 1- Select the destination field; 2-Select Fix value; 3-Enter the fix value 10/01/2017

More Field Options

Selecting More Field Options give us a bit more flexibility when defining mapping field. For example, we can use More Field Options to fix a field format or define field restrictions like the minimum and maximum characters. In the screenshots below, we are showing how to fix the date format of the Start Date field to MM/dd/yyyy

Figure: More Field Options

Figure: Fixing the date format to MM/dd/yyyy

Calculated Value Mapping

There is also the option to use calculated field mapping. This looks a bit like the SuccessFactors business rule engine on steroid where it is possible to do IF/THEN logic and more complex logic. We won’t need calculated value mapping for our use case but this option can handle the transformations which are complex in nature and needs some sort of calculations.

Switch to View Test

Once all the entities fields are mapped, it is possible to preview the result output using the View Test mode (play button). This look just like an upload file and it gives us a preview of the data that will be inserted in Employee Central with the integration

Figure: View Test mode

4.     Adding some Filters

The next step of setting up the integration is setting up Filters and Sorts. For our cost of living adjustment use case, we will use a filter on a specific pay component (in the example below, pay component 1300). For the sake of the example, we will also filter on a User Id but when you are ready to update all employees in the system who have this pay component, you will need to remove the User Id filter.

Figure: Filter and Sort

Ready to run

We are done! The integration just need to be save and it is ready to be run. Once you have run the integration, a log will be generated as per screenshot below:

Figure: Run Now and check log


After running the integration, we can validate the result in the Compensation portlet. Here we see that this employee hourly rate is increased by 3% which is the calculated amount we set up in the integration.

Integration… that sounds complicated!

We believe that integration center is a quite accessible tool for Employee Central consultant. With a bit of training or a good mentor (We are lucky to have @jaikarankorpal part of our team), you can create some interesting integrations that could reduce the extract/transform/load processes that your customers are currently doing. There is a great value in it for every EC consultant once the vast capabilities of Integration Center are understood and realised.

Integration Center for the business user

As we have seen with our use case, building a SF to SF integration in integration center can be relatively easy and quite useful. However, we still do not see the HR business people go in integration center, modify the Start Date and % of increase amount and run the integration every year in its current form unless the user is tech savvy. Therefore, it would be nice if Integration Center provides a simpler version or ready to go use cases. It would be great if we could build a custom UI that could be permissioned to trigger the integration. One way to achieve (we are yet to prototype this) is to create a custom MDF object that would capture the integration fix values and calculation parameters to trigger the integration… that would give the ability to run the integration in simulation and real mode… and generate log files during the process!

In Summary, Integration Center is extremely useful tool to carry out the customised exports and then imports on need based or can be scheduled. The example used in the blog is one of the common scenario. There are number of similar scenarios in payroll or employee master data maintenance which can leverage Integration Center. Examples are general pay increase, mass uploads with percentage increase in a certain pay component, Updating / replacing the work schedule rules of employees, Changes in seniority or other dates etc. Integration center also monitors the executed integrations and is capable of providing the useful error log and messages for troubleshooting and keep track of data uploads.


Hope you have enjoyed reading the blog.
Please share your thoughts or use case on the subject in the comment section!



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo RAJESH KATHARE

      Stephanie Bourgault-Mongeau , Gobinder Singh Sandhu

      Thanks for the detailed article. It's very clearly explained accompanied by screenshots.

      I just want to point out that the trigger type "Application / UI" you have used in the example is incorrect. The trigger type "Application / UI" can only be used internally by SF applications to trigger the execution of an Integration defined in Integration Center (IC). Currently SF RCM uses this for Background Check verification. If you use this option, you cannot schedule the integration and even if you choose "Run Now", only the first record is picked for execution.

      The right trigger type would be "Scheduled" for your use case. Can you check and update your document?


      Author's profile photo Bob Vos
      Bob Vos

      Hi Stephanie,

      Very nice blog which definitely shows the strenght of the Integration Center which is often forgotten in my experience. Thanks for this.

      For this specific used case i also want to mention that salary increases and pay scale updates can also be done via business rules and the standard mass pay scale change functionality within SuccessFactors.

      Author's profile photo Hans van Dijk
      Hans van Dijk

      Dear Stephanie,


      Thank you for your blog. I have a use case where we need to increase certain pay components within recurring payments with a certain percentage. Using your blog I have created an IC integration to increase these pay component. The issue I am facing is that only the first pay component is selected by the integration for increase and not multiple pay components. In our case this first pay component is not relevant for the increase. I have tried both 'Application / UI' and 'Scheduled' trigger types, but in both cases only the first pay component is selected for processing.

      Are you familair with this issue and how did you solve this?

      Thank you