Before You Begin: No workflows are assigned to the HR event by default, and you must manually add them.
After you create the necessary workflows, you must manually associate them with status updates that occur in the Recruiting module. You establish the association between status updates and workflows using the Job Application Status Changed event in Workflow Administration > HR Events.
When you select the event in the sidebar, the Triggered Workflows section is displayed where you can add one or more workflows
Note the following for the Job Application Status Changed HR event:
- Whenever a candidate's status is updated in the Recruiting module, the HR event automatically begins to trigger the workflows that you assigned in the Triggered Workflows section.
- It isn’t possible to guarantee the order in which the HR event triggers the workflows that you added to the list in the Triggered Workflows section.
- Once it triggers a workflow where a condition is true, the HR event is "consumed" by the workflow. This means that it will no longer trigger the remaining workflows on the list.
Note: When you select the Job Application Status Changed event, the Triggering Forms section is also displayed. This section isn’t used for this HR event and can be ignored.
Example:
You add three notification workflows to the triggered workflow list: one for New status, one for In Progress status, and one for Declined status.
When a candidate submits a new job application (in which case, the system automatically assigns them the New status), the HR event begins to trigger the workflows. In this case, the Declined status workflow was triggered first, followed by the New status workflow, while the In Progress workflow wasn’t triggered at all.
Note the following about why this was the case:
- The Declined status workflow ran first because the order that the workflows are triggered cannot be guaranteed. However, because the employee was set to New status for this HR event, the Declined workflow finished without sending a notification.
- When the New status workflow runs, the first condition node checks whether the New status occurred.
- Because this is true (the employee was assigned the New status), the HR event is consumed, and the system doesn't trigger the remaining workflow for the In Progress status.
Requirements for Assigning Workflows to the HR Event:
Important: The HR event triggers the workflows on the list until it finds a workflow with a condition that is true. Moreover, the order in which workflows that are assigned to the HR event are triggered cannot be guaranteed. Therefore, the workflows that you add to the HR event must meet the requirements listed below. Failure to meet these requirements could result in notifications not being sent.
- In all workflows, the start node should connect directly to the condition node that checks for candidate status. Don’t place another condition node (for example, the condition for internal candidates) before the condition node for candidate status, because this could cause workflows not to run.
- For example, a user adds two workflows to the HR event that start with a condition node for internal candidates. One workflow is for the "Declined" status and the other is for the "New" status. An internal candidate submits a job application, and the HR event happens to trigger the workflow for "Declined" status first. Because it finds the first condition to be true (that is, the candidate was internal), the HR event is consumed. As a result, the workflow for the "New" status (which would result in a notification being sent) isn’t triggered.
- You must only add one workflow per candidate status to the HR event. For example, a user adds separate workflows for when a candidate is manually and automatically declined. Both workflows start with a condition node that checks for the "Declined" status. A candidate is manually declined, but the HR event runs the workflow for the automatic decline first.
- The first condition in this workflow is found true, and the HR event is consumed. However, because this workflow is for automatic decline, it doesn't send a notification. Moreover, because the HR event was consumed, it doesn't trigger the workflow for the manual decline notification, which would have resulted in the correct notification. As a solution, you would combine automatic and manual decline notifications into a single workflow.