Creating business rules for Employee Central transactions during implementation

Objective

After completing this lesson, you will be able to create business rules for Employee Central Core data

Business Rule overview

Business rules are used to add application logic to the system and used in different scenarios across all SAP SuccessFactors solutions. In Employee Central Core, business rules are used to automate HR processes, such as workflow and event reason derivations, alert notifications, and many others.

Business rules are comprised of the following:

  • Condition (IF) - The logic that must be met before the system takes action. When you want the system to apply the action every time, set the IF statement to Always True .
  • Action (THEN) - The logic that defines how the system reacts when the condition is met. Some application-specific scenarios do not require a THEN statement.
  • Trigger or Rule Event - The event type that activates the rule processing.

Business rules can be applied to any application of SAP SuccessFactors. In this unit, we will only cover the rules for Employee Central data.

IF Logic

IF statements are the conditions in the rule that must be validated. It determines when the THEN logic is executed. The IF logic uses "and"/"or" statements. The following list provides examples of when IF logic is used:

  • If a particular option is chosen from a picklist
  • If specific text or numbers are entered into a field (or if they are greater than or less than the values stated)
  • If a field value has changed

Some rules are created without an IF statement. This is also known as Always True, which means there are no conditions for the system to validate. Once the rule is triggered, the system will execute the THEN statement.

Else If statements allow you to combine several conditions in the same rule.

THEN Logic

The THEN statement determines the system action once the condition is met. Depending on the use case, these are the actions the system can execute with Then logic:

  • SET: This automatically propagates information based on existing information or a specific value chosen.
  • Raise message: This brings a pop-up box up on the screen that provides additional information to the user filling in the information or an error message that something was done incorrectly.
  • Create: This creates a child object. Examples include adding a new pay component to an employee or creating another child object attached to the parent object.
  • Delete: Delete data from the database when the condition is met. For example, you can remove a pay component when the employee moves away from London.
  • Execute: Carry out specified action when the condition is met.
  • Add to: Add items to a collection when the condition is met. For example, you can create a single rule to assign multiple learning courses to new hires.

ELSE statements can also be added. These actions occur when THEN statements are not applicable because the IF condition is NOT true.

Triggers or Rule Event Types

Triggers, also called rule event types, initiate the rule processing. The system will not validate the conditions (IF statements) or execute any actions (THEN statements) if no user action activates the rule.

There are six rule events associated with HRIS elements and fields. Rule events define which user action sets the rule execution. Complete the interaction or use the table to learn more about triggers or rule events.

Rule Event for HRIS Elements

This event/triggerIs assigned at...Rule is triggered...Use this event to...
onChangeField level onlyWhen a field value is changedActivate rules as soon as the user changes a field
onInitHRIS Element level

During hire/rehire, using Add New Employee page.

When creating a new FO record in Manage Org Pay and Job Structures page (for example, location, event reason).

Set field properties (for example, making fields mandatory or hiding fields) or default values you want to be shown as soon as the user calls up the Add New Employee or Manage Organization Pay and Job Structures UI.
onSaveHRIS Element levelWhen the page is saved.

Validate user entries when the user wants to save the changes. For example, if the user didn't make an entry in a mandatory field, an error message is displayed.

onViewHRIS Element levelWhen viewing transient fields on the page.

Calculate fields that are transient (this means that the result is not a fixed value stored on the database but is calculated during rule execution when the user calls up the page). For example, to calculate an employee's age.

saveAlertHRIS Element levelWhen a change to jobInfo, compInfo, employmentInfo, workPermitInfo is saved.Sends alerts to remind users of upcoming system events, such as, visa or contract expiry.
onPostSaveHRIS ElementAfter changes to an object is savedTrigger events for Intelligent Services.

Rule Scenarios

Rule scenarios for Employee Central Core

There are many use cases why business rules are created for Employee Central data, such as to automate the approval process, identify the correct event reason based on proposed changes, set default values, etc.

SAP SuccessFactors has provided the rule scenarios for each solution's most common use cases, including Employee Central. Here are the rule scenarios for Employee Central Core:

EC Core Rule Scenarios

