A Simple Guide to Business Process Reporting in Workday Recruiting

Metrics are critical to making informed decisions in Talent Acquisition. Time to fill, time to offer, time in certain steps of the process – you name it. Identifying bottlenecks to improve candidate experience and reduce lag time in hiring is crucial in today’s competitive market.
The goal of this guide is to provide a model for time-related analytics throughout the recruitment process. It can get quite complex with the large number of business objects throughout Workday Recruiting. The models presented below are not a replacement for standard fields like Close Date or Offer Date, but if those fields don’t provide enough context to particular metrics, this deeper dive into the business process timestamps is incredibly useful. A common example is wanting to know the timestamp when the candidate accepts their offer letter, which requires leveraging calculated fields.
Job Requisition
All business processes (BPs) related to job requisitions including Create, Edit, Close, Freeze, and Unfreeze can follow this calculated field (CF) model to return event-related information about them:
CF #1 – Job Requisition Event from Job Requisition | |
Calculated Field Function | Extract Single Instance (ESI) |
Business Object | Job Requisition |
Source Field | Job Requisition Event |
Condition | CF #2 (see below) |
Sort Field | Date and Time Initiated (as an example) |
Sort Direction | Descending |
Instance to be Returned | First occurrence |
The sorting will return the latest initiated instance.
CF #2 – Completed Job Requisition BP Type in the List | |
Calculated Field Function | True/False |
Business Object | Job Requisition Event |
First row | Business Process Type ‘in the selection list’ Close Job Requisition (as an example)* |
(and) Second row | Transaction Status ‘not in the selection list’ Rescinded, Canceled |
*Extra Tip: if using evergreen requisitions, add Close Evergreen Requisition to the first row of the True/False.
One more calculated field is needed to return the timestamp:
CF #3 – Date BP was Completed | |
Calculated Field Function | Lookup Related Value |
Business Object | Job Requisition |
Lookup Field | CF #1 |
Return Value | Date and Time Completed (as an example) |
In this example, CF #3 can now be used in a report to show the date and time the most recently initiated close job requisition business process was Completed.
Replicate these calculations as needed for other job requisition business processes using additional versions.
Job Application
The above framework can be used within the Job Application workflow as well. The following example demonstrates how to return when a job application was first moved to Recruiter Screen:
CF #1 – First Recruiter Screen Event | |
Calculated Field Function | Extract Single Instance (ESI) |
Business Object | Job Application Event |
Source Field | Job Application Sub Business Processes |
Condition | CF #2 (see below) |
Sort Field | Date and Time Initiated |
Sort Direction | Ascending |
Instance to be Returned | First occurrence |
The sorting will return the first initiated instance.
CF #2 – Job Application Step is Recruiter Screen | |
Calculated Field Function | True/False |
Business Object | Recruiting Event |
First row | Job Application Step ‘in the selection list’ Recruiter Screen** |
**This field can look at step label overrides in the Job Application business process.
CF #3 – Date Recruiter Screen Event was Initiated | |
Calculated Field Function | Lookup Related Value |
Business Object | Job Requisition Event |
Lookup Field | CF #1 |
Return Value | Date and Time Initiated |
To bring into Job Application data source reporting, create one more LRV:
CF #4 – Job Application Event for Job Application | |
Calculated Field Function | Lookup Related Value |
Business Object | Job Applications, Prospects and Referrals |
Lookup Field | Job Application Event |
Return Value | CF #3 |
You can pull many other useful fields into calculated fields depending on the required use case. A few examples are:
- Interview Events (on the Job Application business object) which could be used as a Source Field in an ESI
- Offer Event (on the Job Applications, Prospects and Referrals business object) which could be used as a Lookup Field in an LRV.
Job Application – Specific Step in a Sub-Process
Arriving at the granularity of specific business process steps’ initiation or completion dates during the job application workflow is the use case example mentioned in the introduction – acceptance of an offer letter. This would be the Date and Time Completed of the candidate’s Review Document step in the Offer business process.
CF #1 – Latest Job Application Event | |
Calculated Field Function | Extract Single Instance (ESI) |
Business Object | Job Application Event |
Source Field | Process History |
Condition | CF #2 (see below) |
Sort Field | Date and Time Initiated |
Sort Direction | Descending |
Instance to be Returned | First occurrence |
The sorting will return the most recently initiated instance.
CF #2 – <step from the BP> is Completed | |
Calculated Field Function | True/False |
Business Object | Event Record |
First row | Step ‘in the selection list’ step f – Review Documents* |
(and) Second row | Status ‘in the selection list’ Step Completed |
*This represents the exact step(s) in the Offer business process.
CF #3 – Date Completed for Latest <BP step> | |
Calculated Field Function | Lookup Related Value |
Business Object | Job Application Event |
Lookup Field | CF #1 |
Return Value | Date and Time Completed |
Follow CF #4 in the previous section to return this date in Job Application reports.
More Business Processes
Posting requisitions, updating primary recruiters, staffing events, and editing a custom object are more instances of business process reporting that could arise.
- For business process dates related to posting a job, leverage the field Job Posting Details (Job Requisition business object) as the Source Field in an ESI CF. Create an LRV CF for the Sort Field:
Business Object | Job Posting Details |
Lookup Field | Post Job Business Process |
Return Value | Date and Time Completed |
- For timestamps on the most recent Primary Recruiter role assignment change, create both an ESI and an LRV CF:
CF #1 – Latest Primary Recruiter Assignment | |
Calculated Field Function | ESI |
Business Object | Job Requisition |
Source Field | Role Assignments |
Condition | True/False CF: Role Name ‘in the selection list’ Primary Recruiter |
Sort Field | Last Functionally Updated |
Sort Direction | Descending |
Instance to be Returned | First occurrence |
CF #2 – Last Primary Recruiter Update | |
Calculated Field Function | LRV |
Business Object | Job Requisition |
Lookup Field | CF #1 |
Return Value | Last Functionally Updated |
- For job requisitions used to hire multiple workers, leveraging a field to pull the latest staffing process’ completed date could be insightful:
CF #1 – Job Requisition’s Latest Staffing Event | |
Calculated Field Function | ESI |
Business Object | Job Requisition |
Source Field | Inbound Staffing Process – Completed |
Condition | Any is True |
Sort Field | Date and Time Completed |
Sort Direction | Descending |
Instance to be Returned | First occurrence |
CF #2 – Job Requisition’s Last Staffing Event Completion Date | |
Calculated Field Function | LRV |
Business Object | Job Requisition |
Lookup Field | CF #1 |
Return Value | Date and Time Completed |
- Concluding with the simplest calculated field, create an LRV to determine the last time a custom object was edited:
Business Object | Job Requisition |
Lookup Field | Job Requisition Additional Data |
Return Value | Last Functionally Updated |
Some Final Reminders
- Always include appropriate labels in reports based on the ESI to emphasize it’s the “most recent” or “first” instance, especially since some business processes are initiated many times like Job Requisition Change and Interview.
- As with all things Workday, testing the accuracy of the calculated fields is very important, such as with a basic Advanced report or running an event’s Report Fields & Values report. Leveraging existing data for spot-checking of unique scenarios can be insightful.
- Any changes to business processes should prompt a review of these calculated fields to ensure there’s no impact on the analytics.
Hopefully, these practical examples will help you generate some ideas for complex analytics requests. Happy Recruitment Reporting!
Do you need more help with a specific or complex use case? Contact us and we’d love to walk through and solution some options.