> Continuous Process Improvement > Hire to Retire Employee Lifecycle > Workday Onboarding > Data Template

Data Template: Hire to Retire - Employee Lifecycle

Workday Onboarding

Hire to Retire - Employee Lifecycle Attributes (22) Hire to Retire - Employee Lifecycle Activities (15) Extraction Guides (2)

Your Hire to Retire - Employee Lifecycle Data Template

This template provides a clear guide on the essential data attributes and activities required to effectively analyze your Hire to Retire process. It helps you identify the critical information needed to build a robust event log, ensuring accurate insights into your employee lifecycle. Additionally, you'll find guidance on extracting this data specifically from Workday Onboarding.

Recommended attributes to collect for thorough analysis
Key activities to track across the employee lifecycle
Practical guidance for data extraction from Workday Onboarding

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

Download Template

Hire to Retire - Employee Lifecycle Attributes

These are the recommended data fields to include in your event log for comprehensive analysis of your Hire to Retire - Employee Lifecycle process.

3 Required 5 Recommended 14 Optional

	Name	Description
	Activity Name ActivityName	The name of the specific event or task that occurred at a point in the employee's lifecycle.
Description The Activity Name describes a specific step in the Hire-to-Retire process, such as 'Offer Accepted', 'Background Check Completed', or 'Promotion Approved'. These activities form the nodes of the process map, showing the sequence of events that make up the employee journey. Analyzing these activities helps organizations understand the process flow, identify frequent and rare paths, and pinpoint stages where delays or rework occur. Consistent and clear activity naming is crucial for building an accurate and understandable process model. Why it matters It defines the steps in the process map, which is the foundation of all process mining analysis and visualization. Where to get Derived from the Business Process Step or Event Name within Workday transaction logs. Examples Offer Letter GeneratedOnboarding Tasks CompletedTermination Initiated
	Employee ID EmployeeId	The unique identifier for an employee, serving as the primary case ID for their entire lifecycle within the organization.
Description The Employee ID is the cornerstone of the Hire-to-Retire process analysis. It links all related events, from the initial job application to the final termination, into a single, cohesive journey. By tracking this ID, organizations can build a complete history of an employee's tenure, including role changes, performance reviews, and onboarding steps. In process mining, every activity is associated with an Employee ID, allowing for a comprehensive view of individual and aggregate employee lifecycles. This enables analysis of process durations, identification of common pathways, and discovery of bottlenecks that affect employees at different stages of their careers. Why it matters This attribute is essential for stitching together all lifecycle events for a single employee, enabling a complete end-to-end process view. Where to get This is a core field in Workday HCM, typically found in worker profiles and business process transactions. Examples 100234510087651011212
	Event Timestamp EventTimestamp	The precise date and time when the activity or event was recorded.
Description This attribute provides the temporal context for each activity, recording when it happened. The sequence and timing of these timestamps are used to construct the process flow and calculate all time-based metrics, such as cycle times and durations. In analysis, Event Timestamp is fundamental for understanding process performance. It allows for calculating the time between steps, identifying delays, and analyzing process behavior over different time periods, such as comparing quarter-over-quarter hiring speed. Why it matters This attribute is critical for ordering events correctly and calculating all performance metrics like cycle time and bottlenecks. Where to get This is a standard part of any business process transaction log in Workday, often referred to as the 'Effective Date' or 'Completed Moment'. Examples 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2024-01-15T09:12:00Z
	Department Department	The organizational department to which the employee belongs.
Description This attribute represents the employee's assigned department, such as 'Sales', 'Engineering', or 'Human Resources'. It is a critical dimension for segmenting and comparing process performance across different parts of the organization. In process analysis, filtering by Department allows for answering questions like, 'Is the time-to-hire longer for the Engineering department than for Sales?' or 'Which departments have the highest rate of onboarding deviations?'. This helps pinpoint localized issues and tailor process improvements. Why it matters It allows for powerful comparative analysis, helping to identify if process inefficiencies are concentrated in specific business areas. Where to get This is part of the employee's core job and organizational data in Workday HCM, linked to their position. Examples EngineeringSales and MarketingFinance
	Event End Time EventEndTime	The timestamp marking the completion of an activity, particularly for tasks with a measurable duration.
Description While StartTime indicates when an activity began, Event End Time marks its conclusion. The difference between the two represents the processing time of the activity. This is particularly useful for tasks that are not instantaneous, such as 'Background Check' or 'Performance Review'. In analysis, this attribute is crucial for calculating the `ProcessingTime` metric. It helps differentiate between the waiting time between activities and the actual time spent working on an activity, leading to a more precise understanding of where time is spent in the process. Why it matters It enables the calculation of an activity's true processing time, helping to distinguish active work time from idle waiting time. Where to get For some business processes in Workday, both initiation and completion timestamps are logged. This may require joining events. Examples 2023-10-26T18:30:00Z2023-11-05T11:00:15Z2024-01-15T17:20:00Z
	Event Performer EventPerformer	The user or automated system agent who executed the activity.
Description This attribute identifies the individual, role, or system responsible for completing a task. It could be a hiring manager approving an offer, an HR specialist initiating onboarding, or a system process generating a notification. Analyzing the Event Performer is key to understanding resource allocation, workload distribution, and user adoption. It can help identify overburdened teams, highlight opportunities for automation where manual users perform repetitive tasks, and analyze performance differences between individuals or departments. Why it matters This attribute helps analyze workload distribution, user performance, and identifies who is involved in the process, which is key for targeted improvements. Where to get Available in the transaction logs of Workday Business Processes, often associated with the user who completed a step. Examples jsmith@example.comr.davisSystem Process
	Job Requisition ID JobRequisitionId	The unique identifier for the job requisition that initiated the hiring process.