Rule ScenarioDescription
Generate Assignment ID ExternalThis scenario creates the rules that generate the values for Assignment ID External based on the MDF Sequence objects. Create a single rule only based on this scenario.
Generate Employee ID for Hire/RehireThis scenario generates an Employee ID from the Metadata Framework Sequence (MDF) and assigns it to the User ID field of the Employee Information object during Hire/Rehire with the new employment process.
Rules for Hire/RehireThis scenario will be used for the customer who wants to create any business rules that trigger in hire scenarios. For example, to determine default values or the visibility for certain fields during the hire/rehire process. This limits the base objects to either Employee Information or Employee Information Model.
Trigger onInit Rules for Hire/RehireThis scenario to initialize HRIS Elements during all Hire/Rehire processes (for both old and new employments) using the Employee Information Model base object. Limited to the onInit event type.
Trigger Event Reason DerivationThis scenario is used to derive the event reason automatically for transactions initiated in Job and Compensation Information entities. This limits the base objects to the Job or Compensation Information model.
Generate Employee Central AlertsThis scenario creates the rules that generate alerts for Employee Central data, for example, alerts for job information changes.
Enforce New Employment for RehireThis scenario is for configuring a rule that validates the business requirements to enforce new employment and returns an error message if the conditions are not met.

The rule validates changes made in Job Information. For example, when an employee changes legal entity, the system validates the change based on the rule configuration. The validation either approves the changes or enforces new employment.

Trigger WorkflowsYou can use this scenario to create rules that trigger workflows to approve data changes. In Manage Business Configuration, rules created using this scenario can be assigned only for the onSave event type.
Display Internal Job HistoryThis scenario creates the rules for the Internal Job History block configuration.
Validate HRIS ElementsThis scenario creates business validation and raises alert messages on HRIS elements.
Calculate Full-Time Equivalent (FTE)This scenario calculates a user's full-time equivalent (FTE) using the Job Information Model base object.
Trigger onPostSave Events for Job InformationYou can use this scenario to create rules that trigger events or alerts after changes to Job Information are saved. Rules can only be assigned using onPostSave event type.
Trigger Cross-Entity RulesThis scenario is used to configure cross-entity rules triggered from the source entity, and changes are executed on the target entity. Cross-entity rules can set values for fields in a different entity. For example, you can configure Job Information changes that update Compensation Information. Currently, it is supported only for specific employment-related entities. Currently, only five cross-entity rules are allowed.
Trigger onChange Rules for HRIS ElementsYou can use this scenario to create rules that trigger when HRIS fields are changed. For example, propagating Job Information fields from the Job Classification record. Rules can only be assigned using onChange event type.
Trigger onSave Rules for HRIS ElementsYou can use this scenario to create rules that trigger when saving changes to the HRIS elements. Rules can only be assigned using onSave event type.
Trigger an Off Cycle Event BatchYou can use this scenario to create a rule for an Off Cycle Event Batch that uses the SET operation in the Then statement . This rule is executed during the Off Cycle Event Batch processing job.
Trigger Event for Off Cycle Event BatchYou can use this scenario to create a rule for an Off Cycle Event Batch that uses the EXECUTE operation in the Then statement . This rule is primarily used to trigger PM forms. The rule is executed during the Off Cycle Event Batch processing job.
Trigger onView Rules for HRIS ElementsYou can use this scenario to create rules that default the value for a field, change field properties, or calculate fields that are transient. Limited to the onView event type.
Save Changes to Foundation ObjectsYou can use this scenario to create rules that save changes to Foundation Objects and their fields. For example, defaulting the standard weekly hours to a location.

Migrating Basic to Application-Specific Scenario

Many rules created before the availability of application-specific scenarios use the Basic Rule scenario. These legacy rules can be migrated to application-specific either one at a time or by mass change.

  • To change the rules individually, go to Configure Business Rules. Choose the rule and select Change Scenario.

    This will open the wizard that will guide you through the process.
  • For mass changes, go to Check Tool → Migration tab → Business Rules Application. Run the check and follow the migration steps.

Employee Central standard and model base objects

The base object defines what you can configure in the rule. Unlike MDF objects, Employee Central objects have standard and model base objects. The model base object is required under certain circumstances.

