> Continuous Process Improvement > Recruitment & Talent Acquisition > Workday Recruiting > Data Template

Your Recruitment & Talent Acquisition Data Template

Workday Recruiting

Recruitment & Talent Acquisition Attributes (20) Recruitment & Talent Acquisition Activities (15) Extraction Guides (3)

Your Recruitment & Talent Acquisition Data Template

This template provides a comprehensive guide to collecting the necessary data for analyzing your recruitment and talent acquisition processes. It outlines essential attributes to collect, key activities to track, and provides guidance on how to extract this data from your Workday Recruiting system. Use this resource to streamline your data preparation and accelerate your process mining journey.

Recommended attributes to collect
Key activities to track
Extraction guidance for Workday Recruiting

New to event logs? Learn how to create a process mining event log.

Download Template

Recruitment & Talent Acquisition Attributes

These are the recommended data fields to include in your event log for comprehensive recruitment and talent acquisition analysis, enabling deep insights into your hiring process.

3 Required 5 Recommended 12 Optional

	Name	Description
	Activity Name ActivityName	The name of the specific event or task that occurred at a point in time within the recruitment process.
Description The Activity Name describes a single step or milestone in the hiring journey, such as 'Application Screened', 'Interview Scheduled', or 'Offer Extended'. These activities form the sequence of events that constitute the process. This attribute is crucial for visualizing the process map, identifying the different paths applications take, and analyzing the frequency and order of events. It is the basis for understanding what is happening in the process. Why it matters This attribute defines the steps of the recruitment process, allowing for the visualization and analysis of the process flow. Where to get This is derived from business process step names or status changes within Workday Recruiting's job application data. Examples Application ScreenedInterview CompletedOffer AcceptedCandidate Rejected
	Event Time EventTime	The timestamp indicating when the activity or event occurred.
Description This attribute records the exact date and time that a specific recruitment activity took place. Timestamps are the backbone of process mining, providing the chronological order of events. In analysis, timestamps are used to calculate durations between activities, measure overall cycle times like 'Time to Hire', and identify bottlenecks where the process is delayed. They are essential for any time-based analysis of the recruitment funnel. Why it matters Timestamps are critical for calculating all time-based KPIs, understanding process duration, and discovering bottlenecks. Where to get This corresponds to the completion date or transaction date of a business process step in Workday Recruiting. Examples 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	Job Application JobApplicationId	The unique identifier for a candidate's job application, serving as the central case ID for the recruitment process.
Description The Job Application ID uniquely tracks a single candidate's journey for a specific job requisition from initial submission to the final decision. Each interaction, status change, or decision point related to this application is linked back to this identifier. In process mining, this attribute is fundamental. It allows for the reconstruction of each candidate's end-to-end process flow, enabling analysis of cycle times, bottlenecks, and paths taken. It is the core element that connects all related activities into a cohesive case. Why it matters This is the essential Case ID that connects all recruitment activities for a single candidate, making it possible to analyze the entire hiring journey. Where to get This identifier is a core element in Workday Recruiting, typically available in reports and data sources related to job applications. Examples APP-2023-001234APP-2023-005678APP-2024-009101
	Application Source ApplicationSource	The channel or source through which the candidate's application was received.
Description This attribute indicates how a candidate discovered and applied for the job, for example, through the company careers page, LinkedIn, an employee referral, or a recruiting agency. Understanding the source is vital for optimizing recruitment strategy and budget. It powers the 'Sourcing Channel Effectiveness' dashboard and the 'Offer Acceptance Rate by Source' KPI, helping to determine which channels produce the most and best-quality candidates. Why it matters Helps evaluate the effectiveness of different sourcing channels, enabling data-driven decisions on where to invest recruiting resources. Where to get Consult Workday Recruiting documentation. This is a standard field on the job application. Examples LinkedInEmployee ReferralCompany Careers SiteIndeed
	Application Status ApplicationStatus	The final outcome or current state of the job application.
Description This attribute records the final disposition of a job application, such as 'Hired', 'Rejected by Company', 'Offer Declined', or 'Withdrawn by Candidate'. It represents the terminal state of the process for a given application. This status is critical for outcome analysis. It is used to calculate conversion rates, offer acceptance rates, and candidate drop-off rates at various stages. Understanding why and where applications end is key to improving the overall process effectiveness. Why it matters Defines the outcome of each case, which is essential for calculating conversion rates, drop-off rates, and overall process success. Where to get This is typically the final disposition or status reason field on the Job Application object in Workday Recruiting. Examples HiredRejectedOffer DeclinedApplication Withdrawn
	Department Department	The department or business unit associated with the job requisition.
Description This attribute specifies the organizational unit, such as 'Engineering', 'Marketing', or 'Finance', for which the candidate is being hired. It is derived from the job requisition's associated supervisory organization. In analysis, filtering by department allows for comparison of hiring processes across different parts of the business. It is used in the 'Application Screening Efficiency' dashboard to see if certain departments have longer screening times, potentially indicating different practices or resource needs. Why it matters Enables comparison of recruitment process performance and efficiency across different business units or departments. Where to get Consult Workday Recruiting documentation. This is derived from the Supervisory Organization tied to the Job Requisition. Examples EngineeringSalesHuman ResourcesFinance
	Hiring Manager HiringManager	The name of the hiring manager for the position the candidate applied for.
Description This attribute identifies the manager of the team or department with the open position. The hiring manager is a key stakeholder in the decision-making process, especially during interviews and feedback stages. This data is essential for the 'Hiring Manager Feedback Timeliness' dashboard. By analyzing the time between 'Interview Completed' and 'Feedback Submitted' per hiring manager, organizations can pinpoint delays and work with specific managers to accelerate the hiring loop. Why it matters Crucial for analyzing hiring manager engagement and identifying delays in feedback submission, which directly impacts candidate experience. Where to get Consult Workday Recruiting documentation. This is typically part of the supervisory organization or job requisition details. Examples Susan AdamsDavid ChenAngela Rodriguez
	Recruiter Name RecruiterName	The name of the recruiter responsible for managing the job application.
Description This attribute identifies the primary talent acquisition partner or recruiter assigned to the job application and requisition. They are typically responsible for guiding the candidate through the process. Analyzing the process by recruiter is key to understanding team performance and workload. It helps build the 'Recruiter Performance And Throughput' dashboard and calculate KPIs like 'Recruiter Time-to-Offer Variance', enabling comparisons of efficiency and identification of best practices. Why it matters Allows for performance analysis by recruiter, helping to identify high-performers, training needs, and workload imbalances. Where to get Consult Workday Recruiting documentation. This is typically linked to the Job Requisition or Job Application objects. Examples John SmithEmily JonesMaria Garcia
	Candidate ID CandidateId	The unique identifier for the candidate.