Description The Job Requisition ID links all early-stage hiring activities, such as posting a job, screening candidates, and generating offers, to a specific business need. It acts as a secondary case ID for the recruitment phase of the employee lifecycle. Analyzing by Job Requisition ID can reveal insights into the efficiency of the hiring process for different roles or departments. It helps track the entire funnel from requisition creation to offer acceptance, supporting KPIs like 'Average Time-to-Hire'. Why it matters It groups all pre-hire activities under a single identifier, enabling detailed analysis of the recruitment part of the process. Where to get Found within the Recruiting module of Workday. It's associated with the candidate's application and subsequent hiring event. Examples REQ-2023-05-101REQ-2024-01-230REQ-2023-11-087
	Lifecycle Event Type LifecycleEventType	Categorizes the process into major lifecycle types like Onboarding, Promotion, or Offboarding.
Description This attribute provides a high-level classification for different journeys within the overall Hire-to-Retire process. By tagging each case as 'Onboarding', 'Internal Mobility', or 'Termination', it becomes much easier to filter the process map and analyze these distinct subprocesses in isolation. For example, to analyze the 'Internal Mobility & Promotion Time' dashboard, one would filter for cases where Lifecycle Event Type is 'Internal Mobility' or 'Promotion'. This segmentation is crucial for creating targeted analyses and dashboards that answer specific business questions. Why it matters It allows for segmenting the overall employee journey into distinct subprocesses, enabling focused analysis on onboarding, offboarding, or promotions. Where to get This is typically derived by mapping specific Workday Business Process names (e.g., 'Hire', 'Change Job', 'Terminate') to these categories during data transformation. Examples OnboardingInternal MobilityOffboardingPerformance Management
	Employment Status EmploymentStatus	The current employment status of the employee, such as Active, Terminated, or On Leave.
Description This attribute indicates the employee's current status within the organization. It's a dynamic field that changes as the employee moves through their lifecycle. For example, a new hire starts as 'Pre-Hire' or 'Onboarding' and becomes 'Active' upon completion. In process mining, this attribute provides valuable state information. It can be used to check process compliance, for example, ensuring that payroll is only set up for 'Active' employees. It also helps in filtering for specific populations, such as analyzing the offboarding process for all 'Terminated' employees. Why it matters Provides a snapshot of the employee's current state, which is useful for validating process logic and for filtering analyses to specific employee populations. Where to get A core field on the worker's profile in Workday HCM. Examples ActiveTerminatedOn LeavePre-Hire
	Employment Type EmploymentType	Indicates whether the employee is full-time, part-time, a contractor, or an intern.
Description This attribute classifies the nature of the employment agreement. Different employment types often follow different process variants for onboarding, payroll, and benefits setup. By using this attribute as a filter, organizations can compare the lifecycle processes for different worker categories. This can highlight if, for example, the onboarding process for contractors is significantly faster or less compliant than the one for full-time employees, allowing for targeted process adjustments. Why it matters Helps in comparing process variations between different worker categories, such as full-time employees and contractors, who may follow different procedures. Where to get A standard field on the employee's job details in Workday HCM. Examples Full-TimePart-TimeContractorIntern
	Is Compliance Activity IsComplianceActivity	A boolean flag indicating if an activity is a required compliance or regulatory step.
Description This flag identifies activities that are critical for legal, regulatory, or policy compliance, such as signing a policy acknowledgment or completing mandatory training. It helps in separating these critical tasks from regular administrative ones. In analysis, this attribute allows for creating dashboards and KPIs focused specifically on compliance, such as the 'Critical Compliance Activity Rate'. It helps organizations monitor and ensure that the most important regulatory steps are being completed on time for all employees, reducing organizational risk. Why it matters Enables focused monitoring of critical compliance steps to ensure regulatory adherence and mitigate risk. Where to get This is a derived attribute, typically created during data transformation by mapping a list of known compliance-related activity names to a true/false flag. Examples truefalse
	Is Rework IsRework	A boolean flag that indicates if an activity is a repetition of a previous step in the same case.
Description This attribute identifies instances of rework, where a task has to be performed more than once for the same employee. Examples include resubmitting incorrect paperwork or re-running a failed background check. It is typically identified by seeing the same activity name appear multiple times within a case's event log. Analyzing rework is key to improving process efficiency and quality. The 'IsRework' flag makes it easy to quantify the amount of rework, identify its root causes, and measure the impact of improvements aimed at getting things right the first time. It directly supports the 'Rework & Repetition Analysis' dashboard. Why it matters Helps quantify process inefficiency and waste by flagging activities that are being repeated, pointing to quality or communication issues. Where to get This is a calculated flag. The logic is applied during process mining analysis by detecting repeated activities within the same case. Examples truefalse
	Is SLA Violated IsSlaViolated	A boolean flag indicating if an activity was completed after its target SLA date.
Description This calculated attribute provides a simple true/false indicator of whether a process step met its service level agreement. It is derived by comparing the activity's completion timestamp (EventTimestamp) with its deadline (SlaTargetDate). This flag is extremely useful for dashboards and reporting, as it allows for easy counting and visualization of SLA violations. It powers KPIs like 'Performance Review Timeliness' and simplifies the creation of alerts or reports on overdue tasks, helping teams focus on the most critical delays. Why it matters Simplifies performance monitoring by clearly flagging all instances where agreed-upon timelines were not met. Where to get Calculated field: `true` if `EventTimestamp` > `SlaTargetDate`, otherwise `false`. Examples truefalse
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data for this event was refreshed from the source system.
Description This attribute marks when the dataset was last updated. It provides transparency into the freshness of the data being analyzed, which is critical for making timely and relevant business decisions based on the process mining insights. For dashboards and ongoing monitoring, this timestamp helps users understand if they are looking at the most current data available. It is a key piece of metadata for maintaining data integrity and user trust in the analysis. Why it matters Ensures users are aware of the data's freshness, which is critical for the relevance and accuracy of the process analysis. Where to get This is a metadata field generated and stamped onto the dataset during the data ingestion or ETL (Extract, Transform, Load) process. Examples 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	Location Location	The geographical location or office associated with the employee's position.
Description The Location attribute specifies the country, state, or city where the employee is based. This geographical dimension is essential for comparing process performance and compliance across different regions. Analysis using Location can uncover regional variations in hiring times, onboarding efficiency, or termination procedures. It helps answer questions like, 'Do background checks take longer in Germany than in the United States?' and supports compliance monitoring for region-specific regulations. Why it matters Enables geographical analysis to identify regional process variations, which can be influenced by local management, regulations, or culture. Where to get Part of the employee's position and organizational assignment data within Workday HCM. Examples USA - New YorkGermany - BerlinIndia - Bangalore
	Onboarding Plan Name OnboardingPlanName	The name of the specific onboarding template or plan assigned to the new hire.
