SuccessFactors Employee Central Event Reasons Derivation FAQs
Why is Event Reason derivation set-up 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 every time. 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 your business rules, then 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 attributes are updated from Position Org chart the Position to JobInfo Sync rule is triggered which triggers the event rules.
Why manager change 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.
While working with cross entity rules, how does event reason derivation work?
As you know we have source and target entity in cross entity rules, so the event reason in target entity is derived from the source entity. As cross entity rule supports other portlets also which doesn’t have event reason so in that case the event reason for target entity must be set explicitly in the rule. If not, system will give an error.
Is the Event reason derivation rule triggered through Imports?
If you have a column for event reason and the value is provided in the import template, then that event reason is taken into account rather than the event reason derivation by onSave business rules. If an event reason column is there in import template but is empty, then the event reason is derived using the onSave business rules.
As event reason derivation rule for Job info and Comp info are different, if both portlets have different event reason derivation logic, then which event reason takes precedence?
System will get event reason in both job info and comp info portlet from Job info derivation rule, if no event reason gets derived from job info, then event reason from Comp info derivation rule gets derived on both job info and comp info.
Thanks for the blog! I'm glad you've posted this because I would love to discuss the topic of event derivations. In the blog, you mention that you use a single business rule for event derivation. I have always split event derivations into multiple rules. The reason is I find them to be more easily maintained. For example, if the customer decides that they want to change the priority, using multiple rules means you simply move the rules up or down. If you have one big business rule you are forced to cut/paste within the rule which gets to be complicated to and messy.
I haven't found any performance issues because I make the first "if" condition for each event derivation business rule check whether an event reason has already been chosen.
Obviously, you are doing things differently, which is defensible. I just wish there was a good forum where us consultants to really discuss the pros/cons of each approach to an issue.
Would you mind sending a screenshot how you configured the rule -'I make the first “if” condition for each event derivation business rule check whether an event reason has already been chosen'.
Manu / Brandon,
Do you find that with using derivation, you can influence the customer to maintain less Event Reasons? It seems to make sense to do so, but I understand sometimes you cannot minimize them for reporting reasons.
As partners , what are some of the common event reasons thats been suggested to clients. would be helpful if you could share most commonly used reasons in implementations.
Is there any guidance/rule for clients to determine that this change should be a specific event reason vs grouped under data changes. Is Reporting a driving factor to determine a specific reason . For instance , if we want to track all promotions that we decide it to be a specific reason. Are there any other such criteria that demands a specific reason to be created. We track critical ones like promotions , transfers, pay changes, Company Changes and others are clubbed into data changes etc. wondering what is the best practice?