Description The Candidate ID uniquely identifies an individual in the recruiting system, regardless of how many jobs they have applied for. This allows for tracking a candidate's history with the company across multiple applications. This attribute is useful for analyzing the candidate experience over time. For example, it can help identify if previously rejected candidates are reapplying and how their journeys differ, or if a single candidate is being considered for multiple roles simultaneously. Why it matters Allows for a candidate-centric view of the process, tracking an individual across multiple applications and over time. Where to get This is the primary identifier for the Candidate object in Workday Recruiting. Examples CAND-98765CAND-11223CAND-54321
	Candidate Type CandidateType	Indicates if the candidate is an internal employee or an external applicant.
Description This attribute categorizes candidates into groups such as 'Internal' or 'External'. The hiring process, timelines, and policies can differ significantly between these two types. Analyzing the process separately for internal and external candidates is crucial for a complete view. It allows the organization to measure the efficiency of its internal mobility programs versus external hiring efforts and ensure both processes are optimized. Why it matters Allows for separate analysis of internal and external hiring processes, which often have different steps, SLAs, and goals. Where to get Consult Workday Recruiting documentation. This is a standard field on the candidate profile or job application. Examples InternalExternal
	Is Automated IsAutomated	A flag indicating if the activity was performed automatically by the system.
Description This boolean attribute identifies whether a step was executed by a user or by an automated system process. For example, an initial 'Application Received' confirmation email might be an automated activity. Understanding which steps are automated is important for identifying opportunities to increase efficiency. It helps in evaluating the impact of automation on cycle times and resource allocation. Why it matters Distinguishes between manual and system-driven activities, which is key for identifying automation opportunities and measuring their impact. Where to get This information needs to be derived by identifying system-user accounts or specific event types known to be automated in Workday. Examples truefalse
	Is Withdrawn IsWithdrawn	A flag that indicates if the application was withdrawn by the candidate.
Description This is a calculated boolean attribute that is true if the application's final status is 'Withdrawn by Candidate' or a similar state. It helps to isolate cases where the candidate dropped out of the process. This flag simplifies the analysis for the 'Candidate Drop-Off Hotspots' dashboard and the 'Candidate Drop-off Rate' KPI. It allows for easy filtering and aggregation to understand at which stages candidates are most likely to withdraw. Why it matters Helps to specifically analyze candidate-driven drop-offs, providing insights into candidate experience and process friction points. Where to get This is calculated based on the 'ApplicationStatus' attribute during data transformation. Examples truefalse
	Job Location JobLocation	The geographical location or country of the job.
Description This attribute specifies the city, state, or country where the job position is based. For remote positions, it might indicate a region or be marked as 'Remote'. Location is a powerful dimension for analysis. It allows for comparing 'Time to Hire' and other KPIs across different regions, which can reveal variations due to local market conditions, talent availability, or regional process differences. Why it matters Enables geographical analysis of the recruitment process, highlighting regional differences in cycle times and efficiency. Where to get This information is part of the Job Requisition details in Workday. Examples New York, NYLondon, UKRemote (US)Berlin, Germany
	Job Requisition ID JobRequisitionId	The unique identifier for the job opening for which the candidate has applied.
Description The Job Requisition ID is the identifier for the approved job opening. A single requisition can have many applications associated with it. This attribute allows for analysis at the requisition level. For instance, one can analyze the total time a requisition was open, the number of candidates sourced, or compare the recruitment funnels for different types of jobs (e.g., engineering vs. sales requisitions). Why it matters Links multiple applications to a single job opening, enabling analysis of requisition-level metrics and hiring funnels. Where to get This is a primary identifier on the Job Requisition object in Workday Recruiting and is linked to every job application. Examples REQ-2023-105REQ-2024-012REQ-2024-345
	Last Data Update LastDataUpdate	The timestamp when the data was last refreshed or extracted from the source system.
Description This attribute indicates the freshness of the data being analyzed. It shows the date and time of the last data pull from Workday Recruiting. This is important for users to understand how current the analysis is. It helps them interpret the findings correctly, knowing whether they are looking at real-time data or a snapshot from a specific point in time. Why it matters Provides context on data freshness, ensuring users understand how up-to-date the process analysis is. Where to get This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process. Examples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	Offer Amount OfferAmount	The salary amount offered to the candidate.
Description This attribute contains the value of the base salary proposed to a candidate in the job offer. It is a critical piece of data in the final stages of the recruitment process. Analyzing offer amounts can provide insights into compensation trends and competitiveness. When combined with 'Offer Accepted' status, it can help determine if compensation is a factor in offer declines. It is a key element for the 'Offer Management And Acceptance Rates' dashboard. Why it matters Helps in analyzing compensation strategy and its impact on offer acceptance rates. Where to get Consult Workday Recruiting documentation. This would be part of the 'Offer' business process data. Examples 8500012000065000
	Processing Time ProcessingTime	The duration of time spent actively working on an activity.
Description Processing Time, also known as active time, measures the duration a resource spends working on a specific task. This is different from cycle time, which includes wait time. For instance, it would be the time a recruiter spends actively screening an application. This metric is valuable for understanding resource efficiency and workload. If available, it helps to pinpoint which specific activities are the most time-consuming in terms of actual effort, not just elapsed time. Why it matters Measures the actual work effort for an activity, helping to distinguish active work time from idle wait time for better resource planning. Where to get This is often not directly available and needs to be calculated or estimated. For example, it could be the time between a 'Screening Started' and 'Screening Completed' event if such granularity exists. Examples 360018007200
	Rejection Reason RejectionReason	The reason provided when a candidate's application is rejected.
Description When an application is moved to a 'Rejected' status, this attribute provides context for the decision. Reasons might include 'Not a culture fit', 'Lacks required skills', or 'Position filled by another candidate'. Analyzing rejection reasons helps identify patterns in the hiring process. For instance, a high number of rejections for 'Lacks required skills' at a late stage may indicate a poorly written job description. This data is key for the 'Candidate Drop-Off Hotspots' dashboard to understand the 'why' behind the drop-offs. Why it matters Provides qualitative insight into why candidates are not progressing, helping to improve job descriptions and screening criteria. Where to get Consult Workday Recruiting documentation. This is often a sub-status or reason code associated with the rejection step. Examples Not qualifiedExperience mismatchBetter candidates identifiedPosition closed
	Source System SourceSystem	The system from which the data was extracted.
