Event Reason Derivation
| No Event Reason Derivation | Event Reason Derivation (Preferred) |
|---|---|
| Event and Event Reason are manually chosen for changes made to employee data | Use Business Rules to trigger an Event, Event Reason, and Workflow based on changes made to employee data |
| Use Business Rules to connect Workflow to triggered Event Reason | Requires more initial setup |
| Quicker more simplified solution | More accurate reporting |
| User-friendly |
You learned that Event and Event Reasons are mandatory for employment-related transactions. When managers initiate a transaction, they manually choose the appropriate event and event reason, making it error-prone and the resulting reports unreliable.
To streamline this process, Event Reason Derivation (ERD) can be set up for customers so that the system automatically selects the correct event reason according to the changes made to an employee's data. The employee status is updated, if necessary, depending on the event reason.
Appropriate event reasons are determined using business rules. ERD requires a lot of initial setups since each possible data change in Job Information and Comp Information must be anticipated and tied to a specific event reason. For example, the system must differentiate between employee transfers, promotions, location changes, pay changes, position changes, etc.
Customers who want ERD set up for their system should first determine the event reasons they need to cover for all types of changes in the system. Then they need to determine the field changes associated with each event reason. If a rule does not set the event reason, the system issues an error, and the initiator cannot resolve the error.
For Hire, Rehire, and Termination events, event reasons are manually selected. You cannot create a derivation rule to assign event reasons for such events automatically.
If a customer chooses not to use ERD, the Event and Event Reason will always be chosen by the user initiating the transaction. For Job Information edit and history transactions without ERD, managers and admins only have access to events with at least one event reason for which they have Edit permission.
Business rules can trigger a workflow tied to the event reason to ensure the transaction goes through the appropriate approval process before it is active.
Bypassing Event Reason Derivation
Even with Event Reason Derivation turned on, those given the RBP rights to Insert New Record from the history of jobInfo and compInfo blocks can bypass this process. If you do not go through the Take Action button available on employee files, you will manually choose the event and related event reason for the change you are making. When you update the necessary fields and choose Save, the change is automatically stored, and no workflow is triggered.
This is referred to as an HR Edit and only given to an administrative audience.
To review, when ERD is turned on and the individual performing the change navigates through Take Action or uses the Pencil icon (edit) on the block the system chooses the correct event and event reason. This then triggers a workflow if one is configured for that particular change. If the individual navigates through History → Insert New Record, they must manually choose the event and event reason, and no workflow is ever triggered.
Event Reason Derivation on Imports
To have the event reason derived during imports, you must enable the Enable Business Rules for selected entities’ permission for imports.
If a value is entered in the event reason column of the import template, it takes precedence over the Employee Reason Derivation by the onSave rule. If the column is empty, the event reason is derived by the onSave business rule.