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.