Description This attribute identifies the origin of the data, which in this case is Workday Recruiting. It helps in data governance and troubleshooting, especially when data from multiple systems is combined. While it may seem trivial in a single-system analysis, it is a best practice to always include it. It confirms the data's provenance and becomes critical if other HR systems are integrated later. Why it matters Identifies the data's origin, which is crucial for data governance, validation, and managing data from multiple sources. Where to get This is a static value ('Workday Recruiting') added during the data extraction and transformation process. Examples Workday Recruiting
	Time To Hire TimeToHire	The total time from when an application is received to when the candidate is hired.
Description This is a case-level calculation that measures the total duration of the recruitment process for successful candidates. It is calculated as the time difference between the 'Application Received' event and the 'Candidate Hired' event. This is one of the most important KPIs in recruitment ('Average Time to Hire'). It provides a high-level measure of the overall efficiency of the hiring process. Tracking this metric over time and across departments helps to identify systemic improvements or regressions. Why it matters A critical, high-level KPI that measures the overall efficiency of the recruitment funnel from start to finish. Where to get This is calculated from the event log data after it has been extracted from Workday. Examples 259200043200003456000

Required Recommended Optional

Recruitment & Talent Acquisition Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and identifying bottlenecks in your hiring workflow.

7 Recommended 8 Optional

	Activity	Description
	Application Received	Marks the start of the recruitment process for a candidate's job application. This event is captured when a candidate successfully submits their application for a specific job requisition through the Workday portal or an integrated career site.
Why it matters This is the primary start event for the process. Analyzing the time from this activity to subsequent milestones is fundamental for measuring overall Time to Hire and sourcing channel effectiveness. Where to get Workday logs this as an explicit event when the 'Apply for Job' business process completes successfully for a candidate. The event timestamp is available in the candidate's application history. Capture Captured from the application submission timestamp in the candidate's profile. Event type explicit
	Candidate Hired	The successful conclusion of the recruitment process, where the candidate is formally hired as an employee. This is captured when the 'Hire' business process is successfully completed in Workday, creating an employee record.
Why it matters This is the primary success end event. The timestamp is essential for calculating Time to Hire and measuring overall process efficiency and success rates. Where to get This is a major, explicit event logged by the 'Hire' business process in Workday HCM. The completion timestamp is recorded in the process history. Capture Captured from the completion timestamp of the 'Hire' business process for the candidate. Event type explicit
	Candidate Moved To Interview	Indicates that a candidate has passed the initial screening and is now eligible for an interview. This event is captured when a recruiter moves the candidate to the 'Interview' stage in the hiring process.
Why it matters This milestone marks the transition from screening to active evaluation. It is a key point for analyzing conversion rates and the efficiency of the top of the recruitment funnel. Where to get Inferred from the timestamp when the candidate's recruiting stage is changed to 'Interview' or a similar designation within the job application's history. Capture Identified by the status change to an 'Interview' stage in the candidate's progression. Event type inferred
	Candidate Moved To Offer Stage	A key milestone indicating the decision has been made to extend a job offer to the candidate. This is captured when the candidate's application is advanced to the 'Offer' stage in the recruitment process.
Why it matters This activity is a critical gate in the process, marking the successful completion of all evaluation stages. It's a precursor to the formal offer and a key point for cohort analysis. Where to get Inferred from the audit trail of the job application, specifically the timestamp when the candidate's status changes to 'Offer'. Capture Identified by the status change to an 'Offer' stage in the candidate's progression. Event type inferred
	Candidate Rejected	Marks an unsuccessful end to the process where the company decides not to move forward with a candidate. This is inferred when a recruiter moves the candidate to a 'Rejected' or 'Not Hired' disposition status.
Why it matters This is a critical end event for analyzing candidate drop-off hotspots and rejection rates at different stages. It helps identify issues in the interview or screening process. Where to get Inferred from the timestamp when the candidate's disposition is changed to 'Rejected' in the job application history. A reason for rejection is often also recorded. Capture Derived from the effective timestamp of the move to a 'Rejected' disposition. Event type inferred
	Offer Accepted	Represents the candidate's formal acceptance of the job offer. This event is captured when the candidate completes the 'Accept Offer' task in their Workday portal, or when a recruiter manually updates the status.
Why it matters This activity is crucial for calculating offer acceptance rates by source, department, or recruiter. It also triggers subsequent pre-hire activities like background checks. Where to get Explicitly logged when a candidate accepts the offer via their candidate portal. The action is recorded with a timestamp in the job application's business process history. Capture Captured from the completion timestamp of the 'Accept Offer' task. Event type explicit
	Offer Extended	Marks the formal extension of a job offer to a candidate. This is a discrete event captured when the 'Create Offer' or 'Propose Compensation' business process is successfully completed for the job application in Workday.
Why it matters This is a major milestone used to calculate Time to Offer and analyze offer process conformance. It is the starting point for measuring offer acceptance rates. Where to get This event is explicitly logged in the business process history for the job application. The completion timestamp of the offer creation step provides the activity time. Capture Captured from the completion timestamp of the 'Create Offer' business process. Event type explicit
	Application Screened	Represents the completion of the initial review of a candidate's application by a recruiter or screening team. This is typically inferred when the candidate is moved from an 'Applied' or 'New' status to a 'Screening' or 'Under Review' stage.
Why it matters This activity is crucial for analyzing the efficiency of the initial screening phase. Tracking its throughput and duration helps identify bottlenecks early in the recruitment funnel. Where to get Inferred from the effective date of the candidate's stage change to a screening or review step in the 'Recruiting' business process audit trail. Capture Derived from the timestamp when the candidate's stage is updated to 'Screen'. Event type inferred
	Application Withdrawn	An end event where the candidate voluntarily removes themselves from consideration for the role. This is captured when the candidate's status is updated to 'Withdrawn' either by themselves or by a recruiter.
Why it matters Tracking when and why candidates withdraw is crucial for understanding candidate experience issues, process length, or offer competitiveness. It is a key metric for drop-off analysis. Where to get Inferred from the timestamp when the candidate's disposition is updated to 'Withdrawn'. This can be done by the candidate in their portal or by a recruiter. Capture Derived from the effective timestamp of the move to a 'Withdrawn' disposition. Event type inferred
	Background Check Cleared	Marks the successful completion of the background check process. This event is inferred when the candidate's status is updated to reflect that they have passed the necessary checks, clearing them for hire.
Why it matters This is the final checkpoint before the hiring process can be finalized. Delays in receiving and logging this clearance can hold up a candidate's start date. Where to get Inferred from a status update on the candidate's application, such as moving to a 'Ready for Hire' or 'Background Check Complete' stage. Capture Derived from the status change indicating a completed and passed background check. Event type inferred
	Background Check Initiated	Indicates the start of the background check process for a candidate who has accepted an offer. This is usually inferred from the candidate moving to a 'Background Check' stage, which often triggers an integration with a third-party vendor.