For example, to set field properties, you must choose a Model base object. The base object also defines what event types you can use when you assign the rule to the Employee Central object in the data model. You cannot use onView events for changes done on the Add New Employee screen.

For Model base objects, you can set the following properties:

Required

You can set a field required or not required. Assign the value of ‘true’ or ‘false’

Visibility

You can set the visibility of a field. Choose a value of "None", "Edit" or "View" from the drop-down.

Value

You can use this property when you want to combine setting field properties with setting default or conditional values. When you select Value, you have to select the corresponding value in the drop-down menu when creating the rule.

Previous Value

You can use this property when you want to compare an old value with a new value, for example, when a rule is triggered only when a certain value is changed to a new value.

You can also define that any data change to a specific field triggers the rule. For example, checking for any change to FTE could be done with the rule: FTE. Value is not equal to FTE. Previous Value.

System Handling of Rules

The system processes the onSave rules based on the order defined in the Manage Business Configuration with the exception that the event reason and workflow derivation rules are executed after all the other rules are executed.

The Order in which the onSave rules are executed

  • For rule for Personal Information, where event reason derivation is not applicable, here is a sample order: National ID rules and Workflow Derivation rules.
  • For rules for Job information, here is the order: Job information rules, Event Reason Derivation rules, and Workflow Derivation rules.
  • For saving changes made from Manager Self-Service for both Job Information and Compensation Information, here is the order: Job Information rules, Compensation Information rules, Event Reason Derivation rules for Job information, Workflow Derivation rules for Job Information, Event Reason Derivation rules for Compensation Information, Workflow Derivation rules for Compensation Information.

Event reason derivation rule

Event Reason Derivation Rule automates the selection of Event Reasons for Job and Compensation Information transactions. This compares to manual selection when derivation is not set up. Since the employee status depends on the event reason, it’s crucial to have an accurate event reason.

Setup an Event Reason Derivation Rule

  1. Create a new business rule.
  2. Choose the Employee Central Core → Event Reason Derivation scenario.
  3. Assign a Rule Name and ID for the rule. Do not include any spaces in the rule ID otherwise it won't trigger correctly.
  4. Select the base object. The base object is limited to Job Information Model and Compensation Information Model.
  5. Set the first IF to check if the event reason value is null before setting it through the business rule. You can do this by setting the first IF statement NOT EQUAL to Null and the THEN statement blank, as in figure, Check for Null. This ensures that cases, where the event reason has already been supplied will not be overwritten.
  6. Configure the rest of the rules. Add additional ELSE IF to check for conditions of the change made in the block. Then use the THEN statement to assign a valid Event Reason Value. Include as many ELSE IF … THEN constructs to handle all the possible change scenarios for the block. An example is provided in the figure ERD rule.
  7. Repeat the steps to create additional event reason derivation rules as necessary. See the ERD rule recommendations.
  8. Configure a final rule OR the ELSE statement to assign an event reason if no conditions are matched, also known as a catch-all. If a rule does not set the event reason, the system issues an error, and the initiator cannot bypass the error to make the necessary change.

    Note

    Only a single event reason can be assigned to a transaction.

Example: Event Reason Derivation Rule

Here, you see a sample ERD rule created for ACE whenever there is a change in Standard Weekly Hours. As mentioned previously, we want to ensure the first IF statement validates the event reason to be null before setting it through the business rule.

The succeeding IF statement confirms that there is a change in the Standard Weekly Hours value. You can use any of the comparative operands shown in the image to build the conditions for this rule.

The THEN statement is where you set the event reason value when the condition is met for this transaction.

Assigning ERD

For the rule to be processed, it must be assigned as an onSave event type to the correct HRIS Element, in this case, Job Information.

We must select the Job Information Model as the base object when assigning the rule to the Job Information element when we use the Job Information Model as the base object when the rule was created.

Event reason derivation rule best practices

