“I Love Rules” said my kids never!
But I do! I love rules – “Business Rules” that is! They are very useful in extending the standard solution to your company’s custom needs and for finding creative solutions to complex problems. They help reduce HR Technology costs.
You can define business rules for a wide range of applications across the SAP SuccessFactors platform including Employee Central. You can default values, kick off approval workflows, propagate data, do data validations, eligibility checks and calculations. There are many pre-delivered functions that can help you with all of the above.
In these series of episodes, I would like to take you on a journey of useful features, tips and tricks, and handy examples for business rules for your Employee Central solution.
Some helpful resources that will give you detailed information:
I would also encourage you to enter ideas and solutions you have created to solve your business challenges in the comments section. Sharing is caring 🙂
Episode 1: Application-specific Rule Scenarios
Let’s begin at the beginning: We recommend using application-specific Rule Scenarios when creating rules. Rule scenarios provide more guidance about the supported objects, parameters, and actions you can use to configure the rule. For each application-specific scenario, there are guardrails to help you create Rules that work. For existing rules using the Basic rule scenario, you can change the scenario to an application-specific rule scenario.
My colleague S_Strangfeld has a couple of wonderful blogs on adjusting rules to application-specific scenarios and mass changing rules to application-specific scenarios. She also has a short video on how to do it.
For an example of creating a rule using an Employee Central Scenario, see Episode 1 card. It will walk through selecting the ‘Validation for HRIS Elements’ scenario to create a rule that will give a message when a field on Personal Info of Employee Profile is changed.
Episode 2: Rule Events or Rule Triggers in Employee Central
Rule Events refers to which user action in the system triggers rule execution. For example, onChange event simply means when a field is changed and the user tabs out of that field, the rule attached to that field will be triggered.
Events supported in Employee Central are:
These events give you tremendous capability to solve many simple and complex requirements for your business. You may think this is the boring stuff, but boring and reliable is great when it comes to Rules. Stay tuned for more exciting and exotic Rules in the upcoming episodes 😉
For several examples of cool rules using onInit, onChange and onSave, see Episode 2 card. It will walk through how to hide fields during new hire for selected company codes, defaulting a new timezone when employee location field is changed and triggering an approval workflow when employee’s national id information is saved.
In addition, the Help document has many Employee Central related Business Rule examples:
Episode 3: Warnings, errors, and validations with data change
At home we have a sensor light in the corridor which goes on when something moves in the corridor. So imagine my heart rate when the light woke me up at 2:15 am! Nothing should have been moving at that time and we looked and checked and didn’t find anything. But the next morning, I found a spider as big as my palm hiding next to the picture frame in the corridor (I live in Australia, and we have THOSE SPIDERS!!). Needless to say, I will be paying more attention when the sensor light comes on unexpectedly…
Wouldn’t be nice to have an early alert/warning in the system that warns about unexpected things. Stops bad data when saving, gives helpful messages when unexpected data is entered. That is exactly what you can achieve with Business Rules and it is easy to set up. You first create the message text, and then create a rule that refers to the message text you've created. Then add it to the field or to save of record.
For some examples of rules with error and warning messages, please see Episode 3 card. It will give examples of an info message when Marital Status field is changed, a warning when Nationality of employee is saved and an error if the ‘child’ dependent is over 18 years old.
In addition, the Help document has great information:
Episode 4: Comparing Previous and Current values
Sometimes you need to check if the value of a field is changed when saving the record. And if so, trigger a workflow approval or display a message, or do some calculations, etc.
To do that, you can compare the previous and current values of the field and see if it is different.
For Employee Profile, in order to utilize the ‘previous value’ capability, you need to use the ‘model’ Base Object (e.g. Personal Information Model, instead of Personal Information). Otherwise the Previous Value will not be available for the if statement comparison.
For MDF objects (for example Position object), use the ‘Rules for MDF Based Objects’ scenario when creating the Rule (this ties nicely back to Episode 1 🙂). This scenario will automatically give you the ‘Original Record’ parameter. You can then compare the original value of the field with the current value.
For examples of rules which compare previous and current values, please see Episode 4 card. There is an example of a change to employee name which triggers an approval. There is also an example of when the ‘Job Code’ field is changed on the Position object. We will come back to this example in Episode 5 and expand on it with additional requirements, such as triggering a workflow only if the user who is making the change is not a HRBP (i.e. manager is making the change, and HRBP should verify that the manager has picked the right job code).
You can find additional information on usage of Business Rules in MDF objects here:
Episode 5: Privileged? Are you an HRBP? Then...You Bet!
You can trust different people with different tasks, given their responsibilities and experience. For example, an HRBP is always in the system and working on tasks they are familiar with. Often, they don’t need to go through an approval workflow to double check they have done the right thing. However, a manager or employee who is creating or changing data will benefit from someone giving the change the ‘four-eye principle’ to check that they have entered the right information and/or to fill in additional details.
And this is easy to achieve in Business Rules! You can check if the user making the change is the employee him/herself or not. You can also check if the user making the change is in a certain permission group.
For examples of rules which check the user, please see Episode 5 card.
In the first example, managers are allowed to create and change Positions. However, we want the position to go through an approval with an HRBP to verify the data and enter additional fields in the position. However, if the position is created by an HRBP, no need for approval! (also see episode 4 for a similar example of Job Code change)
In the second example, you can prevent an employee changing or canceling an existing absence from the past. When you add the IF-condition “User is equal to Login User()”, you restrict the check to the Employee-Self-Service scenario. An HR admin can edit or cancel such requests.
This example is also interesting, because the business rule is added to specific time types via ‘Manage Data’, instead of to Employee Time object (more info on the Episode 5 card). We will talk more about Time related business rules in a later episode! – they are interesting 🙂
Episode 6: Calculations! Calculations!
One of the big benefits of Business Rules is the ability to do calculations with them. They are very powerful and flexible.
For example, you can add, subtract, multiply and divide (like we did in primary school 😉). And you can format numbers, get the number of calendar days between dates, get expiration date of work permit, get incumbent by position, get next working day, and much, much more.
For a couple of examples of rules doing calculations, please see Episode 6 card. You will find an example that automatically calculates and sets the next sequence of the Position Code ID and another example that calculates the Full Time Equivalent from Standard Hours.
For a full list of functions supported in Business Rules, please see the Functions A-Z | SAP Help Portal. Sky’s the limit (almost) 😊!
Episode 7: Defaulting Values
There are many occasions when you would like to fill in fields without having to do it manually. Why not let the system (a.k.a. business rules) do it for you? Business Rules can default in values. For example, when filling in values for the employee profile or working with generic objects such as Position entity.
For a couple of examples of rules filling in the fields for a new position that is being created from Position Org Chart and filling in the HR Business Partner on the employee profile, please see Episode 7 card.
Episode 8: Data Propagation / Synchronization
Business Rules empower you to minimize data entry and increase accuracy when using Position Management. Upon entry of a new hire or transfer, data can be propagated from the position object to the new incumbent employee’s job information. In addition, if you change Position fields, they can automatically synchronize to the employee’s job information.
You can also configure Business Rules that will synchronize updates from employee Job Information fields back to corresponding position object fields. This synchronization happens when employee data is changed via action “Change Job or Compensation Information” (but not when changes are made from the Job Information History portlet). This rule also allows ‘Implicit Position Management’ where some users (e.g. Managers) may benefit from not having access to positions. If so, when applying changes in Employee Profile through Take Action, synchronization can update positions automatically.
These propagation / synchronization rules are triggered from Position Management Settings > ‘Synchronization’ tab. For a couple of examples of rules doing propagation and synchronization of Position and Employee Job Information, please see Episode 8 card.
For additional information, please see Defining Synchronization Position to Job Information | SAP Help Portal and Defining Synchronization Job Information to Position | SAP Help Portal
Episode 9: Workflow derivation
Well-designed workflows can automate business processes and ensure data quality. Business Rules can trigger approval workflows for specified events or data changes. You can create business rules to define conditions that should be met before a specified workflow is triggered for an object.
Please use the ‘Trigger Workflows’ scenario while creating new rules instead of the Basic scenario. This special-purpose business rule scenario will help you to create rules more easily because it provides useful guidance at various steps (refer to Episode 1 for ‘Scenarios’ - and additional benefit of using application-specific scenarios is the ‘Assigned’ (where-used) feature).
For a couple of examples of rules calling approval workflows, please see Episode 9 card. You will find an example of an employee pay change that needs to be approved by different people depending on percentage of pay change. And an example of an approval for a new hire.
For additional information, please see:
Episode 10: Alerts and Notifications
You can use business rules to define when an alert should be triggered, which alert message template is used, and whom the alerts are sent to. And it is as easy as a-b-c:
There are lots of resources to help you with these (and I have included some links below). There are some nuances in how to configure the business rule, so somethings to keep an eye on:
See examples in Episode 10 card for how the syntax format is different between these two scenarios above.
There is very good information in the Help document and even better information in the KBAs below:
Episode 11: Rules with Lookup Function
The Lookup function is used to look up values from a table. This enables the rule to look up a result from a table instead of having lots of ‘Else and Else-If statements’. This makes the rule less complex which in turn improves performance. And the lookup table can be reused in multiple rules. I am big fan of lookup tables 😊
The lookup table must be a MDF (Metadata Framework) object. For example, if you need multiple pieces of information from the lookup, you can wrap all the information in an object, and perform the lookup only once in the variable section (see later episode for ‘Variables’). Then, all the information can be used in the rule by using the fields of the variable.
See examples in Episode 11 card with filling in personal info fields during new hire (where the language and nationality fields come from a lookup table) and creating new time account details (where the accrual amount comes from a lookup table).
For additional information, please see: Creation of a Rule with Lookup Function | SAP Help Portal and Using Lookup Tables | SAP Help Portal
Episode 12: Example Rules for Hiring and Termination
Sometimes you need a bit of inspiration to get your creativity going – in this case, thinking of what kinds of things are possible when you are hiring or terminating an employee (using business rules of course).
So, for your inspirational pleasure, please see Episode 12 card for an example of hiding some Compensation fields during hiring of new employee (also see Episode 2 for a similar example). And another example with calculating benefit end date during termination.
For additional examples, please see: Example Business Rules for Hire | SAP Help Portal and Example Business Rules for Termination | SAP Help Portal
Episode 13: Rules in Time Management
Continuing the inspiration theme, Time Management is capable of doing a lot by using business rules. It is the key to flexibility and additional functionality! And with new capabilities in the 2H2023 release, you will find them even more flexible. Rules are used in accruals, period-end processing, leave taken / time off, and for time sheet validations. You will find many rule scenarios that will help you create rules.
Please see Episode 13 card for an example of time sheet validation rule and an example of a period-end processing rule.
For additional information and many more examples, please see: Rules and Rule Functions in Time Management | SAP Help Portal and Common Rules in Time Management | SAP Help Portal. New features in Time Management related to Rules: Enhanced Absence Counting Rule with Day-Based Processing in Time Management | SAP Help Portal
Episode 14: Variables to Store Interim Results
What are variables and why would I want them? Simply put, they are great for reducing complexity and improving performance! You can store results of complex and repeating calculations in variables; and then use the variable in the IF / ELSE-IF blocks to compare values with the condition.
Please see Episode 14 card for an example of ‘before and after’ of a rule which looks up employee’s home country and calls a different workflow depending on country. Initial rule is inefficient due to multiple ‘IF / ELSE-IF’ blocks which fetches employee record to get employee home country. In the second version of the rule, performance is improved by fetching employee record at the beginning and storing the country in a variable. Then the variable is used multiple times to compare values without the need to fetch employee record repeatedly.
Also, continuing from episode 13, Time Management module goes even further, and has a helper object (MDF entity) that can be used to store accrual rule variables (see Accrual Rule Variables and Using Variables to Store Interim Rule Results for more information and examples).
For additional information, please see: Creating Variables | SAP Help Portal and IDP - EmployeeCentral - Optimizing Business Rules For Specific Scenarios V1.3.pdf (sap.com)
Episode 15: Mass Changes
You can mass update positions and incumbents using business rules. This capability uses ‘Manage Mass Changes for Metadata Objects’. You can use a single rule to define which positions will be selected and the change attributes. Changes are effective dated and changes to positions can be synced to incumbents.
Please see Episode 15 card for an example of a company reorg where positions in a certain department and location are transferred to a different department and cost center. There is also another example to archive old time off calendars.
For additional information, please see: Mass Changes to Positions | SAP Help Portal
Episode 16: Event Reason Derivation Rules
You can create rules that select the appropriate event reason according to what change is done to an employee’s data. Without derivation rules, user would have to manually select the event-reason from the UI every time they make a change to the employee data. This can be time consuming and error prone. Business rules that methodically check what change has occurred and figure out the event reason based on a hierarchy of changes is very useful!
Please see Episode 16 card for examples of job and compensation changes.
For additional information, please see: Event Reason Derivation Business Rules | SAP Help Portal and KBA2571698 - Best practices setting up business rules for event reason derivation
Episode 17: Rule Execution Log
Rule Execution Logs are used in troubleshooting and performance analysis of Business Rules. You can find out why a rule doesn’t work as expected by analyzing the log trace. If you can’t find possible error in the rule definition and execution, there is a list of Common Errors in the help portal.
Please see Episode 17 card for a simple example of how to set up the execution log and trace. There is also a follow up from episode 14, where I said the performance is improved by using variables. How can I prove that performance improvement? By looking at the execution log of course! 😊 I can see exactly how many milliseconds I am saving by looking at the before and after execution logs!
For additional information, please see: Creating Business Rule Execution Logs | SAP Help Portal and Troubleshooting | SAP Help Portal
Episode 18: Adding Contexts to Rules
By adding context, you can limit the situations where rules are triggered. For example, for Edit UI, History UI, Imports, Mass Changes, etc. This can prevent triggering unnecessary rules in a given context and can improve system performance. Please note that these contexts are currently only for HRIS elements, not for MDF objects.
When you add a rule to the HRIS element, it automatically sets all contexts to ‘Yes’ (meaning the rules are triggered when the parameters set in the rule are met). But you can change the context to ‘No’, so it is not triggered for that context. For example, rules for Event Reason Derivation (Episode 16) may only make sense when making changes in ESS/MSS, so you can restrict such rules to the ESS/MSS context by setting it to Yes, while switching other contexts such as Import to No.
Please see Episode 18 card for how to set up and an example.
For additional information, please see: Adding Contexts for Business Rules | SAP Help Portal and Configuring Rule Context for Business Rules | SAP Help Portal
Episode 19: Export / Import your Business Rules:
If you need to copy rules from one instance to another, you can use the MDF import and export framework. Rules are essentially MDF objects, so you can use the ‘Import and Export Data’ action.
Please see Episode 19 card for more details on how to do it.
Episode 20: Best Practices and Resources:
… and finally, some tips to make your rules efficient, accurate and to improve performance:
Please see Episode 20 card for additional information, and a list of resources.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.