5.3 Propagation Rules and Hire/Rehire Rules

5.3 Propagation Rules and Hire/Rehire Rules

Quick Answer: A propagation rule copies data from a source, usually a foundation object, into employee data so it is maintained in one place. It is typically an onChange rule on the driving field. For example, changing Job Classification sets Pay Grade and Employee Class. Hire/Rehire rules use the special base objects Employee Information or Employee Information Model and run only on the Add New Employee form. They typically use onInit to prefill fields as the page opens.

Why Propagation Matters

Employee records depend on foundation data. THR81 stresses that corporate (foundation) data must be set up before employee data, because the job classification holds the job code, job title, pay grade, and standard weekly hours that employee records reuse. Once the foundation data exists, propagation rules fill parts of the employee record automatically. This reduces data entry errors. If Engineer (ENG) is chosen as the job classification during a hire, the related pay grade and weekly hours are filled in.

Typical propagation use cases from THR81:

• Update job codes: whenever the job code changes, retrieve all job-related data from the job foundation objects.
• Propagate FLSA status: if the country is USA and the job classification changes, set the FLSA status in Job Info.
• Propagate standard hours: if the legal entity changes in Job Info, set the standard hours.
• Propagate timezone: when the location changes, copy the location's timezone into Job Info.

Building a Propagation Rule

THR81's exercise copies Employee Class and Pay Grade from the selected Job Classification:

Assign it at field level: in Manage Business Configuration > jobInfo, open the job-code field's Details, and in Trigger Rules select base object Job Information Model, event type onChange, and the rule. Save, and accept any data model adjustments.

Test it: open Actions > Change Job and Compensation Info for an employee, choose Job Information with today's date, change the job classification, and confirm that the pay grade now changes. Cancel so nothing is saved.

In the timezone example, the rule is assigned to the location field with onChange, with IF set to Always True. The user's timezone always follows the location's timezone when the location changes.

Why onChange and not onSave? onChange fires the moment the driving field changes, so the user sees the propagated values while completing the form. An onSave rule would set the values only when the page is saved.

A Related Scenario: Save Changes to Foundation Objects

When the logic belongs to a foundation object record, use the scenario Save Changes to Foundation Objects. SAP's example defaults the standard weekly hours on a location. FO records created in Manage Organization, Pay and Job Structures can also use onInit rules to set defaults as the new record opens.

Hire/Rehire Rules

For Employee Central, SAP created special base objects, Employee Information and Employee Information Model, for rules that should run only on the Add New Employee form. They also make every EC object included in the hire form available to the rule.

Setup steps:

1. Create a rule with an Employee Central Core scenario: Rules for Hire/Rehire or Trigger onInit Rules for Hire/Rehire.
2. Choose Employee Information or Employee Information Model as the base object.
3. Assign the trigger to the HRIS element being affected on the form. Rules that trigger workflows for new hires must be assigned in jobInfo.

Worked Example: Default the US National ID

Most of ACE Corp's hires are in the United States and use a Social Security Number. THR81's rule prefills the National ID section:

Two details from SAP's exercise often decide success:

• The order of the expressions matters: Country, then Is Primary, then Card Type. The card type list depends on the country.
• Text values are case-sensitive: USA and ssn must match the stored codes.

Because the event is onInit, the defaults appear as soon as the administrator opens Add New Employee, before anything is entered. Other hire screens are not affected because the base object is Employee Information.

Choosing Between the Patterns

Common Mistakes

• Creating the rule but not assigning it, so nothing happens.
• Assigning an onChange rule at element level. onChange works only at field level.
• Choosing a different base object in BCUI from the one used to build the rule.
• Forgetting permissions for newly propagated or enabled fields, so users cannot see the results.