SuccessFactors recommends several best practices when working with Event Reason Derivation rules.

  • Check for Event Reason Not Equal to Null

    Each ERD rule should have the first condition: IF the Event Reason is not equal to Null, THEN do not process the rule any further. This avoids overwriting the event reason accidentally.

  • Grouping Event Reason Derivation Logic within a Single Rule

    Event Reason derivation logic typically spans a series of logical decisions/conditions. We therefore recommend combining them into a single rule for better system performance and overall user experience. In general, fewer onSave rules lead to better performance.

    Cases where the requirements are more complex and therefore require more event reasons or where changes are frequent, and hence maintainability becomes important, may justify splitting the logic across multiple rules to support easier maintenance. This design may come at some performance cost.

  • Use a Catch-All Rule or a Catch-All Event Reason

    If a rule does not set the event reason, you will get the following error message: "Unable to determine the event reason for the proposed changes" when using MSS. This message is a configuration issue, meaning it was not possible to set the event reason based on the clauses configured for the event derivation rule(s).

    To handle all unspecified scenarios, use a Catch-All Event Reason. This ensures that all transactions are submitted with an Event Reason. You can accomplish this by either of these options:

    • Including the Event Reason as the ELSE statement of the final ERD rule.
    • Creating a separate rule to perform the catch-all. It would be triggered as the last ERD rule.

Workflow derivation rule

Much like an event reason derivation rule, workflow derivation rules allow you to define specific conditions that trigger a workflow. For example, when the employee's salary is increased, a particular workflow is started to approve the salary increase.

Workflow derivation can also work alongside the event reason derivation rule. Using the previous example, when the employee salary is increased, and the system identifies the event reason as a promotion with pay change, the workflow derivation rule can be configured to assign the correct approval process based on this event reason.

Without a rule to automate which workflow is used for the transaction, the system saves the data directly without approval.

Setting Up Workflow Derivation Rule

  1. Create a new business rule.
  2. Choose the Employee Central Core → Trigger Workflows scenario.
  3. Select the relevant Base (Standard or Model) object

    Workflow is supported in the following HRIS Elements:

    • National ID Card
    • Home Address
    • Personal Information
    • Global Information
    • Personal Relationship Info
    • Work Permit Information
    • Job Information
    • Job Relationship Information
    • Employment Information
    • Compensation Information
    • Pay Component Recurring
    • Pay Component Non-Recurring
    • Foundation Objects
  4. Set the IF and ELSE IFs to set the conditions. Here's a sample of a condition to be validated against an event reason value: IF Event Reason.Value = Promotion with Pay Change.
  5. Set the THEN statements to execute the wfConfig value. The wfConfig is the field that stores the workflow record to be executed when the condition is met.

Example: Workflow Derivation Rule

Here, you can see a sample rule that derives the Promotion with Pay Change workflow when the event reason is Promotion-Pay Change.

Note

Only a single workflow can be assigned to a transaction.

Recommendations for workflow rules

  • When possible, have one rule with several IF statements rather than several single rules.

  • When the entity is processed on the UI, the corresponding onSave rule is evaluated, and the workflow assigned in the THEN statement is executed when the condition is met. The system saves the data if a workflow configuration is not assigned using the onSave rule.

  • Workflow derivation rules for new hires must be assigned under the jobInfo entity.

Exercise: Create an event reason and workflow derivation rule

Business Example

ACE Corp wants to automate the event reason and workflow derivation to streamline their business process. You will create a sample ERD rule and review the existing workflow rules in the system. You will assign the rules to the appropriate elements in Manage Business Configuration. Test the rules if they get triggered based on submitted transactions.

Note

You must have completed Prepare an Instance (Unit 1) and Prepare the Data Models (Unit 2) exercises before completing this hands-on. This exercise activity is not required for completing succeeding hands-on exercises for this course.

If you completed the exercise Create a Job Change Event Reason and Workflow, you can use the event reason you created in that exercise.

Watch the video to learn how to create derivation rules.

Steps

  1. Go to Manage Business Rules to create an event reason derivation rule. Create a rule that must use Benefits Adjustment (PAYBEN) as the event reason for transactions involving the Is Eligible for Benefit field in Job Info. Use the table and the screenshot to define the rule.

    Event Reason Rule

    Rule ScenarioTrigger Rules for Event Reason Derivation
    Rule NameERD_JOBINFO
    Rule IDERD_JOBINFO
    Start Date01/01/1900
    DescriptionBenefits Adjustment
    Base ObjectJob Information Model

    1. Navigate to Configure Business Rules.

    2. In Business Rules Admin, select + sign to add a new rule.

    3. Select Employee Central Core → Event Reason Derivation scenario. Fill in the information based on the table, Event Reason Rule and choose Continue.

    4. Set the first If - Then construct for not overwriting an event reason value if it already exists.

    5. Select Add Else If . Add the condition, IF Is Eligible for Benefit value is not equal to Is Eligible Benefit previous value

    6. Add the THEN statement, Set Event Reason Value equal to Benefits Adjustment. Alternatively, if you completed the Create a Job Change Event Reason and Workflow exercise, you can use the JOBINFOCHANGE event reason that was created and permissioned in that activity.

    7. Save.

    8. Make note of the ERD rule (ERD_JOBINFO).

  2. Go to Manage Business Rules to review the existing trigger workflow rules in the system.

    1. Go back to Business Rule Admin and filter the rules in the system using Scenario → Trigger Workflows → Go

    2. There are six workflows for Home Address, Personal Information, Employment Info, Job Info, Compensation Info, Pay Component NonRecurring. Open each one to review the conditions for each rule.

  3. Go to Manage Business Configuration to assign/set the event reason and workflow derivation rules to trigger onSave in the Job Information block.

    1. Navigate to Manage Business Configuration.

    2. Choose jobInfo → Take Action → Make Correction.

    3. Scroll down to the Trigger Rules section.

    4. Add Base object: Job Information Model → Event Type: onSave → Rules: ERD_JOBINFO → Enabled: Yes

    5. Using the up/down arrows on the right, place the rule on top of the jobInfoModel_ERD_migrated_rule

    6. Add the trigger,Base object: Job Information Model → Event Type: onSave → Rules: WF_jobinfo → Enabled: Yes

    7. Select Save.

    8. OPTIONAL: Set the triggers for the other workflow rules.

  4. Go to Marcus Hoff's profile and initiate a change to the Is Eligible for Benefit field to test the event reason and workflow derivation rules.

    1. Navigate to Marcus Hoff Employee Information → Take Action → Change Job and Compensation Information . Choose Job Information.

    2. Select today's date for the effective date.

    3. Change the value of the Is Eligible for Benefit field and select Save.

    4. Check if the request (event reason) is Benefits Adjustment. Check if the workflow is Data Change (DTACHNG) the same as indicated in the WFD rule. Select Cancel to cancel the transaction.

    5. (OPTIONAL): If you added the triggers of the workflow rules, initiate a transaction on those blocks and verify if the rules are working.

Hire and rehire rules overview

Hire and Rehire Rules allow you to apply rules during the hiring process. For example, you can set specific fields to automatically populate in the Add New Employee wizard. The onInit rule must be triggered on initiation or when the page is opened.

You can only use Employee Information or Employee Information Model as base objects for Hire/Rehire rules.

For Employee Central, special base objects, Employee Information/Employee Information Model, were created to allow creating rules that are only triggered when using the Add New Employee form. It also allows all EC objects included in the hire/rehire form to be available for the rule.

Setting up Hire/Rehire Rules

  1. Create a new business rule.
  2. Choose the Employee Central Core → Choose Hire/rehire scenario.
  3. Choose the appropriate base object. The base object is limited to Employee Information or Employee Information Model.
  4. Assign the rule to the applicable object.
  5. Assign the trigger to the appropriate hris element. This it the object being affected in the form. For triggering workflows, the trigger must be assigned in the jobInfo element.

Creation of a new hire rule

The figure, New Hire Rule Example, shows you how to automatically populate areas, like the national ID, for new hires.

Because this is an on-initiation rule, we want it to always trigger without conditions and the values in the THEN settings to be applied. Therefore, the IF section will be marked always true.

The THEN section is where we determine our default field values. Choose employee information, so the values are only to default when the administrator adds a new employee to the system. The rule will not take effect on other screens. Next, we choose the area where we want the field values to be defaulted, for example, national ID. We have set three specific fields: Country = USA; National ID card type = social security number, or the ID which is ssn; and Primary = Yes.

