This article has been written assuming the reader has fair amount of knowledge about Employee central and business rules. This can be handy for every functional configurator while working on business rules. Business rules can become highly complex sometimes, not in terms of writing the logic but testing as well. I would like to share some important points in this article that can be helpful for every configurator including a beginner.
1. It is always suggested to choose the application specific category from rule scenario instead of directly taking a basic rule. This will be helpful to avoid unexpected issue or rework later. Choosing a rule category restricts the base objects for you.
2. It's very common at every client to configure background elements. Before you take a requirement to update these elements, please keep in mind that business rules are currently NOT supported for background elements.
3. Make sure you choose the Model base objects ex. Job information model to write logic on field properties (ex. required, visibility, previous). System can only work on values with non-model objects ex. Job information.
4. Make sure to choose 'Rule for Hire/Rehire' from rule category if you want your rule to get triggered only during new hire or rehire. This will restrict the base object to only Employee Information" and "Employee Information Model". But it does not mean that rules with other Base Objects will not trigger in during New Hire. All rules related to employee data (ex. with base entity job info or job info model), will trigger during new hire and rehire.
5. To write business rules for complex requirements, variables can be explored to start with. Storing variables initially, helps reduce the processing logic. I would recommend starting to write the logic flow on a piece of paper and start configuring the rule. You may also come across some limitations of business rules while configuring so sooner the better you start configuring it.
6. Make sure you don't configure more than 5 cross entity business rules for an HRIS element ex. Job information portlet. System will give an error if you assign more than 6 cross entity rules. So, it is very important to make sure you haven't chosen cross entity rule from rule category when requirement can be met with a basic rule.
7. Cross entity rules are triggered onSave. Limited functionality is given for onChange. Please note that cross entity rules assigned OnSave to Job info portlet are triggered from Position to Job Info sync rule. Support for onchange cross portlets is introduced for a limited functionality. It works for Job information, Compensation Information and Pay component Recurring when both Job Information and Compensation Information Change checkboxes are selected in MSS UI (Take action).
8. To compare the values in the rule logic it is very important that data type of both fields match. Ex. you want to compare value from an MDF record using operator (<,>) with amount on recurring compensation information portlet, if you are not able to select amount on right side then try using any operator ex. Divide. In this case you will be able to select dividend from employee's comp info and divisor can be 1.
9. Always use Business rule execution log (rule trace) to debug the rule. Most of the issues can be solved reviewing the trace. Make sure to enter your business rule name if you want to review only your rule logic. In case you want to review the whole log including all rules triggered during a transaction then don't enter the rule name.
10. You can use the export and import utility to quickly export your business rule from one instance and import into another. Select the object 'Rule' to export the rules. The column' body' in the csv export will have the business rule logic.
11. As you know 'Lookup' is used to read records from a table. Please note that this function works with only MDF but not Foundation objects.
12. Never delete a business rule from an instance if it is assigned to an HRIS element for ex. Job information portlet. If you do you won't be able to open the configuration screen. In this example if you delete a business rule that has been assigned on job info portlet then when you open Manage business configuration and clock Job info you will get an error. In this case create a dummy rule with same name, remove the assignment from job info portlet and then delete the dummy rule.
13. You may come across a requirement to modify the employment dates like hire date, employment end date using a business rule but try to avoid doing that because it may lead to data issues and inconsistencies.
14. Always try to search existing business rule that can be modified or updated to include new requirement instead of directly creating a new rule. For ex. if you have a default a value on Job Info based on value in another field then assess similar existing rules instead of creating a new one. More the number of business rules, more is the execution time for a transaction. Number of business rules is inversely proportional to performance.
15. Make use of 'Context' for business rules to prevent unnecessary triggering of business rules. You can select context by clicking details in Manage business configuration.
For ex. you may not want a workflow rule to trigger during mass changes of data. In that case select 'Mass changes' No so that rule is not triggered during mass changes. Another example could be related to data conversion or imports. If you don't want a particular rule to get triggered during Imports, then select 'No' for imports.
16. If you come across a requirement to trigger a rule based on event reason attribute on Job info but you don't see event reason field from manage business configuration (MBC) then enable it. This field is hardcoded in data model so it's not necessary to enable in from MBC unless you want to configure 'onChange' rule on this field.
17. If you have multiple if else conditions in your rule, then try to keep those conditions on top that belongs to major employee population i.e., condition that narrows down the criteria the most.
18. If you have a requirement to default a job relationship during hire/rehire, then it is suggested to add matrix relationship to the position of new hire employee. During new hire the matrix relationships from position are synced to job relationships (enable this setting in Position management settings). You cannot set the user id for a relationship in job relationship portlet during hire/rehire due to system limitation.
19. If you have a requirement to set the field property editable, read only etc. for an MDF attribute then you have to create a configuration UI (Manage configuration UI) for the MDF and create a UI rule as shown below as an example.
20. If you have integration from Employee Central to Employee Central payroll and you have a requirement to make person id 8 digits through a business rule, then use the format function in business rule as shown below. Template %08d means that total digits in person id will be 8 digits.
Ex if your person id range (in sequence MDF) starts from 1000 then this rule will make that value 00001000.
1. It is always suggested to choose the application specific category from rule scenario instead of directly taking a basic rule. This will be helpful to avoid unexpected issue or rework later. Choosing a rule category restricts the base objects for you.
2. It's very common at every client to configure background elements. Before you take a requirement to update these elements, please keep in mind that business rules are currently NOT supported for background elements.
3. Make sure you choose the Model base objects ex. Job information model to write logic on field properties (ex. required, visibility, previous). System can only work on values with non-model objects ex. Job information.
4. Make sure to choose 'Rule for Hire/Rehire' from rule category if you want your rule to get triggered only during new hire or rehire. This will restrict the base object to only Employee Information" and "Employee Information Model". But it does not mean that rules with other Base Objects will not trigger in during New Hire. All rules related to employee data (ex. with base entity job info or job info model), will trigger during new hire and rehire.
5. To write business rules for complex requirements, variables can be explored to start with. Storing variables initially, helps reduce the processing logic. I would recommend starting to write the logic flow on a piece of paper and start configuring the rule. You may also come across some limitations of business rules while configuring so sooner the better you start configuring it.
6. Make sure you don't configure more than 5 cross entity business rules for an HRIS element ex. Job information portlet. System will give an error if you assign more than 6 cross entity rules. So, it is very important to make sure you haven't chosen cross entity rule from rule category when requirement can be met with a basic rule.
7. Cross entity rules are triggered onSave. Limited functionality is given for onChange. Please note that cross entity rules assigned OnSave to Job info portlet are triggered from Position to Job Info sync rule. Support for onchange cross portlets is introduced for a limited functionality. It works for Job information, Compensation Information and Pay component Recurring when both Job Information and Compensation Information Change checkboxes are selected in MSS UI (Take action).
8. To compare the values in the rule logic it is very important that data type of both fields match. Ex. you want to compare value from an MDF record using operator (<,>) with amount on recurring compensation information portlet, if you are not able to select amount on right side then try using any operator ex. Divide. In this case you will be able to select dividend from employee's comp info and divisor can be 1.
9. Always use Business rule execution log (rule trace) to debug the rule. Most of the issues can be solved reviewing the trace. Make sure to enter your business rule name if you want to review only your rule logic. In case you want to review the whole log including all rules triggered during a transaction then don't enter the rule name.
10. You can use the export and import utility to quickly export your business rule from one instance and import into another. Select the object 'Rule' to export the rules. The column' body' in the csv export will have the business rule logic.
11. As you know 'Lookup' is used to read records from a table. Please note that this function works with only MDF but not Foundation objects.
12. Never delete a business rule from an instance if it is assigned to an HRIS element for ex. Job information portlet. If you do you won't be able to open the configuration screen. In this example if you delete a business rule that has been assigned on job info portlet then when you open Manage business configuration and clock Job info you will get an error. In this case create a dummy rule with same name, remove the assignment from job info portlet and then delete the dummy rule.
13. You may come across a requirement to modify the employment dates like hire date, employment end date using a business rule but try to avoid doing that because it may lead to data issues and inconsistencies.
14. Always try to search existing business rule that can be modified or updated to include new requirement instead of directly creating a new rule. For ex. if you have a default a value on Job Info based on value in another field then assess similar existing rules instead of creating a new one. More the number of business rules, more is the execution time for a transaction. Number of business rules is inversely proportional to performance.
15. Make use of 'Context' for business rules to prevent unnecessary triggering of business rules. You can select context by clicking details in Manage business configuration.
For ex. you may not want a workflow rule to trigger during mass changes of data. In that case select 'Mass changes' No so that rule is not triggered during mass changes. Another example could be related to data conversion or imports. If you don't want a particular rule to get triggered during Imports, then select 'No' for imports.
16. If you come across a requirement to trigger a rule based on event reason attribute on Job info but you don't see event reason field from manage business configuration (MBC) then enable it. This field is hardcoded in data model so it's not necessary to enable in from MBC unless you want to configure 'onChange' rule on this field.
17. If you have multiple if else conditions in your rule, then try to keep those conditions on top that belongs to major employee population i.e., condition that narrows down the criteria the most.
18. If you have a requirement to default a job relationship during hire/rehire, then it is suggested to add matrix relationship to the position of new hire employee. During new hire the matrix relationships from position are synced to job relationships (enable this setting in Position management settings). You cannot set the user id for a relationship in job relationship portlet during hire/rehire due to system limitation.
19. If you have a requirement to set the field property editable, read only etc. for an MDF attribute then you have to create a configuration UI (Manage configuration UI) for the MDF and create a UI rule as shown below as an example.
20. If you have integration from Employee Central to Employee Central payroll and you have a requirement to make person id 8 digits through a business rule, then use the format function in business rule as shown below. Template %08d means that total digits in person id will be 8 digits.
Ex if your person id range (in sequence MDF) starts from 1000 then this rule will make that value 00001000.
- SAP Managed Tags:
