SAP Learning Journey

Creating business rules for Employee Central transactions during implementation

Objectives
After completing this lesson, you will be able to:

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. Business rules can be applied to any application of SAP SuccessFactors. In this unit, we will only cover the rules for Employee Central Data.

Process Overview of Configuring Business Rules

Configuring business rules is a two-step process that consists of creating and assigning the business rule. The general steps are as follows:

  1. Business Rule Creation
    1. Define the IF statement – The IF statement in the rule refers to what conditions must be met for the system to react.
    2. Define the THEN statement – The THEN statement in the rule refers to the action the system will take once the conditions are met.
  2. Assignment of Rule
    1. To determine how rules must be assigned, first, determine what user action must trigger the rule. Is it when the user is saving the data, when they are opening the page, or when changing a field?
    2. Depending on the trigger, the rule can be assigned at the field or object levels.

The Rule Logic

Most business rules are comprised of IF and THEN statements.

IF Logic

IF statements are the conditions in the rule that must be validated. The IF logic uses "and"/"or" statements to determine when the THEN logic should be executed. 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, also known as, Always True, which means there are no conditions for the system to check. Once the rule is triggered, the system will always react the way it was configured in 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 a rule is triggered. For example, you can remove a pay component when the employee moves away from London.
  • Execute: Carry out specified action when the rule is triggered.
  • Add to: Add items to a collection when a rule is triggered. 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.

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. For example, 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 dropdown.

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 dropdown 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.

Rule events and scenarios

Complete the interaction below to learn about the rule event types.

Rule scenarios for Employee Central Core

There are many use cases why business rules are created for Employee Central Data, such as to automate workflow, event reason, data propagation, 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
Rules for Hire/RehireThis scenario will be used for the customer who wants to create any business rules that should be triggered 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.
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.
Trigger WorkflowsThis scenario removes irrelevant options or settings in a generic business rule scenario (Basic). It offers special support when you define the THEN statement of your business rule. SAP recommends using this business scenario to create all your workflow business rules.
Internal Job HistoryThis scenario creates the rules for the Internal Job History block configuration.
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.

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.
Generate AlertsThis scenario creates the rules that generate alerts for Employee Central data, for example, alerts for job information changes.
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.
Calculate Full-Time Equivalent (FTE)This scenario calculates a user's full-time equivalent (FTE) using the Job Information Model base object.
Validation for HRIS ElementsThis scenario creates business validation and raises alert messages on HRIS elements.
Trigger onPostSave Events for HRIS ElementsYou can use this scenario to create rules that trigger events or alerts after changes are saved to HRIS elements.
Trigger Changes to HRIS ElementsYou can use this scenario to create rules that trigger changes to HRIS elements. For example, propagating Job Information fields from the Job Classification record.
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.
Note

Only use the basic scenario when no other application-specific scenario fits. You can change existing rules from basic to application-specific or application-specific to another application-specific scenario.

Migrating Basic to Application-Specific Scenario

Many rules created before the availability of application-specific scenarios use the Basic 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 to 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.
Note
Warning messages may appear on the business rule admin page to encourage users to migrate their rules from basic to the application-specific scenario.

Event reason derivation rule

Event Reason Derivation Rule aims to automate the selection of Event Reasons for Job and Compensation Information transactions compared 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. The rule ID should not have any spaces, or it will not 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 the appropriate 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 validates if 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 take effect, it needs to be attached to the appropriate HRIS Element, in this case, Job Information.

Because the Job Information Model was used as the base object when the rule was created, we must also select the Job Information Model as the base object when assigning the rule to the Job Information element.

The rule event for an ERD scenario must be onSave to work properly.

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 that we recommend combined into a single rule for better system performance and overall user experience. In general, fewer onSave rules lead to better performance.

    As a general leading practice, event reasons should be designed to be logically simpler by being fewer in number. This is due to being more generic instead of granular and specific.

    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 same example as above, 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 appropriate approval process based on this event reason.

Without a workflow derivation rule or if the rule is not assigned, the system saves the data directly without approval.

Setting Up Workflow Derivation Rule

  1. Ensure the Provisioning setting Enable Business Rules for Workflow Derivation is activated.
  2. Create a new business rule.
  3. Choose the Employee Central Core → Trigger Workflows scenario.
  4. 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
  5. Set the IF and ELSE IFs to check the conditions that should trigger a workflow. If the workflow to be triggered is based upon an event reason value, the condition would be like IF Event Reason.Value = Promotion with Pay Change.
  6. Set the THEN statements to set the wfConfig value. wfConfig is the field that stores the workflow record to be triggered with the transaction.

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.

When the workflow derivation rule uses the event reason in the condition, the rule must be assigned after the event reason derivation rules in Job or Compensation Information element.

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 appropriate workflow configuration assigned is triggered if the rule condition is met successfully. 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.

  • Checking whether the wfConfig field is null before assigning a value can prevent overwriting the field wfConfig value.

  • All the onSave rules configured for an entity/element is evaluated. The system considers the value of the workflow configuration set by the last matching rule.

Rule order with derivation rules

When utilizing workflow derivation (WF) rules that have conditions based upon the event reason, you must order the rules properly.

The ERD rules must run before the workflow derivation rules. Otherwise, no workflows will be triggered. In the scenario where the configuration on Job Information uses a single ERD rule, a single WF rule, and a catch-all, the appropriate order is:

  1. ERD
  2. Catch all
  3. WF

This ensures the event reason field already has a value when the workflow derivation rule runs.

Exercise: Create an event reason and workflow derivation rule

Business Example

ACE Corp wants to automate event reason and workflow derivation to streamline their business process. You will configure a test rule that will assign the event reason and workflow for a change in Standard Weekly Hours.

Note

Note: If you completed the exercise Create a Job Change Event Reason and Workflow, you could use the event reason record and workflow record created in that exercise.

Steps

  1. Turn on Business Rules for Workflow Derivation in Provisioning.

    1. Log in to Provisioning.

    2. Navigate to Company Settings.

    3. Activate the setting, Enable Business Rules for Workflow Derivation.

    4. Select Save Feature, and enter the company ID to confirm the changes.

  2. Create a Job Change Event and a Workflow derivation rule. Use the table, event reason rule and workflow rule, respectively. A screenshot of the rules is included for guidance.

    Event Reason Rule

    Rule ScenarioEvent Reason Derivation
    Rule NameERD_JOBINFO
    Rule IDERD_JOBINFO
    Start Date01/01/1900
    DescriptionFull-Time Employee Status Change
    Base ObjectJob Information Model

    Workflow Rule

    Rule ScenarioTrigger Workflows
    Rule NameWF_JOBINFO
    Rule IDWF_JOBINFO
    Start Date01/01/1900
    Base ObjectJob Information

    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. Make note of the ID for your ERD rule (ERD_JOBINFO).

    6. Select Create New Rule.

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

    8. Use the If/Then statements such that IF the event reason is Standard Hours changed to trigger the Job Change workflow (see Image).

    9. Make note of the ID (WF_JOBINFO)

  3. Add the Rule to trigger onSave in the jobInfo block. Add the trigger using Manage Business Configuration.

    1. Navigate to Manage Business Configuration.

    2. Choose jobInfo.

    3. Scroll down to the Trigger Rules section.

    4. Add the rule ERD_JOBINFO to the list as an onSave rule.

      NOTE: You will have to choose the base object first.

    5. Add the rule WF_JOBINFO to the list as an onSave rule.

      NOTE: You will have to choose the base object first.

      Note
      There is an existing onSave rule in jobInfo. The order of the rules matter. Arrange the rules as follows (you can use the up/down arrow to rearrange the order):
      1. ERD_JOBINFO
      2. Existing rule (migrated ERD rule)
      3. WF_JOBINFO

      Adjust the rule order according to the note using the up/down arrows on the right.

    6. Select Save. You might get a large Confirmation popup message. Select Yes.

  4. Test your new Workflow and Event Reason 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 Standard Weekly Hours field and select Save.

    4. Check if the event reason and workflow steps are visible in the request screen.

      Result

      Do these match the desired result?

      The event reason will appear in the statement Submitting XXXXX request for Marcus Hoff.

      The Workflow Job Change has the following approvers:

      • Manager Manager (Target)

      • Employee HR (Target)

      For Marcus Hoff, this will be Alexander Thompson and Nancy Nash.

    5. Select Cancel → Cancel . Don’t save to return to Marcus’ Employee File.

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.

ExerciseStart Exercise

Task 1: Create the Hire/Rehire Rule

Steps

  1. Create the rule using the information provided in the following tables:

    National ID Rule

    FieldValue
    Rule NameUSA National ID
    Rule IDINIT_NAT_ID
    Base ObjectEmployee Information

    THEN Statement

    Then
    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

    1. Go to Configure Business Rules.

    2. Select Create New Rule (+).

    3. Expand Employee Central Core Scenarios and select 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.

      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

    7. Enter each SET as separate expressions.

    8. Delete extra entry lines from the collection filter.

    9. Save.

Task 2: Associate the New Rule to the HRIS Field or Element

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

Steps

  1. Associate the new rule to the HRIS field or element.

    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. Test your rule.

    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. If we are to change the user's location, we don't need to update the timezone field manually; 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.

Steps

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

    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 Propagate Job Classification to Job Info Business 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 create the rule:

    Rule Parameters

    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 Changes to 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. Set a trigger on the Job Information Block to run the rule from step 2 when the field Job Code changes.

    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. Test your propagation rule.

    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 very 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 5 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.

Steps

  1. Create a Cross Entity rule that creates an HR Manager Job Relationship entry for Nancy Nash 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 create the rule:

    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 → 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. Set a trigger on the Job Information Block to run the rule onSave.

    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. Test your rule.

    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.

    8. Refresh the Employee File Page.

    9. 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.

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

Save progress to your learning plan by logging in or creating an account

Login or Register
Continue to quiz