Skip to Content
Product Information
Author's profile photo Tarun Kumar Pachipulsu

SAP SuccessFactors Employee Central – Optimizing Business Rules

This blog will provide an overview of the SuccessFactors Implementation design principles(SFIDP) document – SAP SuccessFactors Employee Central: Optimizing Business Rules For Specific Scenarios.

The SuccessFactors Business Rules engine is a very powerful tool which can be used to meet a variety of business needs such as legal regulations, company policies, data validations, defaulting values, hiding/showing fields, eligibility calculation or other custom requirements. These requirements vary from customer to customer and depend on how the system has been set up. As such business rules are highly configurable. In many cases business rules can get very complex with extensive logic, multitude of conditions, decision trees etc., which might affect the overall response time of the application/transaction and maintainability of such business rules.

The Employee Central master implementation guide and the Business Rules in SuccessFactors guide available on SAP Help provide guidance for configuring business rules in an optimum way for common business scenarios.

The implementation design principle document identifies opportunities for efficiencies and improvements while adhering to the guidance. This is explained in the form of example business rules created for common scenarios drawn from implementations. The intent of the document is to provide examples which can be applied for similar situations and to provide a reference to the implementation consultant to apply to their specific scenario.

Below is an example concept of using lookup function efficiently that is explained using a specific use case of retirement date calculation.

Using lookup efficiently

Scenario: The organization has two retirement policies; old and new based on the joining date/seniority date of the employee. Below graphic represents both the policies.

The retirement date can be easily calculated in a business rule using IF and ELSEIF along with simple date functions. The complexity in the business rule logic increases when we have more legal entities with retirement date policies specific to each legal entity.

The requirements would look something like the following:

With the above requirements, the earlier approach of using IF-ELSEIF would get too lengthy, complicated and not maintainable. The most logical thing would then be to introduce a MDF lookup table which will be used to hold the legal entity specific policy details for both the retirement plans. And then read the relevant row in the table from the business rule using lookup function.

The table would have the columns depicted in the below graphic:

Using variables within the business rule to hold the different fields would require us to have at least 6 variables/lookups.

The number of variables and lookup calls would increase with the number of columns we have in the MDF lookup table, which is not efficient. The overall performance of the lookup function and in turn the business rule will depend also on the number of entries in the table. This is attributed to the limitation of the lookup function’s ability to retrieve only a single field vs getting the entire row.

However, we can split up the lookup table into two: a parent table(Retirement Data Lookup) with all the key fields and a child table(Retirement Data Policy Details) with all the non-key fields. The child table is associated with a composite one to one relationship. This will ensure the administrators are still able to maintain the values in a single screen for both the parent and child table.

With the table now split up into two, we can read all the non-key fields or child table at once using a single lookup call.

In the example above, we are able to reduce the number of lookup calls from 4 to 1 for each execution. The benefits are even greater when the lookup has many more fields being read. This method can be applied to any scenario which makes use of a large number of non-key fields. Further details along with screenshots of the business rule logic are available as part of the IDP document.

Many other concepts and examples similar to the above have been documented within the IDP document.

The use cases for business rules are diverse and many times vary by customer, industry, region, regulations, custom requirements and many other factors. If you have encountered unique solutions/situations that demand creation of complex logic within business rules and would like to share the same, feel free to comment below and I will be happy to review and include them within the IDP document.

The SuccessFactors product management CoE acknowledges the contributions of Michael Hallare, Rizing; Bhogesh Gandham, EPI-USE and Parul Luthra, GroupEx; towards the authoring of this document.

Assigned Tags

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

      Nice blog post Tarun. This has definitely motivated me to read the IDP.

      One scenario that I encounter recently was related to date and time fields. I see that there was no way within business rules to know the user's time zone or convert date and time  from one timezone to another.

      Author's profile photo Tarun Kumar Pachipulsu
      Tarun Kumar Pachipulsu
      Blog Post Author

      @Amit: Yes currently there is no inbuilt option to determine the time zone of a user in Business Rules. However, I would like to understand some of the scenarios where this is necessary. Can you share some details of requirements/scenarios that needed the timezone.

      Author's profile photo Antonio Ferreira Vicente
      Antonio Ferreira Vicente

      Good Job Tarun!!

      Author's profile photo Prasanna Balu
      Prasanna Balu

      Hi Tarun,

      Thanks for the wonderful article.

      Like in compensation do we have limitation in MDF lookup tables to use not more than 5 inputs (2401723 - Unable to access lookup table with more than 5 inputs and outputs)



      Author's profile photo Heike Klews
      Heike Klews

      Hi Prasanna,

      The lookup tables used in business rules do not have the 5 input/output limitation of the compensation tables. You can use many more fields (The more fields you use the more beneficial is the suggestion by Tarun to use the parent-child table pattern in the lookup table).

      Kind regards,


      Author's profile photo Murugan Natarajan
      Murugan Natarajan

      Hi Tarun,

      Thank you for confirming this. This is our one of the requirement how to handle more than 5 input and as per your statement and above blog it shows that we handle this using nested tables if required.


      Prasanna - Thanks for raising this question.




      Author's profile photo Sankarsan Dey
      Sankarsan Dey

      Hi Amit,

      Thanks for this details inside.

      We have similar type of requirement where as based upon the seniority, pay scale grade and union/non union time account value differ.

      Now my question is not related to how we can achieve . but my question towards how we can test it.

      What i mean to say that in the Time Process Simulator we could not see any account type if we try to execute in Future calendar date. Then how we can check with same employee for the seniority level account value.

      Do you have details guidance on this and how we should go scenario based testing where is future date plays important role.



      Author's profile photo arjun sapsf786
      arjun sapsf786

      Nice Tarun,

      Its wonderful article on Business Rule more articles ...could you please let me share us.