Event reason is an activity derived from events that drives changes in employee data. These events are predefined for all instances and cannot be added (as of 1508). Of course, you can deactivate part of them or rename the current events if needed. Standard events delivered from SuccessFactors are listed below (today we will focus on those marked green). The reason why to focus only on these is that they are all available in MSS and we will try to find a the right approach how to offer the managers a simple way to use the SuccessFactors to manage employees.
● Additional Job – this event is not used. When activating additional job, you go to the new hire process and use the event Hire
● Assignment Completion
● Job Change
● Completion of Probation
● Data Change
● Job Reclassification
● Leave of Absence (used for time off activities)
● Pay Rate Change
● Position Change
● Return from Disability
● Return to Work (used for time off activities)
● Add Global Assignment
● End Global Assignment
● Start Pension Payout
We can of course add Global Assignment activities as manager facing as well but for our purposes the others will be sufficient enough. You can work with events and event reasons in two ways. Either activate the automated event and event reason derivation or let the manager define them manually.
Automated Event Derivation
In event derivation you don’t need to teach managers anything and they will select what they want to do just by selecting the right activities in self-service. In case of event derivation you do not need to instruct managers much in advance. They just do the required changes in respective fields.
Now we will as Marcus Hoff change the job information of my direct report Judy Hoffman. See the picture below
You can see that we have as a manager permissions to change almost everything. So we can change the Department for Judy. This is the rule that covers this option:
You can see that the basic object is Job Information Model. The reason why to use the Job Information Model is that you can compare Previous Value to Current Value as they are both defined there. When the change in Department happens the event reason Position Reclassification is populated to the job information history of the employee and workflow Job Change is triggered. To activate this rule you need to assign it to the Job Information section in the data model.
The rule is configured as Event Type onSave. Other types don’t make sense to use as you cannot start workflow before you save the form.
Manual Choice of Event and Event Reason
Now let’s move to the second type where managers choose the event and event reason which should be assigned to the activity.
In this case the list of available events and event reasons if offered to the managers. There are about 200 event reasons delivered from the SuccessFactors that you can easily use with the events. The configuration is little bit easier than the configuration of event derivation. You can set the rule in different ways.
You are now defining the event reason and according to the it you trigger the right workflow.
When you use the events this way you always need to keep in mind that when you have the dynamic role in the workflow you have to always specify the Event reason in the role setting. All other configuration is the same.
Let’s now make the decision what approach is better to use in which cases:
- Event derivation – When you are restrictive to managers and allow them to do as less as possible the event derivation is not good for you. When managers can choose only a new position for their direct reports it makes no sense to use the event derivation because the event would always be the same.
- The manually selected events and event reasons can help the managers decide and specify what they actually want to do.
- On the other hand event derivation can simplify the process for managers because they don’t need to specify the event reason as it will be selected according to the HR rules.
- Automated event derivation can also provide more valuable results for reporting at the data are 100% consistent and there is no way how to assign wrong event or event reason to a specific transaction.