Why it matters This activity is vital for monitoring compliance and analyzing delays between offer acceptance and the start of pre-hire checks. It helps ensure a smooth transition to onboarding. Where to get Inferred from the timestamp of the candidate moving into the 'Background Check' stage in their recruitment process flow. The audit trail for the job application will show this status change. Capture Derived from the effective timestamp of the move to the 'Background Check' stage. Event type inferred
	Feedback Submitted	Represents the point when an interviewer formally submits their evaluation of a candidate post-interview. Workday provides a specific mechanism for interviewers to provide feedback directly on the candidate's profile.
Why it matters This is essential for the 'Hiring Manager Feedback Timeliness' analysis. Delays here are a common bottleneck, and tracking this helps enforce service level agreements. Where to get This is an explicit event captured when feedback is submitted through the 'Provide Interview Feedback' task. The timestamp of submission is logged against the interview record. Capture Extracted from the completion timestamp of the 'Provide Interview Feedback' event. Event type explicit
	Interview Completed	Marks the completion of a scheduled interview with a candidate. This is generally inferred when an interviewer or recruiter updates the status of the interview from 'Scheduled' to 'Completed' or 'Conducted'.
Why it matters This activity serves as the trigger for the feedback submission window. Analyzing the time from this point to feedback submission is key for measuring hiring manager responsiveness. Where to get Inferred from a status update on the scheduled interview object or a manual stage change for the candidate in Workday Recruiting after the interview has taken place. Capture Derived from the timestamp of the interview status update or candidate stage change post-interview. Event type inferred
	Interview Scheduled	Represents the formal scheduling of an interview with the candidate. This is typically captured when an interview event is created and confirmed within Workday's scheduling functionality for the specific job application.
Why it matters Measuring the time between this and previous activities helps identify delays in coordination. This is critical for improving candidate experience and accelerating the interview process. Where to get Workday's interview scheduling feature creates events with timestamps. This activity can be captured from the creation date of the scheduled interview linked to the application. Capture Captured from the creation event of an interview record in the recruiting module. Event type explicit
	Onboarding Initiated	Represents the kickoff of the new hire onboarding process within Workday. This is typically an explicit event that is part of the main 'Hire' business process or triggered immediately after.
Why it matters Analyzing the time from 'Offer Accepted' to this activity helps streamline the post-offer candidate experience. It ensures new hires are engaged and prepared for their first day. Where to get Workday's 'Onboarding' business process has a clear initiation timestamp. This can be captured from the process audit trail for the new employee record. Capture Captured from the initiation timestamp of the 'Onboarding' business process. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from Workday Recruiting

Steps

Log into Workday: Access your Workday tenant with a user account that has permissions for creating custom reports and accessing recruiting data.
Create a Custom Report: Navigate to the 'Create Custom Report' task. Select 'Advanced' as the Report Type and enable the 'Enable as Web Service' option. For the Data Source, use an indexed source like 'All Job Applications' for better performance.
Define the Primary Business Object: Set the Primary Business Object to 'Job Application'. This object will serve as the basis for the report and the case identifier.
Add Data Columns: Add the required and recommended fields to the report's column grid. Add 'Job Application' for the JobApplicationId. For other attributes like 'Recruiter' and 'Hiring Manager', you will need to add them from the related business objects linked to the Job Application.
Create Calculated Fields for Activities: This is the most critical step. For each of the 15 activities, you will create two calculated fields: one for the Activity Name and one for the Event Timestamp. The logic for these fields is detailed in the Query section. For example, to capture 'Offer Extended', you will create a field that checks for the completion of the 'Propose Compensation' business process and another field to extract the completion timestamp of that process.
Add Calculated Fields to the Report: Add all the newly created calculated fields (30 in total, 15 for activity names and 15 for timestamps) as columns in your report. The report will be in a 'wide' format, with one row per job application and many columns representing the potential activities.
Configure Web Service Options: In the 'Web Service' tab of the report definition, ensure the 'Enable as Web Service' checkbox is selected. You can view the report's namespace and URL here. Note the 'Namespace' for later use.
Set Permissions: Share the report with an Integration System User (ISU) or a specific security group that will be used to call the RaaS endpoint. This user must have permissions to the data source's domain, for example, 'Recruiting: Job Applications'.
Run and Test the Report: Run the report from the Workday UI to verify the output. Check for a reasonable number of rows and ensure the calculated fields are populating correctly for a few sample applications.
Schedule the Extraction: Use an external scheduling tool or middleware (like MuleSoft, Boomi, or a custom script) to call the report's RaaS URL on a regular basis. The tool will need to handle the Workday SOAP or REST API call with proper authentication.
Transform the Data: The raw output from the RaaS call will be a wide XML or CSV file. You must implement a transformation step in your middleware or a scripting language (like Python) to unpivot this data. The script should iterate through each row (job application) and create a new row in the final event log for every non-empty activity/timestamp pair, resulting in a 'long' format with three main columns: JobApplicationId, ActivityName, and EventTime.

Configuration

Report Type: Always use 'Advanced' to allow for complex calculated fields and access to related business objects.
Data Source: Use an indexed data source like 'All Job Applications' to ensure the report runs efficiently. Avoid un-indexed sources for large datasets.
Date Range Filtering: It is critical to apply a filter on the 'Application Date' field of the Job Application business object. Start with a smaller range, such as the last 3 to 6 months, to manage the data volume and report performance.
Primary Business Object: The primary object must be 'Job Application' to ensure the JobApplicationId serves as the case identifier.
Web Service Enablement: You must check the 'Enable as Web Service' option in the report configuration to make it accessible via APIs.
Security and Permissions: The report must be shared with a dedicated Integration System User (ISU). This ISU must have security group permissions to access the required data domains, including 'Recruiting: Job Applications', 'Business Process Transactions', and 'Worker Data'.
Output Format: While Workday offers several output formats (XML, CSV, JSON), XML (specifically the 'Simple XML' format) is often the most reliable for structured data extraction via the API.

a Sample Query config

The Workday Report Writer is configured through the user interface. The following describes the structure and calculated fields required to build the report. The final output will be a wide table that must be transformed into an event log.

**Primary Business Object:**
*   `Job Application`

**Direct Report Fields (Columns):**
| Field Name in Report | Workday Business Object | Workday Field | Notes |
| --- | --- | --- | --- |
| `JobApplicationId` | Job Application | Job Application | Serves as the Case ID. |
| `RecruiterName` | Job Application -> Recruiter | Worker | Use a Lookup Related Value field. |
| `HiringManager` | Job Application -> Job Requisition -> Hiring Manager | Worker | Use a Lookup Related Value field. |
| `ApplicationSource` | Job Application | Source | |
| `Department` | Job Application -> Job Requisition -> Organization | Supervisory Organization | |
| `ApplicationStatus` | Job Application | Status | Represents the final or current status. |