You select the rule event onInit because you want the default values to show up as soon as the administrator opens the Add New Employee screen, independent of any values that the administrator might add on this page.

To validate, open the Add New Employee wizard to check if fields are initiated, as shown in the figure, Validate On Initiation Rule.

Exercise: Create a hire/rehire rule

Business Example

ACE Corp would like to streamline the New Hire process for its admins. Most new hires are in the United States and use a Social Security Number as their primary National Id. In this exercise, you will create a configurable rule that will, as a default, autofill the fields National ID Card Type, Is Primary, and Country.

Note

You must have completed Prepare an Instance (Unit 1) and Prepare the Data Models (Unit 2) exercises before completing this hands-on. This exercise activity is not required for completing succeeding hands-on exercises for this course.

Task 1: Create a Hire/Rehire Rule

Steps

  1. Go to Manage Business Rules to create a hire/rehire rule. Set the IF statement to "Always True". Set the THEN statement to default the country, card type and the is primary fields. Use table to define the rule.

    National ID Rule

    FieldValue
    Rule ScenarioTrigger Rules for Hire/Rehire
    Rule NameUSA National ID
    Rule IDINIT_NAT_ID
    Base ObjectEmployee Information

    THEN Statement

    THEN STATEMENT
    SetNational ID Information Countryto be equal toTextUSA
    SetNational ID Information Is Primaryto be equal toBooleanYes
    SetNational ID Information National Id Card Typeto be equal toTextssn

    Note

    The order of the expressions in the rule does matter. It should be Country, then Is Primary, then Card type. The values are also case-sensitive

    1. Go to Configure Business Rules.

    2. Select Create New Rule (+).

    3. Expand Employee Central Core Scenarios and select Trigger Rules for Hire/Rehire.

    4. Create the rule using the table, National ID Rule.

    5. For the condition, set the IF statement to Always True.

    6. For the action, follow the table, THEN Statement.

    7. Enter each SET as separate expressions.

    8. Delete extra entry lines from the collection filter.

    9. Save.

Task 2: Assign the Rule

Having created the rule, you will now associate the new rule with the HRIS field or element.

Steps

  1. Go to Manage Business Configuration to assign/set the rule to trigger onInit in the National ID Card block.

    1. Navigate to Manage Business Configuration.

    2. In the HRIS Elements, select nationalIdCard.

    3. In the Trigger rules, select the following triggers: Employee Information onInit USA National ID.

    4. Save the change. Accept the changes to the Data Model by BCUI by choosing Yes.

Task 3: Test the Rule

Having created the configurable rule and associated it with the HRIS element, and you will now need to test the rule.

Steps

  1. Use the Add New Employee wizard to test if the National id fields are prepopulated.

    1. In your instance, go to Add New Employee and enter the following details:

      FieldValue
      Hire Date[Today’s date]
      CompanyACE USA
      Event ReasonNew Hire

    2. In the National ID Information screen area, verify that "United States" appears in the Country field and "Social Security Number" appears in the National Id Card Type field, as default.

    3. Select Cancel.

Propagation rules overview

Employee data often relies on the foundation object records created in the system. For example, when adding job information for a user, you'll need to enter a location, timezone, and other information. To make data entry more efficient and accurate, you can create a default value for the timezone field based on the location record.

In the figure, Propagate Timezone, you can see the employee works in ACE_USA and is located in San Mateo. To change the user's location, we don't need to update the timezone field manually. Instead we can create a propagation rule that will copy the timezone data in the location record.

You can define propagation rules to have the system automatically copy the data from one field to another. This way, you can have the same data in several places of the system while maintaining the data in a single field. Here are some examples of typical use cases:

  • Update Job Codes in Employee Central

    Whenever the jobcode is changed in Employee Central, THEN … retrieve all the job-code-related data from the job-related foundation objects to update the data in the Employee Central.

  • Propagate FLSA Status

    IF… the country is USA, AND the job classification is changed THEN… propagate the FLSA status to Job Info.

  • Propagate Standard Hours

    IF… the legal entity is changed in Job Info THEN… propagate the standard hour to Job Info.