Description Workday allows for the creation of different onboarding plans tailored to various roles, locations, or seniority levels. This attribute identifies which specific plan was used for a new employee. Analyzing by Onboarding Plan Name helps evaluate the effectiveness and efficiency of different onboarding strategies. It allows for direct comparison, for example, between an 'Executive Onboarding Plan' and a 'Standard Employee Onboarding Plan', to see which one has better task completion rates or faster cycle times. Why it matters This helps evaluate the performance of different onboarding programs to identify best practices and areas for improvement. Where to get This information is likely available within the Onboarding module of Workday, associated with the Hire business process. Examples Standard Corporate OnboardingSales Team OnboardingExecutive Onboarding Plan
	Position ID PositionId	The unique identifier for the specific position or job role held by the employee.
Description The Position ID identifies the specific role an employee occupies within the organization's structure. Each position has defined attributes, such as job profile, location, and reporting structure. It is more specific than a job title, as multiple positions can share the same title. Analyzing by Position ID helps in understanding processes related to specific roles. For instance, one could analyze the onboarding journey for all 'Senior Software Engineer' positions to see if there are common patterns or delays unique to that role. Why it matters Allows for granular analysis based on specific roles, helping to understand how processes differ for various positions within the company. Where to get A standard field associated with the employee's job assignment in Workday HCM. Examples POS-1001POS-2345POS-8762
	Processing Time ProcessingTime	The duration of time spent actively working on an event.
Description This metric calculates the time elapsed between the start and end of an activity (EventEndTime - StartTime). It represents the actual work duration, as opposed to waiting time between activities. For example, it could measure how long a background check was actively being processed. Analyzing Processing Time helps identify which specific tasks are taking the most effort, rather than just which process stages have the longest delays. This allows for more targeted improvements aimed at making the work itself more efficient. Why it matters It isolates the time spent on value-adding work from idle time, providing a clear target for efficiency improvements at the task level. Where to get Calculated field: `EventEndTime` minus `EventTimestamp`. Examples 2 hours5 days30 minutes
	SLA Target Date SlaTargetDate	The target date by which a specific activity, like a performance review, should be completed.
Description This attribute defines the Service Level Agreement (SLA) deadline for a particular task. It sets the expectation for how long certain processes should take and serves as a benchmark for measuring performance. This is essential for KPIs like 'Performance Review Timeliness' and dashboards focused on SLA adherence. By comparing the actual completion date (EventTimestamp) to the SlaTargetDate, it's possible to automatically identify violations, measure on-time performance, and proactively manage delays. Why it matters Provides a clear benchmark for measuring on-time performance and is essential for calculating SLA adherence KPIs. Where to get For processes like Performance Reviews in Workday, a due date is often configured. This data would need to be extracted alongside the process events. Examples 2023-12-31T23:59:59Z2024-06-30T23:59:59Z
	Source System SourceSystem	The system from which the event data was extracted, in this case, Workday Onboarding.
Description This attribute identifies the origin of the data. While in this view we focus on Workday Onboarding, a full Hire-to-Retire process might involve data from other systems like an Applicant Tracking System (ATS) or a separate payroll provider. Specifying the source system is key for data governance and for understanding the context of the event. In a multi-system analysis, this field allows for filtering the process view to events from a specific system or analyzing the handoffs between different systems. Why it matters It provides crucial context about data origin, which is essential for data validation and for analyses that combine data from multiple systems. Where to get This is typically a static value ('Workday Onboarding') added during the data extraction and transformation process. Examples Workday OnboardingWorkday HCM
	Termination Reason TerminationReason	The reason provided for an employee's departure from the organization.
Description This attribute captures why an employee's tenure ended, such as 'Voluntary Resignation', 'Involuntary - Performance', or 'Retirement'. This information is critical for analyzing attrition and the offboarding process. In process mining, Termination Reason provides context to the offboarding journey. It can be used to analyze if different termination types follow different offboarding procedures or take different amounts of time. This helps in understanding employee turnover and ensuring the offboarding process is handled appropriately for each situation. Why it matters Provides crucial context for analyzing the offboarding process and helps correlate process issues with reasons for attrition. Where to get Captured during the 'Terminate Employee' business process in Workday. Examples Resignation, VoluntaryTermination, InvoluntaryRetirement
	Time to Hire TimeToHire	The total time from when a job requisition is created until the candidate accepts the offer.
Description Time to Hire is a critical recruitment KPI that measures the efficiency of the entire hiring funnel. It is calculated as the duration between the 'Job Requisition Created' event and the 'Offer Accepted' event for the same employee or requisition. This calculated attribute is the basis for the 'Average Time-to-Hire' KPI and related dashboards. Tracking it over time allows HR departments to measure the impact of process improvements, identify bottlenecks in sourcing or interviewing, and set realistic hiring timelines for managers. Why it matters Directly measures the efficiency of the recruitment process, a key performance indicator for any HR organization. Where to get Calculated at the case level by finding the duration between the timestamp of the 'Job Requisition Created' activity and the 'Offer Accepted' activity. Examples 35 days62 days28 days

Required Recommended Optional

Hire to Retire - Employee Lifecycle Activities

These are the key process steps and milestones to capture in your event log for accurate discovery and analysis of your employee lifecycle.

7 Recommended 8 Optional

	Activity	Description
	Employee Terminated	This is the final activity in the employee lifecycle, marking the official end of their employment in the system. This event is captured when the 'Terminate Employee' business process successfully completes.
Why it matters This is the definitive end event for the hire-to-retire process. It is the endpoint for measuring the offboarding cycle time and confirms the process is finalized. Where to get Explicitly logged as the completion event for the 'Terminate Employee' business process. The employee's record becomes inactive after this point. Capture Event logged upon successful completion of the 'Terminate Employee' business process. Event type explicit
	Hire Process Completed	This is a pivotal activity where a candidate's record is officially converted into an employee record in Workday HCM. This event is captured explicitly upon the successful completion of the 'Hire' business process.
Why it matters This event formally marks the transition from candidate to employee and is a critical milestone for tracking onboarding cycle time. It signifies the employee is officially in the HCM system. Where to get Explicitly logged as the completion event for the 'Hire' business process for the employee. The business process log contains the exact timestamp. Capture Event logged upon successful completion of the 'Hire' business process. Event type explicit
	Job Requisition Created	This activity marks the official start of the recruitment process when a new job requisition is created and approved in Workday. This event is captured explicitly when the 'Create Job Requisition' business process successfully completes.
Why it matters This is the primary start event for the entire hiring lifecycle. Analyzing the time from this activity to 'Offer Accepted' is crucial for measuring the Time-to-Hire KPI. Where to get This event is logged upon the successful completion of the 'Create Job Requisition' business process in Workday Recruiting. The event log for this business process provides the timestamp. Capture Event logged on completion of the 'Create Job Requisition' business process. Event type explicit
	Offer Accepted	This activity occurs when a candidate formally accepts the job offer, often by electronically signing the offer letter within Workday. This is a critical milestone captured when the candidate completes the 'Review and Sign' step in the offer process.
Why it matters This milestone concludes the core recruitment phase and triggers pre-hire and onboarding activities. It's a key component for measuring the Time-to-Hire KPI. Where to get This is an explicit event logged when the candidate completes the acceptance step of the job offer within the 'Job Application' business process. Capture Candidate action of accepting the offer is logged as a completed step in the Job Application BP. Event type explicit
	Onboarding Initiated	Marks the kickoff of the new hire's onboarding journey within the Workday Onboarding module. This is captured when the set of onboarding tasks and workflows are assigned to the new employee, typically triggered by the completion of the Hire process.
Why it matters This is the start point for analyzing the efficiency of the onboarding journey. It helps measure onboarding task completion rates and identify process deviations. Where to get Logged as an initiation event when the 'Onboarding' business process or a similar workflow is triggered for the new employee. Capture Event logged when the Onboarding business process is triggered for the new hire. Event type explicit
	Onboarding Tasks Completed	Represents the completion of all assigned onboarding tasks for a new hire. This event is typically inferred when the overall status of the onboarding business process for the employee moves to 'Successfully Completed'.
Why it matters This is a key milestone indicating a new hire is fully onboarded. It serves as the end point for measuring the Onboarding Cycle Time KPI and analyzing onboarding journey adherence. Where to get Inferred from the completion timestamp of the parent 'Onboarding' business process, which occurs after all required steps and tasks are finished. Capture Inferred from the completion timestamp of the overall Onboarding business process for the employee. Event type inferred
	Termination Initiated	This activity marks the beginning of the offboarding process for a departing employee. It is captured explicitly when a manager or HR user initiates the 'Terminate Employee' business process in Workday.
Why it matters This is the primary start event for the entire offboarding lifecycle. It is the starting point for measuring the Average Offboarding Cycle Time KPI. Where to get This is an explicit event logged at the initiation of the 'Terminate Employee' business process in Workday HCM. Capture Event logged when the 'Terminate Employee' business process is initiated. Event type explicit
	Background Check Completed	Represents the completion of the pre-employment screening process. This is captured when the background check status is updated to complete, either manually or via an integration.
Why it matters This activity is the end point for measuring the Background Check Duration KPI. Delays in this activity directly impact the new hire's start date. Where to get Captured from a status change on the 'Background Check' business process or a related object, indicating a final status like 'Completed' or 'Passed'. Capture Inferred from the timestamp when the background check status field changes to a final state. Event type inferred
	Background Check Initiated	This marks the start of the pre-employment screening process for a candidate who has accepted an offer. The event is captured when the background check step is initiated, often triggering an integration with a third-party vendor.
Why it matters The duration of background checks is often a bottleneck in the hiring process. This activity is the starting point for measuring the Background Check Duration KPI. Where to get Logged as a step within a business process, such as 'Background Check', which is often part of the overall hiring workflow. The initiation timestamp is recorded. Capture Event logged upon initiation of the 'Background Check' business process or a related step. Event type explicit
	Offboarding Tasks Completed	Represents the completion of all required offboarding tasks, such as asset return and knowledge transfer. This event is inferred when the offboarding checklist or business process moves to a completed status.
Why it matters Tracking the completion of these tasks is crucial for ensuring a secure and compliant offboarding. Delays can pose security risks and create a poor experience. Where to get Inferred from the completion timestamp of the 'Offboarding' business process or when all assigned offboarding tasks are marked as complete for the employee. Capture Inferred from the completion of an offboarding checklist or related business process. Event type inferred
	Offer Letter Generated	Represents the point when a formal job offer is generated for a candidate. This is typically an explicit step within the 'Job Application' business process in Workday.
Why it matters Tracking this helps to understand the time taken to formalize an offer after interviews are complete. Delays here can cause candidates to drop out. Where to get Captured from the event log for the 'Job Application' business process, specifically the completion of the 'Generate Document' or a similar offer step. Capture Event logged on completion of the 'Generate Offer' step in the Job Application BP. Event type explicit
	Payroll Setup Completed	This activity signifies that all necessary information for processing the new employee's payroll has been entered and verified. This may be captured as the completion of a specific step within the Onboarding or Hire business process.
Why it matters Ensures employees are paid correctly and on time from their first paycheck. This activity is the endpoint for the Payroll Setup Time KPI, highlighting delays in compensation activation. Where to get Captured as a completed checklist item or a specific step, such as 'Enter Payment Elections', within the Onboarding business process. Capture Completion of a specific payroll-related task or step within a business process. Event type explicit
	Performance Review Completed	This activity marks the completion of a formal performance review cycle for an employee. It is captured when the 'Performance Review' business process reaches its final, approved state.
Why it matters Tracking these events is essential for analyzing the timeliness and frequency of performance management. It directly supports the Performance Review Timeliness KPI. Where to get Logged as the successful completion event of the 'Start Performance Review' business process for the employee. Capture Event logged upon successful completion of the 'Performance Review' business process. Event type explicit
	Promotion Approved	Marks the final approval of an employee's promotion. This activity is captured when the 'Change Job' or a related compensation business process is fully approved and completed.
Why it matters This is the endpoint for measuring the Internal Mobility Approval Time KPI. It confirms the successful completion of a key career milestone. Where to get Logged as the successful completion event of the 'Change Job' business process, where the reason for the change is a promotion. Capture Event logged on completion of the 'Change Job' business process with a 'Promotion' reason. Event type explicit
	Role Change Initiated	Represents the start of an internal mobility event, such as a transfer or promotion. This is captured when a manager or HR partner initiates the 'Change Job' business process for an employee.
Why it matters This activity is the starting point for measuring internal mobility efficiency and approval times. It helps identify bottlenecks in career progression for employees. Where to get This is an explicit event logged at the initiation of the 'Change Job' business process in Workday HCM. Capture Event logged when the 'Change Job' business process is initiated for an employee. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from Workday Onboarding

Steps

Log into Workday: Access your Workday instance with a user account that has permissions to create custom reports (Report Writer) and access the required data domains (e.g., Staffing, Core HCM, Onboarding, Performance Management).
Create a New Custom Report: Navigate to the 'Create Custom Report' task. Select 'Advanced' as the report type. This type is necessary for creating a complex, multi-source report.
Define Primary Business Object: Set the primary 'Data Source' to 'Business Process Transactions'. This object provides a comprehensive view of all business process events, which is essential for creating an event log. Choose 'All Business Process Transactions' to ensure no events are initially excluded.
Add Initial Columns: In the 'Columns' tab, add the fields that will serve as the basis for your event log. Start with:
- Worker (from Business Process Transaction) > Employee ID for the EmployeeId.
- Overall Process (from Business Process Transaction) for ActivityName logic.
- Effective Date or Completion Date (from Business Process Transaction) for EventTimestamp.
- Initiator for EventPerformer.
- Worker > Supervisory Organization > Department for Department.
Create Calculated Fields for Activities: The core of this extraction is mapping Workday business process steps to specific activity names. Create a series of 'Evaluate Expression' calculated fields. Each field will check the business process type and its status to output the correct ActivityName. For example, a calculated field named CF_ActivityName_Hire would have a condition like: Business Process Type = 'Hire' AND Step = 'Successfully Completed' and return the text 'Hire Process Completed'. You will create similar fields for all 15 required activities.
Create a Master Calculated Field: Create a final 'Lookup Related Value' or 'Evaluate Expression' calculated field named ActivityName. This field will chain together all the individual activity fields from the previous step, ensuring only one activity name is returned per row.
Structure as a Unioned Report: To combine events from different business processes cleanly, convert the report to a 'Composite' report and use the 'Union' sub-report type. Create a separate data source for each major lifecycle process (e.g., 'Hire', 'Onboarding', 'Change Job', 'Terminate'). In each sub-report, filter for that specific business process type and map its relevant steps to the standard output columns (EmployeeId, ActivityName, EventTimestamp, etc.).
Configure Prompts and Filters: Add prompts for the date range, allowing users to specify the extraction period. Add filters to limit the data to specific companies or supervisory organizations if needed. This is crucial for managing performance.
Enable as a Web Service: Navigate to the 'Advanced' tab of the report definition. Check the 'Enable as Web Service' box. This exposes the report as a Report-as-a-Service (RaaS) endpoint.
Configure API Options: Under 'Web Service API Options', select JSON as the output format for easier parsing by downstream systems. Note the 'Namespace' and 'Report Name' as they will be part of the API URL.
Deploy and Test: Save and run the report from the Workday UI to validate the data. Once confirmed, access the RaaS URL via a browser or API client (like Postman) to test the web service endpoint. The URL format is typically https://[Your Workday Host]/ccx/service/[Your Tenant]/Report_Service/[Report Owner]/[Report Name].
Schedule Extraction: Use your integration or ETL tool to schedule regular calls to the RaaS URL, passing the desired date range parameters to pull the event log data into your process mining tool.

Configuration

Report Type: Advanced. This is required to support calculated fields and unioned sub-reports.
Primary Data Source / Business Object: 'Business Process Transactions'. This object is the foundation as it contains records of all process initiations, steps, and completions across Workday.
Calculated Fields: Extensive use of 'Evaluate Expression' calculated fields is necessary to translate raw business process events (e.g., 'Hire BP, Step: Propose Compensation, Status: Completed') into a clean activity name (e.g., 'Hire Process Completed').
Prompts: Configure prompts for 'Start Date' and 'End Date' based on the 'Completion Date' field. This allows for incremental or bounded data extractions.
Filtering: It is highly recommended to filter by 'Company' or 'Supervisory Organization' to manage data volume and focus the analysis on relevant parts of the organization. You should also filter out business processes that are not relevant to the employee lifecycle.
Web Service Options: The report must be enabled as a web service ('RaaS'). The output format should be set to JSON for broad compatibility.
Security & Permissions: The user creating and running the report needs access to the following data domains: 'Business Process Transactions', 'Worker Data (Core HCM)', 'Staffing', 'Onboarding', and potentially 'Compensation' and 'Performance Management' to see all related events and attributes.

a Sample Query config

/*
 This is a logical representation of a Workday Advanced Composite Report configuration.
 It is not executable code but a blueprint for a Workday Report Writer.
 The report unions data from different business processes to form a single event log.
*/

REPORT_TYPE: Composite
COMPOSITE_TYPE: Union

// =======================================================
// SUB-REPORT 1: RECRUITMENT AND HIRE EVENTS
// =======================================================

SUB_REPORT_NAME: SR_RecruitHire
DATA_SOURCE: Business Process Transactions

COLUMNS:
  1. Field: Worker > Employee ID | Alias: EmployeeId
  2. Calculated Field: CF_ActivityName_RecruitHire | Alias: ActivityName
  3. Field: Completion Date | Alias: EventTimestamp
  4. Field: Initiator | Alias: EventPerformer
  5. Field: Worker > Supervisory Organization | Alias: Department
  6. Field: Job Application > Job Requisition > Requisition ID | Alias: JobRequisitionId
  7. Calculated Field: CF_LifecycleType_Onboarding | Alias: LifecycleEventType

CALCULATED_FIELDS:
  - Name: CF_ActivityName_RecruitHire
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Create Job Requisition' AND Status = 'Successfully Completed') THEN 'Job Requisition Created'
      ELSE IF (Business Process Type = 'Job Application' AND Last Step Completed = 'Generate Offer') THEN 'Offer Letter Generated'
      ELSE IF (Business process Type = 'Job Application' AND Last Step Completed = 'Candidate Accepts Offer') THEN 'Offer Accepted'
      ELSE IF (Business Process Type = 'Job Application' AND Last Step Completed = 'Background Check') THEN 'Background Check Initiated'
      ELSE IF (Business Process Type = 'Job Application' AND Last Step Completed = 'Background Check Complete') THEN 'Background Check Completed'
      ELSE IF (Business Process Type = 'Hire' AND Status = 'Successfully Completed') THEN 'Hire Process Completed'
      ELSE ''

  - Name: CF_LifecycleType_Onboarding
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Onboarding'

FILTERS:
  - Business Process Type IN ('Create Job Requisition', 'Job Application', 'Hire')
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]


// =======================================================
// SUB-REPORT 2: ONBOARDING EVENTS
// =======================================================

SUB_REPORT_NAME: SR_Onboarding
DATA_SOURCE: Business Process Transactions

COLUMNS: (Same structure as SUB-REPORT 1)

CALCULATED_FIELDS:
  - Name: CF_ActivityName_Onboarding
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Onboarding' AND Status = 'In Progress' AND First Step Initiated = 'True') THEN 'Onboarding Initiated'
      ELSE IF (Business Process Type = 'Onboarding' AND Last Step Completed = 'Complete Payroll Forms') THEN 'Payroll Setup Completed'
      ELSE IF (Business Process Type = 'Onboarding' AND Status = 'Successfully Completed') THEN 'Onboarding Tasks Completed'
      ELSE ''

  - Name: CF_LifecycleType_Onboarding
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Onboarding'

FILTERS:
  - Business Process Type = 'Onboarding'
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]


// =======================================================
// SUB-REPORT 3: PERFORMANCE AND CAREER EVENTS
// =======================================================

SUB_REPORT_NAME: SR_PerformanceCareer
DATA_SOURCE: Business Process Transactions

COLUMNS: (Same structure as SUB-REPORT 1, JobRequisitionId may be null)

CALCULATED_FIELDS:
  - Name: CF_ActivityName_PerfCareer
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Start Performance Review' AND Status = 'Successfully Completed') THEN 'Performance Review Completed'
      ELSE IF (Business Process Type = 'Change Job' AND Status = 'In Progress' AND First Step Initiated = 'True') THEN 'Role Change Initiated'
      ELSE IF (Business Process Type = 'Change Job' AND Last Step Completed = 'Approval' AND (Reason Category = 'Promotion')) THEN 'Promotion Approved'
      ELSE ''

  - Name: CF_LifecycleType_CareerDev
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Career Development'

FILTERS:
  - Business Process Type IN ('Start Performance Review', 'Change Job')
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]


// =======================================================
// SUB-REPORT 4: OFFBOARDING EVENTS
// =======================================================

SUB_REPORT_NAME: SR_Offboarding
DATA_SOURCE: Business Process Transactions

COLUMNS: (Same structure as SUB-REPORT 1, JobRequisitionId will be null)

CALCULATED_FIELDS:
  - Name: CF_ActivityName_Offboarding
    Type: Evaluate Expression
    Logic:
      IF (Business Process Type = 'Terminate Employee' AND Status = 'In Progress' AND First Step Initiated = 'True') THEN 'Termination Initiated'
      ELSE IF (Business Process Type = 'Offboarding' AND Status = 'Successfully Completed') THEN 'Offboarding Tasks Completed'
      ELSE IF (Business Process Type = 'Terminate Employee' AND Status = 'Successfully Completed') THEN 'Employee Terminated'
      ELSE ''

  - Name: CF_LifecycleType_Offboarding
    Type: Evaluate Expression
    Logic:
      IF (True) THEN 'Offboarding'

FILTERS:
  - Business Process Type IN ('Terminate Employee', 'Offboarding')
  - Completion Date BETWEEN [Prompt: Start Date] AND [Prompt: End Date]

Steps

Prerequisite: Configure Workday API Access.
- Create an Integration System User (ISU) in Workday with a secure password.
- Create a new, dedicated Integration Security Group and assign the ISU to it.
- Grant the Security Group domain security policy permissions for 'Get' access to the following domains: 'Business Process Transactions', 'Worker Data: Public Worker Reports', and any other domains relevant to the business processes being queried (e.g., 'Job Requisition Data').
- Activate the pending security policy changes in Workday.
Set Up Python Environment.
- Ensure you have Python 3.6 or newer installed on the machine that will run the script.
- Install the necessary Python libraries using pip: pip install zeep pandas.
- zeep is a SOAP client for interacting with the Workday API, and pandas is used for data manipulation and exporting to CSV.
Obtain Workday WSDL URL.
- In your Workday tenant, search for the 'Public Web Services' report.
- Find the 'Human Capital Management' web service and locate its WSDL URL. It will have a format like https://[Your_Workday_Tenant_URL]/ccx/service/[Your_Tenant_Name]/Human_Resources/vXX.X?wsdl.
Configure the Python Script.
- Copy the provided Python script into a file, for example, extract_h2r.py.
- Update the placeholder variables at the top of the script with your Workday WSDL URL, tenant username (e.g., ISU_user@tenant_name), and password.
Define Extraction Scope.
- In the script, locate the BUSINESS_PROCESS_TYPES list. Verify that it includes all the business process definitions relevant to your Hire-to-Retire cycle. You may need to add or modify names based on your specific Workday configuration.
- Set the START_DATE and END_DATE variables to define the time period for the data extraction.
Execute the Extraction Script.
- Open a terminal or command prompt, navigate to the directory where you saved the script, and run it using the command: python extract_h2r.py.
- The script will connect to the Workday API, iterate through each specified business process type, retrieve the data page by page, and print progress updates to the console.
Process and Map API Responses.
- The script internally parses the complex XML response from the Workday API.
- It identifies key events by looking at the business process status ('Successfully Completed', 'Initiated') and specific step names or completion statuses.
- This logic maps the raw Workday data to the structured event log format with columns like EmployeeId, ActivityName, and EventTimestamp.
Review the Output File.
- Once the script finishes, it will generate a CSV file named workday_h2r_event_log.csv in the same directory.
- Open this file in a spreadsheet program to review the data and ensure it appears correctly structured.
Prepare for ProcessMind Upload.
- The generated CSV file is formatted to be directly compatible with ProcessMind. Ensure the column headers (EmployeeId, ActivityName, EventTimestamp, etc.) match the expected schema for your project.
- Upload the CSV file to your ProcessMind instance to begin your analysis.