**Calculated Fields for Event Log Unpivoting:**
Create two calculated fields for each activity: one for the name (Type: Evaluate Expression) and one for the timestamp (Type: Extract Single Instance or Lookup Related Value).

1.  **Application Received**
    *   `ActivityName_AppReceived`: `"Application Received"` (This event uses the application date, so the name is constant).
    *   `EventTime_AppReceived`: Field `Application Date` from the Job Application object.
2.  **Application Screened**
    *   `ActivityName_AppScreened`: `IIF(Stage = [Your 'Screening' Stage], "Application Screened", "")`
    *   `EventTime_AppScreened`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the 'Business Process History for Worker' for the 'Move to Stage: [Screening]' event.
3.  **Candidate Moved To Interview**
    *   `ActivityName_MovedToInterview`: `IIF(Stage = [Your 'Interview' Stage], "Candidate Moved To Interview", "")`
    *   `EventTime_MovedToInterview`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Move to Stage: [Interview]' event.
4.  **Interview Scheduled**
    *   `ActivityName_InterviewScheduled`: `IIF(Interview Status = 'Scheduled', "Interview Scheduled", "")`
    *   `EventTime_InterviewScheduled`: Use a 'Lookup Related Value' field to get the 'Scheduled Start Moment' from the 'Candidate Interview Details' object.
5.  **Interview Completed**
    *   `ActivityName_InterviewCompleted`: `IIF(Interview Status = 'Completed', "Interview Completed", "")`
    *   `EventTime_InterviewCompleted`: Use a 'Lookup Related Value' field to get the 'Actual End Moment' from the 'Candidate Interview Details' object.
6.  **Feedback Submitted**
    *   `ActivityName_FeedbackSubmitted`: `IIF(Interview Feedback Status = 'Submitted', "Feedback Submitted", "")`
    *   `EventTime_FeedbackSubmitted`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Submit Interview Feedback' event.
7.  **Candidate Moved To Offer Stage**
    *   `ActivityName_MovedToOffer`: `IIF(Stage = [Your 'Offer' Stage], "Candidate Moved To Offer Stage", "")`
    *   `EventTime_MovedToOffer`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Move to Stage: [Offer]' event.
8.  **Offer Extended**
    *   `ActivityName_OfferExtended`: `IIF(Is Business Process 'Propose Compensation' Completed = true, "Offer Extended", "")`
    *   `EventTime_OfferExtended`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Propose Compensation' or 'Make Offer' business process.
9.  **Offer Accepted**
    *   `ActivityName_OfferAccepted`: `IIF(Disposition = 'Offer Accepted', "Offer Accepted", "")`
    *   `EventTime_OfferAccepted`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Accept Offer' event.
10. **Background Check Initiated**
    *   `ActivityName_BGCheckInitiated`: `IIF(Stage = [Your 'Background Check' Stage], "Background Check Initiated", "")`
    *   `EventTime_BGCheckInitiated`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Move to Stage: [Background Check]' event.
11. **Background Check Cleared**
    *   `ActivityName_BGCheckCleared`: `IIF(Background Check Status = 'Passed', "Background Check Cleared", "")`
    *   `EventTime_BGCheckCleared`: Use a 'Lookup Related Value' field on the Background Check business object to get the completion date.
12. **Onboarding Initiated**
    *   `ActivityName_OnboardingInitiated`: `IIF(Is Business Process 'Onboarding' Initiated = true, "Onboarding Initiated", "")`
    *   `EventTime_OnboardingInitiated`: Use an 'Extract Single Instance' field to get the 'Entry Moment' from the business process history for the 'Onboarding' business process.
13. **Candidate Hired**
    *   `ActivityName_Hired`: `IIF(Is Hired = true, "Candidate Hired", "")`
    *   `EventTime_Hired`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Hire' business process.
14. **Candidate Rejected**
    *   `ActivityName_Rejected`: `IIF(Is Inactive = true AND Disposition = [Your 'Rejected' Reason], "Candidate Rejected", "")`
    *   `EventTime_Rejected`: Use a 'Lookup Related Value' field to get the 'Inactive Date' from the Job Application object.
15. **Application Withdrawn**
    *   `ActivityName_Withdrawn`: `IIF(Disposition = 'Withdrawn', "Application Withdrawn", "")`
    *   `EventTime_Withdrawn`: Use a 'Lookup Related Value' field to get the 'Inactive Date' from the Job Application object, filtering on the inactive reason.

Steps

Configure Workday Access: Create an Integration System User (ISU) in Workday. Grant this user access to the necessary security domains for the Recruiting API. Key domains include 'Worker Data: Public Worker Reports', 'Job Application', and 'Recruiting: Reports'.
Identify API Endpoint: Locate the REST API endpoint for the 'Get Job Applications' operation in your Workday tenant. The URL typically follows the format: https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications.
Set Up Python Environment: Ensure you have Python installed. Install the necessary libraries using pip: pip install requests pandas.
Develop Authentication Script: In your Python script, implement basic authentication using the credentials of the ISU created in step 1. The username and password will be sent in the request header.
Implement API Request Logic: Write the function to call the 'Get Job Applications' endpoint. Use request parameters to filter the data, such as updatedSince to fetch applications modified after a certain date. This is critical for managing data volume.
Handle API Pagination: The Workday API returns a limited number of records per request. Your script must check the response for a total count and a next page link or offset parameter, and loop through all pages to retrieve the complete dataset.
Define Activity Mapping: Create a mapping dictionary or a series of conditional statements in your script. This logic will translate Workday's business process statuses and recruiting stages (e.g., 'Screen', 'Interview', 'Offer', 'Hire') into the required activity names (e.g., 'Application Screened', 'Candidate Moved To Interview').
Transform Application Data: For each job application retrieved from the API, parse its audit trail or stage history data. This history contains the sequence of stages, dispositions, and business process events with their corresponding timestamps.
Generate Event Log Rows: Iterate through the history of each application. For each relevant historical event that matches your activity mapping, create a dictionary representing a row in the final event log. Populate the JobApplicationId, ActivityName, EventTime, and other required attributes.
Aggregate and Structure Data: Collect all the generated event log rows from all applications into a single list.
Create and Export CSV File: Use the pandas library to convert the list of event dictionaries into a DataFrame. Then, export the DataFrame to a CSV file. Ensure the column headers match the requirements for ProcessMind (e.g., CaseId, Activity, Timestamp).
Review and Upload: Open the final CSV file to review its contents for correctness and completeness before uploading it to the process mining tool.

Configuration

Workday Integration System User (ISU): An ISU with a strong, non-expiring password is required. It needs permissions to the 'Recruiting' and 'Worker Data' security domains to access job application and candidate details.
API Endpoint and Version: You must use the correct REST API endpoint for your Workday tenant. It is important to specify the API version in the request to ensure consistent behavior.
Date Range Filter: The script should use a date filter (e.g., updatedSince) to limit the query to a manageable timeframe. For initial extractions, a period of 3-6 months is recommended. For subsequent delta loads, use the timestamp of the last successful extraction.
Pagination Limit: Be aware of the limit parameter in the API, which controls how many records are returned per page. A typical maximum is 100. The script must be designed to handle this by making multiple paged requests.
Response Fields: To improve performance, you can specify which fields to return using a fields or similar parameter if the API supports it. This reduces the size of the API response payload.
Activity Mapping Configuration: The core logic of the script is the mapping from Workday stages to the defined activities. This may need to be customized based on your organization's specific Workday Recruiting process configuration.

a Sample Query python

import requests
import pandas as pd
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Workday tenant-specific details
WORKDAY_TENANT_HOST = class="hl-string">"https://[your_tenant_host].workday.com"
WORKDAY_TENANT_NAME = class="hl-string">"[your_tenant_name]"
WORKDAY_API_USER = os.environ.get(class="hl-string">"WORKDAY_USER", class="hl-string">"[Your_ISU_Username]")
WORKDAY_API_PASSWORD = os.environ.get(class="hl-string">"WORKDAY_PASSWORD", class="hl-string">"[Your_ISU_Password]")

class=class="hl-string">"hl-comment"># Date range for the extraction (ISO 8601 format)
class=class="hl-string">"hl-comment"># For delta loads, this should be the timestamp of the last successful run.
UPDATED_SINCE_DATE = class="hl-string">"2023-01-01T00:00:00Z"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_workday_job_applications():
    class="hl-string">"""Fetches all job applications from Workday API, handling pagination."""
    all_applications = []
    offset = 0
    limit = 100  class=class="hl-string">"hl-comment"># Workday's typical page size

    api_url = fclass="hl-string">"{WORKDAY_TENANT_HOST}/ccx/api/v1/{WORKDAY_TENANT_NAME}/recruiting/jobApplications"
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    auth = (WORKDAY_API_USER, WORKDAY_API_PASSWORD)

    while True:
        params = {
            class="hl-string">"updatedSince": UPDATED_SINCE_DATE,
            class="hl-string">"limit": limit,
            class="hl-string">"offset": offset
        }
        print(fclass="hl-string">"Fetching applications with offset: {offset}...")
        try:
            response = requests.get(api_url, headers=headers, params=params, auth=auth, timeout=60)
            response.raise_for_status()  class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            applications = data.get(class="hl-string">"data", [])
            all_applications.extend(applications)

            total = data.get(class="hl-string">"total", 0)
            if not applications or (offset + len(applications)) >= total:
                break  class=class="hl-string">"hl-comment"># Exit loop if no more data or all data fetched
            
            offset += len(applications)

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Workday API: {e}")
            break

    print(fclass="hl-string">"Total applications fetched: {len(all_applications)}")
    return all_applications

def transform_application_to_events(application):
    class="hl-string">"""Transforms a single job application's history into a list of event log rows."""
    events = []
    app_id = application.get(class="hl-string">"id")
    if not app_id:
        return []

    class=class="hl-string">"hl-comment"># Recommended Attributes
    recruiter = application.get(class="hl-string">"recruiter", {})
    hiring_manager_obj = application.get(class="hl-string">"job", {}).get(class="hl-string">"hiringManager", {})
    source = application.get(class="hl-string">"source", {})
    department_obj = application.get(class="hl-string">"job", {}).get(class="hl-string">"supervisoryOrganization", {})

    recruiter_name = recruiter.get(class="hl-string">"descriptor")
    hiring_manager_name = hiring_manager_obj.get(class="hl-string">"descriptor")
    app_source = source.get(class="hl-string">"descriptor")
    department = department_obj.get(class="hl-string">"descriptor")
    app_status = application.get(class="hl-string">"status", {}).get(class="hl-string">"descriptor")

    base_event = {
        class="hl-string">"JobApplicationId": app_id,
        class="hl-string">"RecruiterName": recruiter_name,
        class="hl-string">"HiringManager": hiring_manager_name,
        class="hl-string">"ApplicationSource": app_source,
        class="hl-string">"Department": department,
        class="hl-string">"ApplicationStatus": app_status
    }

    class=class="hl-string">"hl-comment"># --- Activity Extraction from Stage and Business Process History ---
    class=class="hl-string">"hl-comment"># This part assumes a structure for audit/history data. It needs to be adapted
    class=class="hl-string">"hl-comment"># to your specific Workday API response structure.
    stage_history = application.get(class="hl-string">"stageHistory", [])
    bp_history = application.get(class="hl-string">"businessProcessHistory", [])

    class=class="hl-string">"hl-comment"># Activity: Application Received
    events.append({
        **base_event,
        class="hl-string">"ActivityName": class="hl-string">"Application Received",
        class="hl-string">"EventTime": application.get(class="hl-string">"appliedOn")
    })

    for stage_change in stage_history:
        stage_name = stage_change.get(class="hl-string">"stage", {}).get(class="hl-string">"descriptor", class="hl-string">"").lower()
        disposition = stage_change.get(class="hl-string">"disposition", {}).get(class="hl-string">"descriptor", class="hl-string">"").lower()
        event_time = stage_change.get(class="hl-string">"enteredOn")

        class=class="hl-string">"hl-comment"># Activity: Application Screened (Inferred from entering a review stage)
        if class="hl-string">'screen' in stage_name or class="hl-string">'review' in stage_name:
            events.append({class="hl-string">"ActivityName": class="hl-string">"Application Screened", class="hl-string">"EventTime": event_time, **base_event})

        class=class="hl-string">"hl-comment"># Activity: Candidate Moved To Interview
        if class="hl-string">'interview' in stage_name:
            events.append({class="hl-string">"ActivityName": class="hl-string">"Candidate Moved To Interview", class="hl-string">"EventTime": event_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Candidate Moved To Offer Stage
        if class="hl-string">'offer' in stage_name:
            events.append({class="hl-string">"ActivityName": class="hl-string">"Candidate Moved To Offer Stage", class="hl-string">"EventTime": event_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Background Check Initiated
        if class="hl-string">'background check' in stage_name:
            events.append({class="hl-string">"ActivityName": class="hl-string">"Background Check Initiated", class="hl-string">"EventTime": event_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Onboarding Initiated
        if class="hl-string">'onboarding' in stage_name or class="hl-string">'ready for hire' in stage_name:
            events.append({class="hl-string">"ActivityName": class="hl-string">"Onboarding Initiated", class="hl-string">"EventTime": event_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Candidate Rejected
        if class="hl-string">'rejected' in disposition or class="hl-string">'not selected' in disposition:
             events.append({class="hl-string">"ActivityName": class="hl-string">"Candidate Rejected", class="hl-string">"EventTime": event_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Application Withdrawn
        if class="hl-string">'withdrawn' in disposition:
             events.append({class="hl-string">"ActivityName": class="hl-string">"Application Withdrawn", class="hl-string">"EventTime": event_time, **base_event})

    class=class="hl-string">"hl-comment"># Extract events from explicit business processes
    for bp_event in bp_history:
        bp_name = bp_event.get(class="hl-string">"process", {}).get(class="hl-string">"descriptor", class="hl-string">"").lower()
        bp_status = bp_event.get(class="hl-string">"status", class="hl-string">"").lower()
        bp_time = bp_event.get(class="hl-string">"completedOn") or bp_event.get(class="hl-string">"initiatedOn")

        class=class="hl-string">"hl-comment"># Activity: Interview Scheduled / Completed
        if class="hl-string">'interview' in bp_name:
            if bp_status == class="hl-string">'initiated':
                events.append({class="hl-string">"ActivityName": class="hl-string">"Interview Scheduled", class="hl-string">"EventTime": bp_time, **base_event})
            elif bp_status == class="hl-string">'completed':
                events.append({class="hl-string">"ActivityName": class="hl-string">"Interview Completed", class="hl-string">"EventTime": bp_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Feedback Submitted
        if class="hl-string">'provide interview feedback' in bp_name and bp_status == class="hl-string">'completed':
            events.append({class="hl-string">"ActivityName": class="hl-string">"Feedback Submitted", class="hl-string">"EventTime": bp_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Offer Extended
        if (class="hl-string">'job offer' in bp_name or class="hl-string">'propose compensation' in bp_name) and bp_status == class="hl-string">'completed':
            events.append({class="hl-string">"ActivityName": class="hl-string">"Offer Extended", class="hl-string">"EventTime": bp_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Offer Accepted
        if class="hl-string">'accept offer' in bp_name and bp_status == class="hl-string">'completed':
            events.append({class="hl-string">"ActivityName": class="hl-string">"Offer Accepted", class="hl-string">"EventTime": bp_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Background Check Cleared
        if class="hl-string">'background check' in bp_name and bp_status == class="hl-string">'completed':
            events.append({class="hl-string">"ActivityName": class="hl-string">"Background Check Cleared", class="hl-string">"EventTime": bp_time, **base_event})
        
        class=class="hl-string">"hl-comment"># Activity: Candidate Hired
        if class="hl-string">'hire' in bp_name and bp_status == class="hl-string">'completed':
            events.append({class="hl-string">"ActivityName": class="hl-string">"Candidate Hired", class="hl-string">"EventTime": bp_time, **base_event})

    class=class="hl-string">"hl-comment"># Remove events with no timestamp and duplicates
    final_events = []
    seen = set()
    for event in events:
        if event.get(class="hl-string">"EventTime"):
            class=class="hl-string">"hl-comment"># Create a unique key for each event to handle duplicates
            event_key = (event[class="hl-string">"JobApplicationId"], event[class="hl-string">"ActivityName"], event[class="hl-string">"EventTime"])
            if event_key not in seen:
                final_events.append(event)
                seen.add(event_key)

    return final_events

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Workday Recruiting data extraction.")
    raw_applications = get_workday_job_applications()
    
    if raw_applications:
        all_events = []
        for app in raw_applications:
            all_events.extend(transform_application_to_events(app))
        
        if all_events:
            class=class="hl-string">"hl-comment"># Create DataFrame and format for ProcessMind
            df = pd.DataFrame(all_events)
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.tz_localize(None)
            df = df.sort_values(by=[class="hl-string">"JobApplicationId", class="hl-string">"EventTime"])
            
            output_filename = class="hl-string">"workday_recruiting_event_log.csv"
            df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
            print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")
        else:
            print(class="hl-string">"No events were generated from the fetched applications.")
    else:
        print(class="hl-string">"No applications found or an error occurred.")

Steps

Prerequisites and Setup: Ensure you have a licensed third-party ETL or iPaaS tool, such as CData, MuleSoft, or a similar platform, with its Workday connector installed. Confirm you have credentials for a Workday Integration System User (ISU) with the necessary API permissions for the Recruiting and Staffing domains.
Configure Workday Connection: In your ETL tool, create a new connection to Workday. Provide your Workday tenant URL, API version, and the ISU credentials, for example, username and password or OAuth 2.0 tokens. Test the connection to ensure it is successful.
Explore the Data Schema: Use the schema browser or data source explorer in your ETL tool to view the Workday objects available through the connector. These are typically presented as tables or views, such as Job_Application, Job_Requisition, and Candidate_Stage_History. Familiarize yourself with the available fields and relationships.
Identify Key Data Objects: For this extraction, you will primarily need data from objects related to job applications, candidate history, interviews, offers, and hires. The exact names will depend on your connector, but look for objects representing these core entities.
Develop the SQL Query: Create a new data extraction job or pipeline. Use a SQL transformation step to run a query against the Workday connection. Copy and paste the provided SQL query into this step. This query is designed to gather data from multiple Workday objects and union them into a single event log format.
Parameterize the Query: Modify the query's WHERE clause to include parameters for the date range, for example, startDate and endDate. Configure these parameters in your ETL job so you can easily change the extraction window without altering the code.
Execute the Extraction Job: Run the configured ETL job. The tool will connect to Workday, execute the SQL query via the API, and retrieve the data into a staging area or memory.
Review and Validate Data: Before writing the final output, use the preview feature in your ETL tool to inspect the results. Check for a reasonable number of rows, ensure all columns are populated as expected, and verify that different activities are present.
Configure the Destination: Define the target for your extracted data. This is typically a CSV file for upload to ProcessMind. Configure the file name, delimiter (comma), and encoding (UTF-8).
Finalize and Export: Run the full extraction job to generate the final CSV file. Ensure the column headers in the output file match the required attributes: JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Department, and ApplicationStatus.

Configuration

Workday Connector Credentials: The connection requires the Workday tenant URL and an authorized Integration System User (ISU) with a password or OAuth 2.0 client credentials. The user must have security permissions for the 'Recruiting' and 'Staffing' functional areas.
Web Service Enablement: The connector may require you to specify which Workday Web Services to expose. Ensure that services related to Recruiting, Staffing, and Human Resources are enabled to access all necessary data objects.
Date Range: To manage performance and data volume, it is critical to filter the extraction by a specific time period. We recommend an initial load of 3 to 6 months of data, followed by incremental daily or weekly loads. This is managed via the WHERE clause in the SQL query.
Data Scope Filters: If you only need to analyze the process for certain parts of the organization, consider adding filters in the WHERE clause for fields like Company, Cost Center, or Supervisory Organization.
API Version: Some connectors require you to specify the Workday API version. It is best to use a recent, supported version to ensure access to the latest data objects and features.
Performance Considerations: Full data extractions from Workday can be resource-intensive. Schedule large jobs during off-peak hours. For ongoing analysis, implement an incremental loading strategy based on a 'last modified' timestamp to only pull new or updated records.

a Sample Query sql

WITH BaseApplicationInfo AS (
    SELECT
        JA.Job_Application_ID AS JobApplicationId,
        JR.Hiring_Manager_WID AS HiringManagerId,
        JR.Recruiter_WID AS RecruiterId,
        JA.Source_System AS ApplicationSource,
        SO.Organization_Name AS Department,
        JA.Application_Status AS ApplicationStatus,
        JA.Date_Applied AS ApplicationDate,
        JA.Date_Moved_to_Hire AS HireDate,
        OFR.Offer_Date AS OfferDate,
        HIRE.Hire_Onboarding_Date AS OnboardingDate,
        OFR.Offer_Accepted_Date AS OfferAcceptedDate
    FROM
        [Job_Applications] AS JA
    LEFT JOIN [Job_Requisitions] AS JR ON JA.Job_Requisition_ID = JR.Job_Requisition_ID
    LEFT JOIN [Supervisory_Organizations] AS SO ON JR.Supervisory_Organization_WID = SO.Supervisory_Organization_WID
    LEFT JOIN [Job_Application_Offer_Details] AS OFR ON JA.Job_Application_ID = OFR.Job_Application_ID
    LEFT JOIN [Job_Application_Hire_Details] AS HIRE ON JA.Job_Application_ID = HIRE.Job_Application_ID
)
SELECT
    BAI.JobApplicationId,
    'Application Received' AS ActivityName,
    BAI.ApplicationDate AS EventTime,
    Recruiter.Worker_Name AS RecruiterName,
    HiringManager.Worker_Name AS HiringManager,
    BAI.ApplicationSource,
    BAI.Department,
    BAI.ApplicationStatus
FROM BaseApplicationInfo BAI
LEFT JOIN [Workers] AS Recruiter ON BAI.RecruiterId = Recruiter.Worker_WID
LEFT JOIN [Workers] AS HiringManager ON BAI.HiringManagerId = HiringManager.Worker_WID

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Application Screened', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Stage_Name = 'Screen'

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Candidate Moved To Interview', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Stage_Name = 'Interview'

UNION ALL

SELECT
    I.Job_Application_ID, 'Interview Scheduled', I.Scheduled_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Interview_Events] I
JOIN BaseApplicationInfo BAI ON I.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE I.Interview_Status = 'Scheduled'

UNION ALL

SELECT
    I.Job_Application_ID, 'Interview Completed', I.Completed_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Interview_Events] I
JOIN BaseApplicationInfo BAI ON I.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE I.Interview_Status = 'Completed'

UNION ALL

SELECT
    F.Job_Application_ID, 'Feedback Submitted', F.Submitted_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Interview_Feedback] F
JOIN BaseApplicationInfo BAI ON F.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Candidate Moved To Offer Stage', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Stage_Name = 'Offer'

UNION ALL

SELECT
    BAI.JobApplicationId, 'Offer Extended', BAI.OfferDate, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM BaseApplicationInfo BAI
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE BAI.OfferDate IS NOT NULL

UNION ALL

SELECT
    BAI.JobApplicationId, 'Offer Accepted', BAI.OfferAcceptedDate, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM BaseApplicationInfo BAI
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE BAI.OfferAcceptedDate IS NOT NULL

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Background Check Initiated', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Stage_Name = 'Background Check'

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Background Check Cleared', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Stage_Name = 'Background Check' AND CSH.Status = 'Passed'

UNION ALL

SELECT
    BAI.JobApplicationId, 'Onboarding Initiated', BAI.OnboardingDate, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM BaseApplicationInfo BAI
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE BAI.OnboardingDate IS NOT NULL

UNION ALL

SELECT
    BAI.JobApplicationId, 'Candidate Hired', BAI.HireDate, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM BaseApplicationInfo BAI
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE BAI.HireDate IS NOT NULL

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Candidate Rejected', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Disposition_Reason LIKE '%Rejected%'

UNION ALL

SELECT
    CSH.Job_Application_ID, 'Application Withdrawn', CSH.Effective_Timestamp, R.Worker_Name, HM.Worker_Name, BAI.ApplicationSource, BAI.Department, BAI.ApplicationStatus
FROM [Candidate_Stage_History] CSH
JOIN BaseApplicationInfo BAI ON CSH.Job_Application_ID = BAI.JobApplicationId
LEFT JOIN [Workers] R ON BAI.RecruiterId = R.Worker_WID
LEFT JOIN [Workers] HM ON BAI.HiringManagerId = HM.Worker_WID
WHERE CSH.Disposition_Reason LIKE '%Withdrawn by Candidate%'

WHERE EventTime >= '[Your Start Date]' AND EventTime < '[Your End Date]'

Your Recruitment & Talent Acquisition Data Template

Your Recruitment & Talent Acquisition Data Template

Recruitment & Talent Acquisition Attributes

Recruitment & Talent Acquisition Activities

Extraction Guides

Workday Report-as-a-Service (RaaS) Extraction

Steps

Configuration

a Sample Query config

Workday Recruiting API Extraction via Python Script

Steps

Configuration

a Sample Query python

ETL Tool Extraction with a Workday Connector

Steps

Configuration

a Sample Query sql

Ready to Get Started?

End Hiring Bottlenecks: Optimize Your Talent Acquisition Today

Your Recruitment & Talent Acquisition Data Template

Your Recruitment & Talent Acquisition Data Template

Recruitment & Talent Acquisition Attributes

Recruitment & Talent Acquisition Activities

Extraction Guides

Workday Report-as-a-Service (RaaS) Extraction

Steps

Configuration

a Sample Query config

Workday Recruiting API Extraction via Python Script

Steps

Configuration

a Sample Query python

ETL Tool Extraction with a Workday Connector

Steps

Configuration

a Sample Query sql

We value your privacy

Ready to Get Started?

End Hiring Bottlenecks: Optimize Your Talent Acquisition Today