Creation of a propagation rule

Setting up Propagation Rules

  1. Create a new Business Rule.
  2. Choose the Trigger Changes to HRIS Elements scenario.
  3. Choose the appropriate base object or subject for the rule.
  4. Create the Rule logic.
  5. Assign the rule. Propagation rules can be assigned at the object or field levels (onChange).

In a sample configuration for ACE, a propagation rule is created so that the Timezone field in Job Information matches the location's timezone whenever the Location field is changed.

In the figure, IF Statement, you can see that the IF statement is set to Always True, which means there are no conditions to be met. Therefore, the system will always update the user’s timezone to the location's timezone when the rule is triggered.

In the figure, Assign the Rule, we see that the propagation rule is assigned at the field level, specifically to the Location field of the Job Information element.

With the onChange event type, we are assured the rule is triggered whenever the location value is changed.

Exercise: Create a propagation rule

Business Example

ACE Corp wants to use a business rule to propagate fields in Job Information. When updating Job Information, the Employee Class and Pay Grade must be auto-populated from the Job Classification record selected.

Note

You must have completed Prepare an Instance (Unit 1) and Prepare the Data Models (Unit 2) exercises before completing this hands-on. This exercise activity is not required for completing succeeding hands-on exercises for this course.

Steps

  1. Test the existing setup for Job Information. Update Wilma Sown's Job Classification to Senior Director, Sales and verify that the pay grade does NOT change. Do NOT save your transaction.

    1. Log in to your instance.

    2. Navigate to Wilma Sown → Actions → Change Job and Compensation Info .

    3. Select Job Information and set the effective date to Today.

    4. Change Job Classification → Senior Director, Sales (SALES-SR_DIR).

    5. Verify that the pay grade does NOT change.

    6. Cancel your changes.

  2. Create a propagation rule that copies the values of the Job Classification’s Employee Class and Pay Grade fields to the Job Information’s Employee Class and Pay Grade fields. Use the table and the image to define the rule:

    Rule Parameters

    Rule ScenarioTrigger onChange Rules for HRIS Elements

    Rule Name

    Propagate Job Classification to Job Info

    Rule ID

    Propagate_Job_Classification_to_Job_Info

    Start Date

    01/01/1900

    Description

    For configuring jobClassification to jobInfo field propagations

    Base Object

    Job Information Model

    1. Go to Configure Business Rules.

    2. Select + to add a new rule.

    3. Select Trigger onChange Rules for HRIS Elements rule scenario.

    4. Complete the rule properties on the right side of the page according to the table and choose Continue.

    5. Complete the IF and THEN statements of the rule according to the Image.

    6. Choose Save

  3. Go to Manage Business Configuration to assign/set the rule to trigger onChange in the job-code field.

    1. Navigate to Manage Business Configuration.

    2. Under HRIS Elements, choose jobInfo.

    3. Locate the job-code field.

    4. Select Details.

    5. Go to the Trigger Rules section. Set the Base Object to Job Information Model . Set the event type to onChange.

    6. Select the rule Propagate Job Classification to Job Info.

    7. Select Done and Save.

    8. If required, choose Yes if a confirmation box appears for required adjustments to the data model.

  4. Go to Wilma Sown's profile to test the rule to verify if the propagation works when the Job Code field value is changed.

    1. Log in to your instance.

    2. Navigate to Wilma Sown → Actions → Change Job and Compensation Info .

    3. Select Job Information and set the effective date to Today.

    4. Change Job Classification to Senior Director, Sales (SALES-SR_DIR) .

    5. Verify that the pay grade DOES change.

    6. Cancel your changes.

Cross-entity rules overview

Cross-entity rules can set values for fields in a different entity. Currently, it is supported only for these specific employment-related entities:

  • Job Information
  • Job Relationship Information
  • Compensation Information
  • Recurring Pay Component
  • Non-Recurring Pay Component
  • Employment Information

The source/target direction is important. The source element must be the base object of the rule.