Configuration

API Endpoint: The script requires the WSDL URL for the Workday Human Capital Management (HCM) web service. This is tenant-specific and can be found in the 'Public Web Services' report within Workday.
Authentication: The script uses basic authentication with an Integration System User (ISU) and password. Ensure this user has the necessary security permissions for the required API domains.
Business Process Types: The core of the extraction logic relies on a list of business process definitions to query. You must configure this list in the script to match the names used in your Workday instance (e.g., Hire, Onboarding, Change Job, Terminate Employee, Create Job Requisition).
Date Range: The script includes START_DATE and END_DATE parameters. For initial runs, it is recommended to use a smaller range, such as 3-6 months, to manage the data volume and API response times. For production, this can be expanded or scheduled for incremental loads.
Pagination: The script is built to handle large datasets by making paginated API calls. The page size is set to 100 by default, which is a common and safe value to avoid timeouts, but it can be adjusted if needed.

a Sample Query python

import os
import pandas as pd
from zeep import Client, Settings, Transport
from zeep.wsse.username import UsernameToken
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Workday tenant's WSDL URL for Human Resources
WSDL_URL = class="hl-string">'https://[Your_Workday_Tenant_URL]/ccx/service/[Your_Tenant_Name]/Human_Resources/v38.0?wsdl'

class=class="hl-string">"hl-comment"># Replace with your Integration System User (ISU) credentials
TENANT_USERNAME = class="hl-string">'user@tenant'
TENANT_PASSWORD = os.environ.get(class="hl-string">'WORKDAY_PASSWORD') class=class="hl-string">"hl-comment"># Best practice: use environment variables for passwords

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># List of Business Processes to extract data from. Names must match your Workday configuration.
BUSINESS_PROCESS_TYPES = [
    class="hl-string">'Create Job Requisition', 
    class="hl-string">'Job Application', 
    class="hl-string">'Hire', 
    class="hl-string">'Onboarding', 
    class="hl-string">'Performance Review', 
    class="hl-string">'Change Job', 
    class="hl-string">'Terminate Employee'
]

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #
def get_workday_client(wsdl, user, password):
    class="hl-string">"""Initializes the Zeep SOAP client with WS-Security."""
    session = requests.Session()
    session.verify = True class=class="hl-string">"hl-comment"># Or path to your cert bundle
    transport = Transport(session=session)
    settings = Settings(strict=False, xml_huge_tree=True)
    client = Client(wsdl, wsse=UsernameToken(user, password), transport=transport, settings=settings)
    return client

def map_transaction_to_events(transaction):
    class="hl-string">"""Maps a single Workday business process transaction to one or more event log records."""
    events = []
    process_data = transaction.Business_Process_Data
    process_type = process_data.Business_Process.Business_Process_Definition_Name
    process_status = process_data.Status.value
    case_id = process_data.Business_Process.Initiating_Person_Reference.Employee_ID if process_data.Business_Process.Initiating_Person_Reference else None
    subject_employee_id = None
    if process_data.Business_Process.Business_Process_Target_Reference and hasattr(process_data.Business_Process.Business_Process_Target_Reference, class="hl-string">'Employee_ID'):
        subject_employee_id = process_data.Business_Process.Business_Process_Target_Reference.Employee_ID

    class=class="hl-string">"hl-comment"># Default to subject employee, fallback to initiator for processes like Job Requisition
    employee_id = subject_employee_id or case_id
    if not employee_id:
        return [] class=class="hl-string">"hl-comment"># Skip transactions without a clear employee context

    performer = case_id
    department = None class=class="hl-string">"hl-comment"># Placeholder, would require additional API calls to enrich

    class=class="hl-string">"hl-comment"># General process completion events
    if process_status == class="hl-string">'Successfully Completed':
        completion_time = process_data.Status_Date.isoformat()
        activity_map = {
            class="hl-string">'Create Job Requisition': class="hl-string">'Job Requisition Created',
            class="hl-string">'Hire': class="hl-string">'Hire Process Completed',
            class="hl-string">'Onboarding': class="hl-string">'Onboarding Tasks Completed',
            class="hl-string">'Performance Review': class="hl-string">'Performance Review Completed',
            class="hl-string">'Change Job': class="hl-string">'Promotion Approved', class=class="hl-string">"hl-comment"># Assumption: Change Job completion means approval
            class="hl-string">'Terminate Employee': class="hl-string">'Employee Terminated'
        }
        if process_type in activity_map:
            events.append({
                class="hl-string">'EmployeeId': employee_id,
                class="hl-string">'ActivityName': activity_map[process_type],
                class="hl-string">'EventTimestamp': completion_time,
                class="hl-string">'EventEndTime': completion_time,
                class="hl-string">'EventPerformer': performer,
                class="hl-string">'Department': department,
                class="hl-string">'JobRequisitionId': None, class=class="hl-string">"hl-comment"># Requires enrichment
                class="hl-string">'LifecycleEventType': process_type
            })

    class=class="hl-string">"hl-comment"># Step-specific events from the transaction history
    if transaction.Business_Process_Step_Data:
        for step in transaction.Business_Process_Step_Data:
            step_name = step.Step
            step_completion_time = step.Completed_Date.isoformat() if step.Completed_Date else None
            if not step_completion_time: continue

            activity_name = None
            if process_type == class="hl-string">'Job Application' and class="hl-string">'Offer' in step_name and not class="hl-string">'Accept' in step_name:
                activity_name = class="hl-string">'Offer Letter Generated'
            elif process_type == class="hl-string">'Job Application' and class="hl-string">'Accept' in step_name and class="hl-string">'Offer' in step_name:
                activity_name = class="hl-string">'Offer Accepted'
            elif class="hl-string">'Background Check' in step_name and class="hl-string">'Initiate' in step_name:
                activity_name = class="hl-string">'Background Check Initiated'
            elif class="hl-string">'Background Check' in step_name and class="hl-string">'Complete' in step_name:
                activity_name = class="hl-string">'Background Check Completed'
            elif process_type == class="hl-string">'Hire' and class="hl-string">'Initiation' in step.Status.value:
                 class=class="hl-string">"hl-comment"># Onboarding is typically a sub-process or triggered by Hire completion
                events.append({
                    class="hl-string">'EmployeeId': employee_id,
                    class="hl-string">'ActivityName': class="hl-string">'Onboarding Initiated',
                    class="hl-string">'EventTimestamp': step_completion_time,
                    class="hl-string">'EventEndTime': step_completion_time,
                    class="hl-string">'EventPerformer': performer,
                    class="hl-string">'Department': department, class="hl-string">'JobRequisitionId': None, class="hl-string">'LifecycleEventType': class="hl-string">'Onboarding'
                })
            elif process_type == class="hl-string">'Onboarding' and class="hl-string">'Payroll' in step_name and step.Status.value == class="hl-string">'Successfully Completed':
                activity_name = class="hl-string">'Payroll Setup Completed'
            elif process_type == class="hl-string">'Change Job' and class="hl-string">'Initiation' in step.Status.value:
                activity_name = class="hl-string">'Role Change Initiated'
            elif process_type == class="hl-string">'Terminate Employee' and class="hl-string">'Initiation' in step.Status.value:
                activity_name = class="hl-string">'Termination Initiated'
            elif process_type == class="hl-string">'Terminate Employee' and class="hl-string">'Offboarding' in step_name and step.Status.value == class="hl-string">'Successfully Completed':
                activity_name = class="hl-string">'Offboarding Tasks Completed'

            if activity_name:
                events.append({
                    class="hl-string">'EmployeeId': employee_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': step_completion_time,
                    class="hl-string">'EventEndTime': step_completion_time,
                    class="hl-string">'EventPerformer': performer,
                    class="hl-string">'Department': department, class="hl-string">'JobRequisitionId': None, class="hl-string">'LifecycleEventType': process_type
                })
    return events

def main():
    class="hl-string">"""Main function to run the extraction process."""
    if not TENANT_PASSWORD:
        print(class="hl-string">"Error: WORKDAY_PASSWORD environment variable not set.")
        return

    print(class="hl-string">"Initializing Workday SOAP client...")
    client = get_workday_client(WSDL_URL, TENANT_USERNAME, TENANT_PASSWORD)
    factory = client.type_factory(class="hl-string">'ns0')

    all_events = []
    for bp_type_name in BUSINESS_PROCESS_TYPES:
        print(fclass="hl-string">"\nFetching data for business process: {bp_type_name}")
        page = 1
        while True:
            print(fclass="hl-string">"  - Requesting page {page}...")
            request_data = factory.Get_Business_Process_Transactions_RequestType(
                Request_Criteria=factory.Business_Process_Transaction_Request_CriteriaType(
                    Transaction_Date_Range_Data=factory.Transaction_Date_Range_DataType(
                        Effective_From=START_DATE,
                        Effective_To=END_DATE
                    ),
                    Business_Process_Type_Reference=[factory.Business_Process_Type_ReferenceType(
                        Business_Process_Type_Name=bp_type_name
                    )]
                ),
                Response_Filter=factory.Response_FilterType(
                    Page=page,
                    Count=100  class=class="hl-string">"hl-comment"># Page size
                )
            )
            
            try:
                response = client.service.Get_Business_Process_Transactions(request_data)

                if response.Response_Results.Total_Results == 0:
                    print(class="hl-string">"  - No results found for this process type.")
                    break

                if not response.Response_Data or not response.Response_Data.Business_Process_Transactions:
                    print(class="hl-string">"  - Reached end of data.")
                    break
                
                transactions = response.Response_Data.Business_Process_Transactions
                print(fclass="hl-string">"  - Received {len(transactions)} transactions on this page.")

                for trans in transactions:
                    events = map_transaction_to_events(trans)
                    all_events.extend(events)

                if len(transactions) < 100:
                    print(class="hl-string">"  - Last page processed.")
                    break

                page += 1

            except Exception as e:
                print(fclass="hl-string">"An error occurred: {e}")
                break

    if not all_events:
        print(class="hl-string">"\nExtraction complete. No events were generated.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_events)}")
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [class="hl-string">'EmployeeId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'EventPerformer', 
            class="hl-string">'Department', class="hl-string">'JobRequisitionId', class="hl-string">'LifecycleEventType']
    df = df[cols]

    class=class="hl-string">"hl-comment"># Sort by employee and timestamp to create a chronological log
    df.sort_values(by=[class="hl-string">'EmployeeId', class="hl-string">'EventTimestamp'], inplace=True)

    output_filename = class="hl-string">'workday_h2r_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully exported event log to {output_filename}")

if __name__ == class="hl-string">'__main__':
    import requests class=class="hl-string">"hl-comment"># Add requests for the session object
    main()

Data Template: Hire to Retire - Employee Lifecycle

Your Hire to Retire - Employee Lifecycle Data Template

Hire to Retire - Employee Lifecycle Attributes

Hire to Retire - Employee Lifecycle Activities

Extraction Guides

Workday Custom Report with Report-as-a-Service (RaaS)

Steps

Configuration

a Sample Query config

Python Script Extraction via Workday Web Services API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize Your Hire to Retire Employee Lifecycle Today