Skip to Content
Technical Articles

SuccessFactors Employee Central Event Reasons Derivation FAQs

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

5 Comments
You must be Logged on to comment or reply to a post.
  • Manu-

     

    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.

    • Brandon Toombs,

      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.

     

    Andy

    • It’s configuration team to decide how to maintain event derivation and maintaining less number of event reasons is something which depends on customers business model. Usually as an implementation partner we can suggest but final call is taken by customer.
      • Good blog.

        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?