The common use cases for cross-entity rules are:

  • Changes to Job Information (for example, company, location, and/or employee class) that then update Compensation Information
  • Changes to Job Information that then update Job Relationships
  • Changes to Job Information (for example, pay scale level, FTE) that then change (create, update, delete) Recurring Pay Components
  • Changes to Compensation Information (custom field with annual salary) to update amounts in a Recurring Pay Component

The History UI and Imports only support onSave rules for cross-entity rules. Generally, onChange rules work when both entities are displayed on the UI, for example, in Manager Self-Service UIs.

You can have a maximum of five cross-entity rule scenarios for an HRIS entity.

Note

For the additional details on Cross-Entity Rules go to the Implementing Employee Central Core guide in the Help Portal.

Exercise: Create a cross-entity rule

Business Example

ACE Corporation wants to leverage the auto-population function of Employee Central by adding an HR Manager to the Employee based on the Business Unit selected.

In this example, you will configure individuals assigned to the Corporate Industries Business Unit in the Ace USA legal entity to have Nancy Nash as their HR Manager.

Note

You must have completed Prepare an Instance (Unit 1) and Prepare the Data Models (Unit 2) exercises before completing this hands-on. This exercise activity is not required for completing succeeding hands-on exercises for this course.

Steps

  1. Go to Manage Business Rules to create a cross entity rule that adds Nancy Nash as the HR Manager when the Employees are assigned to the Legal Entity (Company) Ace USA and Business Unit Corporate Industries in their Employee File. Use the table and image to define the rule:

    Rule ScenarioTrigger Cross-Entity Rules
    Rule NameAssign Corporate Industries HR Manager
    Rule IDAssign_Corporate_Industries_HR_Manager
    Start Date01/01/1900
    Description 
    Base ObjectJob Information Model

    1. Go to Configure Business Rules.

    2. Select + to add a new rule.

    3. Select Employee Central Core → Trigger Cross-Entity Rules rule scenario.

    4. Complete the rule properties on the right side of the page according to the table and choose Continue.

    5. Complete the IF and THEN statements of the rule according to the image.

    6. Choose Save.

  2. Go to Manage Business Configuration to assign/set the rule to trigger onSave in the Job Information block.

    1. Navigate to Manage Business Configuration.

    2. Under HRIS Elements, choose jobInfo.

    3. Under Trigger Rules, set the last trigger Base Object to Job Information Model.

    4. Under Trigger Rules, set the event type to onSave.

    5. Under Trigger Rules, select the rule Assign Corporate Industries HR Manager.

    6. Select Save.

    7. If required, choose Yes if a confirmation box appears for required adjustments to the data model.

  3. Go to Susan Shue's profile to test your rule. To test the rule without the approval process, you can disable the WF_jobinfo rule in Manage Business Configuration temporarily or initiate the transaction in the Job Information History using Transfer event and Department Change as event reason.

    1. Log in to your instance.

    2. Navigate to Susan Shue → Job relationships .

    3. Verify that no Job Relationship Entries exist.

    4. Choose Actions → Change Job and Compensation Info .

    5. Select Job Information and set the effective date to Today.

    6. Change Department to Sales. Note the Legal Entity and Business Unit match the IF criteria in the rule.

    7. Save the changes. Select Submit to go through the approval process.

    8. There are three approval steps. Use proxy to approve each step.

      The approvers are:

      1. Step 1: Darlene Sharp
      2. Step 2: Sid Morton
      3. Step 3: Talent Approval (you can proxy as Alex Anderson)

    9. Once the workflow has been completed, refresh the Employee File Page.

    10. Verify that a new entry appears for Nancy Nash in Job Relationships.

Addition of context to Business Rule

Business Rule Context

Rule Context narrows down the situations where the business rules are applied. For example, you’d like to avoid triggering a workflow derivation rule on mass changes, as it may launch as many workflows as the number of employees subject to the mass change.

Rule Context can be applied to onSave and onChange rules only.

Set the value to NO if you do not want the rule triggered for that purpose. By default, the rule context is set to Yes for all situations.

Note

These contexts are currently only for HRIS elements, not MDF objects. The contexts are also only for onSave and onChange rules.

Following are some of the recommendations for when rule contexts are useful.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn