Why Event Reason derivation set-up is required?
Since there can be multiple changes to Employee data hence it is difficult and time consuming for HR Admins to select the event and event reason from UI everytime. Therefore, we set up event derivation rules that define the event reason according to what change is done to employee’s data and the system automatically selects the appropriate event reason. Further the employee status is derived from Event Reason so employee status is updated too accordingly.
How to set up these rules?
The onSave rules to set event reason can be assigned in the Business Configuration UI. This is saved in the Succession Data Model (SDM) for the corresponding entity and no provisioning access is required.
Can we create rules for New Hire, Rehire and Terminate?
No. You can only configure rules for event reasons that are used under Employment Information in the Job Information portlet or in the Compensation Information portlet.
You cannot create rules for Hire, Rehire, Terminate, Leave of Absence and Return to work.
Can we create one rule per event reason?
The best practice is to create one business rule per HRIS element and group the derivation of all event reasons using if else conditions. You can create one rule for Jobinfo and one for Compinfo as shown below.
This improves performance because if you have more OnSave business rules the system will take more time to process them.
Job Information Model –
Compensation Information Model –
How to configure the sequence/priority of event reasons?
All onSave rules configured for an entity/element are evaluated. The value of the event reason set by the last matching rule is considered by system. For example if you have configured rules as below –
Let’s say from employee profile via ‘Job and Comp change’ the Position was changed in Job info and salary was updated in Compinfo. After saving the updates you will see ‘Position change‘ event reason in Employment info since this event reason is the last matching rule.
In case you configure one rule per HRIS element for all event reasons then sequence depends from top to bottom and the event reason is set by the condition which is met first. For example, if rule for Jobinfo is configured as shown below –
Upon updating the Standard weekly hours and Employee class in Jobinfo portlet of employee you will see ‘Change in schedule‘ event reason logged in the employee profile since the condition of this event is met first in the if-else block.
How to derive event reason for scenarios not configured in the rule?
If you have not covered all possible secenarios in you business rules, the system will not be able to determine an Event Reason so a ‘catch rule‘ should always be configured as shown below.
If you have multiple rules for different event reasons then a separate rule can be configured as below.
It is best to create one rule for all event reasons per HRIS element. Then last condition in the if-else blocks will be like this –
This means for all remaining scenarios ‘Data change’ event will be triggered.
Are Event reason derivation rules triggered during Hire or Add Global assignment or Concurrent Employment?
Yes. That’s why you should always add in your if clause an additional condition where the event reason is equal to null otherwise event reason rule may get triggered overwriting the hire/Global Assignment/Concurrent Employment. You can see this additional condition in screenshots above.
Can I configure country specific event reasons?
Yes. Refer this page for more information.
Are the event rules triggered from Position Org cart?
When position attrbutes are updated from Position Org chart the Position to Jobinfo Sync rule is triggered which triggers the event rules.
Why manager change event event reason is logged separately in Job info when I update parent position and other attributes of position from Position Org chart?
Position to Job Info Synchronization takes care of synchronizing the Position values to Job Info based on the fields defined in the Pos2Job sync rule. Supervisor/Parent position field cannot be added in the rule as the adaptation is performed by the system via background job which syncs the supervisor by creating a second record in job info.