> 持续流程改进 > 招聘与人才招募 > Workday Recruiting > 数据模板

您的招聘与人才招募数据模板

Workday Recruiting

← 返回改进指南

招聘与人才招募属性(19) 招聘与人才招募活动(15) 数据提取指南(3)

您的招聘与人才招募数据模板

此模板介绍如何收集分析招聘与人才招募流程所需的数据，包括需要收集的关键属性、需要跟踪的重要活动，以及如何从Workday Recruiting系统中提取这些数据。您可以借助此资源简化数据准备工作，加快流程挖掘进程。

建议收集的属性
需要跟踪的关键活动
Workday Recruiting数据提取指南

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

招聘与人才招募属性

建议将这些数据字段纳入事件日志，以便全面分析招聘与人才招募流程，深入了解招聘情况。

3 必填 5 建议填写 11 选填

	名称	说明
	事件时间 EventTime	表示活动或事件发生时间的时间戳。
说明此属性记录具体招聘活动发生的准确日期和时间。时间戳是流程挖掘的基础，可确定事件的先后顺序。分析时，时间戳用于计算活动之间的耗时、衡量“招聘周期”等整体周期时间，并发现流程延误的瓶颈。它是招聘漏斗所有时间分析的必要数据。重要性时间戳对于计算所有基于时间的KPI、了解流程时长和发现瓶颈至关重要。获取途径对应Workday Recruiting中业务流程步骤的完成日期或交易日期。示例 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	活动名称 ActivityName	招聘流程中某个时间点发生的具体事件或任务名称。
说明活动名称描述招聘历程中的单个步骤或里程碑，例如“申请已筛选”“已安排面试”或“已发出录用通知”。这些活动按顺序构成整个流程。此属性对于呈现流程图、识别申请所经过的不同路径，以及分析事件发生频率和顺序至关重要。它是了解流程实际进展的基础。重要性此属性定义招聘流程中的各个步骤，支持流程路径的呈现和分析。获取途径此数据取自Workday Recruiting职位申请数据中的业务流程步骤名称或状态变更。示例申请已筛选面试已完成已接受录用通知候选人未通过
	职位申请 JobApplicationId	职位申请的唯一标识符，是招聘流程的核心案例ID。
说明职位申请ID用于唯一跟踪单个候选人针对特定职位的完整历程，从最初提交申请到最终决策。与该申请相关的每次互动、状态变更和决策节点都会关联到此标识符。在流程挖掘中，此属性至关重要。它可以重建每位候选人的端到端流程路径，支持分析周期时间、瓶颈和实际路径。它是将所有相关活动关联为完整案例的核心要素。重要性这是关联单个候选人所有招聘活动的必要案例ID，可用于分析完整的招聘历程。获取途径此标识符是Workday Recruiting的核心要素，通常可在与职位申请相关的报告和数据源中找到。示例 APP-2023-001234APP-2023-005678APP-2024-009101
	招聘人员姓名 RecruiterName	负责管理职位申请的招聘人员姓名。
说明此属性标识负责该职位申请和职位需求的人才招聘合作伙伴或招聘人员。他们通常负责引导候选人完成招聘流程。按招聘人员分析流程，有助于了解团队绩效和工作量。这项数据可用于构建“招聘人员绩效与处理量”仪表板，并计算“招聘人员发出录用通知耗时差异”等KPI，从而比较效率并发现最佳实践。重要性支持按招聘人员分析绩效，帮助识别表现突出的人员、培训需求和工作量失衡情况。获取途径请参阅Workday Recruiting文档。此属性通常关联到职位需求或职位申请对象。示例约翰·史密斯艾米丽·琼斯玛丽亚·加西亚
	招聘经理 HiringManager	候选人所申请职位的招聘经理姓名。
说明此属性标识有空缺职位的团队或部门经理。招聘经理是招聘决策中的关键相关方，尤其参与面试和反馈环节。此数据对于“招聘经理反馈及时性”仪表板至关重要。按招聘经理分析“面试已完成”到“已提交反馈”之间的耗时，组织可以找出延误，并与相关经理协作，加快招聘流程。重要性对于分析招聘经理的参与情况、发现反馈提交延误至关重要，因为这些因素会直接影响候选人体验。获取途径请参阅Workday Recruiting文档。此信息通常属于主管组织或职位需求详情的一部分。示例苏珊·亚当斯陈大卫安吉拉·罗德里格斯
	求职申请状态 ApplicationStatus	求职申请的最终结果或当前状态。
说明此属性记录求职申请的最终处理结果，例如“已录用”“公司拒绝”“拒绝录用通知”或“候选人撤回”。它表示某份求职申请流程的终止状态。此状态对结果分析至关重要，可用于计算转化率、录用通知接受率，以及各阶段的候选人流失率。了解求职申请在何处以及为何结束，是提升整体流程成效的关键。重要性定义每个案例的结果，是计算转化率、流失率和整体流程成功率的必要依据。获取途径通常是Workday Recruiting中求职申请对象上的最终处理结果或状态原因字段。示例已录用已拒绝拒绝录用通知申请已撤回
	申请来源 ApplicationSource	收到候选人申请的渠道或来源。
说明此属性表示候选人通过何种渠道了解并申请职位，例如公司招聘网站、LinkedIn、员工推荐或招聘机构。了解申请来源对于优化招聘策略和预算至关重要。此数据可用于构建“招聘渠道成效”仪表板和“按来源统计的录用接受率”KPI，帮助您判断哪些渠道带来的候选人数量更多、质量更高。重要性帮助评估不同招聘渠道的成效，为招聘资源投入方向提供数据依据。获取途径请参阅Workday Recruiting文档。这是职位申请中的标准字段。示例 LinkedIn员工推荐公司招聘网站Indeed
	部门 Department	职位需求所属的部门或业务单元。
说明此属性指定招聘候选人所属的组织单元，例如“工程”“市场营销”或“财务”。该信息取自职位需求关联的主管组织。分析时，按部门筛选可以比较企业不同部门的招聘流程。在“申请筛选效率”仪表板中，可借此查看某些部门的筛选时间是否更长，从而发现不同的操作方式或资源需求。重要性支持比较不同业务单元或部门的招聘流程绩效和效率。获取途径请参阅Workday Recruiting文档。此信息取自与职位需求关联的主管组织。示例工程销售人力资源财务
	候选人类型 CandidateType	表示候选人是内部员工还是外部申请人。
说明此属性将候选人分为“内部”或“外部”等类别。两类候选人的招聘流程、时间安排和政策可能存在显著差异。分别分析内部和外部候选人的流程，对于全面了解招聘情况至关重要。这样，组织可以衡量内部人才流动计划与外部招聘工作的效率，并确保两类流程都得到优化。重要性支持分别分析内部和外部招聘流程，这两类流程通常在步骤、服务级别协议和目标方面各不相同。获取途径请查阅Workday Recruiting文档。这是候选人档案或求职申请中的标准字段。示例内部外部
	候选人编号 CandidateId	用于唯一标识候选人的编号。
说明候选人编号用于在招聘系统中唯一标识每个人，无论其申请过多少个职位。借助此编号，您可以跨多份求职申请跟踪候选人与公司的往来记录。此属性有助于分析候选人体验的变化。例如，您可以了解此前被拒绝的候选人是否再次申请，以及其申请历程有何不同；也可以查看同一候选人是否同时在多个职位的考虑范围内。重要性以候选人为中心查看流程，跨多份求职申请并随时间跟踪个人情况。获取途径这是Workday Recruiting中候选人对象的主要标识符。示例 CAND-98765CAND-11223CAND-54321
	工作地点 JobLocation	职位所在的地理位置或国家/地区。
说明此属性指定职位所在的城市、州或国家/地区。远程职位可能标注所属区域，或标记为“远程”。地点是重要的分析维度。您可以比较不同地区的“招聘周期”和其他关键绩效指标，从而发现当地市场状况、人才供给或区域流程差异带来的影响。重要性支持从地理位置维度分析招聘流程，发现各地区在周期时间和效率方面的差异。获取途径此信息属于Workday中的职位申请详情。示例纽约，纽约州英国伦敦远程（US）德国柏林
	录用金额 OfferAmount	向候选人提供的薪资金额。
说明此属性记录职位录用通知中向候选人提出的基本薪资，是招聘流程后期阶段的一项重要数据。分析录用金额有助于了解薪酬趋势和竞争力。结合“已接受录用”状态，可以判断薪酬是否影响录用通知的拒绝率。此属性也是“录用管理与接受率”仪表板的重要组成部分。重要性帮助分析薪酬策略及其对录用通知接受率的影响。获取途径请查阅Workday Recruiting文档。此数据属于“录用”业务流程。示例 8500012000065000
	拒绝原因 RejectionReason	候选人求职申请被拒绝时提供的原因。
说明求职申请状态变为“已拒绝”时，此属性会记录相关决策背景。原因可能包括“不符合企业文化”“缺少所需技能”或“职位已由其他候选人填补”。分析拒绝原因有助于发现招聘流程中的规律。例如，后期阶段因“缺少所需技能”而被拒绝的情况较多，可能说明职位描述不够准确。这些数据对于“候选人流失热点”仪表板至关重要，可帮助您了解候选人流失背后的原因。重要性帮助了解候选人未能进入后续环节的原因，为改进职位描述和筛选标准提供定性参考。获取途径请查阅Workday Recruiting文档。这通常是与拒绝环节关联的子状态或原因代码。示例不符合资格经验不匹配发现更合适的候选人职位已关闭
	招聘周期 TimeToHire	从收到求职申请到候选人入职的总时长。
说明这是按案例计算的指标，用于衡量成功录用候选人的招聘流程总时长。计算方式为“收到求职申请”事件与“候选人已录用”事件之间的时间差。这是招聘领域最重要的关键绩效指标之一，即“平均招聘周期”。它从整体上衡量招聘流程的效率。持续跟踪此指标并按部门进行比较，有助于发现系统性改进或效率下降。重要性这是一项重要的高层级关键绩效指标，用于衡量从开始到结束的整体招聘漏斗效率。获取途径从Workday提取事件日志数据后，即可据此计算。示例 259200043200003456000
	数据最近更新时间 LastDataUpdate	数据最近一次从源系统刷新或提取的时间戳。
说明此属性表示所分析数据的新鲜度，显示最近一次从Workday Recruiting提取数据的日期和时间。这有助于用户了解分析结果的时效性，并正确解读发现：当前查看的是实时数据，还是某个特定时间点的数据快照。重要性提供数据时效性信息，帮助用户了解流程分析数据的更新程度。获取途径此时间戳在数据提取、转换和加载（ETL）过程中生成并添加。示例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	是否已撤回 IsWithdrawn	用于标记求职申请是否由候选人撤回。
说明这是一个计算得出的布尔属性。当求职申请的最终状态为“候选人撤回”或类似状态时，该属性为真。它有助于筛选出候选人主动退出流程的案例。此标记可简化“候选人流失热点”仪表板和“候选人流失率”关键绩效指标的分析。您可以轻松筛选和汇总数据，了解候选人最可能在哪些阶段撤回申请。重要性帮助专门分析由候选人主动退出导致的流失，了解候选人体验和流程阻碍。获取途径数据转换时，根据“求职申请状态”属性计算得出。示例 truefalse
	是否自动执行 IsAutomated	用于标记活动是否由系统自动执行。
说明此布尔属性用于区分步骤由用户执行还是由系统自动执行。例如，系统可能会自动发送“已收到求职申请”的确认邮件。了解哪些步骤已自动化，有助于发现提升效率的机会，也便于评估自动化对周期时间和资源分配的影响。重要性区分人工操作与系统自动执行的活动，便于发现自动化机会并衡量其影响。获取途径需要通过识别系统用户账户或Workday中已知的自动化特定事件类型来获取此信息。示例 truefalse
	源系统 SourceSystem	提取数据的系统。
说明此属性标识数据来源，本例中为Workday Recruiting。它有助于数据治理和问题排查，尤其是在合并多个系统的数据时。在单系统分析中，这项信息看似不起眼，但始终保留来源信息是最佳实践。它可以确认数据的来源；日后集成其他人力资源系统时，这项信息也至关重要。重要性标识数据来源，对于数据治理、验证和管理多源数据至关重要。获取途径这是在数据提取和转换过程中添加的静态值（“Workday Recruiting”）。示例 Workday Recruiting
	职位申请编号 JobRequisitionId	用于唯一标识候选人所申请职位的编号。
说明职位申请编号用于标识已批准的职位。一个职位申请可以关联多份求职申请。此属性支持按职位申请进行分析。例如，您可以分析职位开放的总时长、招募的候选人人数，或比较不同职位类型（如工程类与销售类职位）的招聘漏斗。重要性将多份求职申请关联到同一职位，便于分析职位申请层面的指标和招聘漏斗。获取途径这是Workday Recruiting中职位申请对象的主要标识符，并与每份求职申请相关联。示例 REQ-2023-105REQ-2024-012REQ-2024-345

必填建议填写选填

招聘与人才招募活动

在事件日志中记录这些关键流程步骤和里程碑，有助于准确发现流程并识别招聘工作流中的瓶颈。

7 建议填写 8 选填

	活动	说明
	候选人已录用	表示招聘流程顺利结束，候选人正式成为员工。Workday中的“雇用”业务流程成功完成并创建员工记录时，系统会记录此事件。
重要性这是主要的成功结束事件。其时间戳对于计算招聘周期、衡量整体流程效率和成功率至关重要。获取途径这是Workday HCM中“雇用”业务流程明确记录的重要事件。完成时间戳会保存在流程历史中。采集取自候选人“雇用”业务流程的完成时间戳。事件类型 explicit
	候选人未通过	标记流程未成功结束，即公司决定不再推进该候选人。招聘人员将候选人状态设为“未通过”或“未录用”时，可推断此事件。
重要性这是分析候选人流失集中环节和各阶段淘汰率的重要结束事件，有助于发现面试或筛选流程中的问题。获取途径根据职位申请历史中候选人状态变更为“未通过”时的时间戳推断。系统通常也会记录未通过原因。采集根据候选人状态变更为“未通过”时的生效时间戳得出。事件类型 inferred
	候选人进入录用阶段	这是一个关键里程碑，表示已决定向候选人发出职位录用通知。候选人的申请进入招聘流程中的“录用”阶段时，系统会记录此事件。
重要性此活动是流程中的关键关口，标志着所有评估阶段均已顺利完成。它先于正式发出录用通知，也是进行群组分析的重要节点。获取途径根据职位申请的审计轨迹推断，具体为候选人状态变更为“录用”时的时间戳。采集根据候选人进度中的阶段状态变更为“录用”识别。事件类型 inferred
	候选人进入面试阶段	表示候选人已通过初筛，符合面试条件。招聘人员将候选人转入招聘流程的“面试”阶段时，系统会记录此事件。
重要性这一里程碑标志着流程从初筛转入正式评估，是分析转化率和招聘漏斗前端效率的关键节点。获取途径根据候选人招聘阶段变更为“面试”或职位申请历史中类似阶段时的时间戳推断。采集根据候选人进度中的阶段状态变更为“面试”识别。事件类型 inferred
	已发出录用通知	标记正式向候选人发出职位录用通知。候选人的职位申请成功完成“创建录用通知”或“提出薪酬方案”业务流程时，系统会记录此独立事件。
重要性这是计算录用通知发出周期和分析录用流程一致性的关键里程碑，也是衡量录用接受率的起点。获取途径此事件会明确记录在职位申请的业务流程历史中。创建录用通知步骤的完成时间戳即为活动时间。采集取自“创建录用通知”业务流程的完成时间戳。事件类型 explicit
	已接受录用通知	表示候选人正式接受职位录用通知。候选人在Workday门户中完成“接受录用通知”任务，或招聘人员手动更新状态时，系统会记录此事件。
重要性此活动对于按招聘渠道、部门或招聘人员计算录用接受率至关重要。它还会触发背景调查等后续入职前活动。获取途径候选人通过候选人门户接受录用通知时，系统会明确记录此事件，并在职位申请的业务流程历史中保存操作时间戳。采集取自“接受录用通知”任务的完成时间戳。事件类型 explicit
	收到申请	标记候选人职位申请招聘流程的开始。当候选人通过Workday门户或集成的招聘网站成功提交特定职位申请时，系统会记录此事件。
重要性这是该流程的主要开始事件。分析从此活动到后续里程碑的耗时，是衡量整体招聘周期和招聘渠道成效的基础。获取途径候选人成功完成“申请职位”业务流程时，Workday会将其记录为明确事件。事件时间戳可在候选人的申请历史中查看。采集取自候选人档案中的申请提交时间戳。事件类型 explicit
	已启动入职流程	表示Workday中新员工入职流程已启动。通常这是“雇用”主业务流程中的明确事件，也可能在该流程启动后立即触发。
重要性分析从“已接受录用通知”到此活动的耗时，有助于优化发出录用通知后的候选人体验，确保新员工积极参与并为入职首日做好准备。获取途径 Workday的“入职”业务流程有明确的启动时间戳，可从新员工记录的流程审计轨迹中获取。采集取自“入职”业务流程的启动时间戳。事件类型 explicit
	已启动背景调查	表示已接受录用通知的候选人开始进行背景调查。通常可根据候选人进入“背景调查”阶段来推断，此阶段往往会触发与第三方供应商的集成。
重要性此活动对于监控合规情况、分析接受录用通知到启动入职前检查之间的延误至关重要，有助于确保顺利过渡到入职流程。获取途径根据候选人在招聘流程中进入“背景调查”阶段时的时间戳推断。职位申请的审计轨迹会显示此状态变更。采集根据进入“背景调查”阶段的生效时间戳得出。事件类型 inferred
	已安排面试	表示已正式安排候选人面试。通常在Workday的排期功能中为特定职位申请创建并确认面试事件时记录。
重要性衡量此活动与前序活动之间的耗时，有助于发现协调环节的延误。这对改善候选人体验、加快面试流程至关重要。获取途径 Workday的面试排期功能会创建带有时间戳的事件。可根据与申请关联的已安排面试的创建日期记录此活动。采集取自招聘模块中面试记录的创建事件。事件类型 explicit
	已提交反馈	表示面试官在面试后正式提交候选人评估的时间点。Workday提供专门的功能，供面试官直接在候选人档案中提交反馈。
重要性这是分析“招聘经理反馈及时性”的关键环节。此处的延误是常见瓶颈，跟踪该环节有助于落实服务级别协议。获取途径通过“提供面试反馈”任务提交反馈时，系统会记录此明确事件。提交时间戳会关联到面试记录。采集取自“提供面试反馈”事件的完成时间戳。事件类型 explicit
	申请已撤回	表示候选人主动退出职位申请流程。候选人本人或招聘人员将其状态更新为“已撤回”时，系统会记录此事件。
重要性跟踪候选人撤回申请的时间和原因，对于了解候选人体验问题、流程时长或录用条件的竞争力至关重要，也是分析候选人流失的关键指标。获取途径根据候选人状态更新为“已撤回”时的时间戳推断。候选人可在门户中自行操作，招聘人员也可代为更新。采集根据候选人状态变更为“已撤回”时的生效时间戳得出。事件类型 inferred
	申请已筛选	表示招聘人员或筛选团队已完成对候选人申请的初步审核。通常可根据候选人状态从“已申请”或“新申请”变为“筛选中”或“审核中”来推断此事件。
重要性此活动对于分析初筛阶段的效率至关重要。跟踪处理量和耗时有助于及早发现招聘漏斗中的瓶颈。获取途径根据“招聘”业务流程审计轨迹中候选人阶段变更为筛选或审核环节的生效日期推断。采集根据候选人阶段更新为“筛选”时的时间戳得出。事件类型 inferred
	背景调查已通过	标记背景调查已顺利完成。候选人状态更新为通过必要检查并符合录用条件时，可推断此事件。
重要性这是完成招聘流程前的最后一道检查。收到并记录调查通过结果的延误，可能会推迟候选人的入职日期。获取途径根据候选人申请的状态更新推断，例如进入“可录用”或“背景调查完成”阶段。采集根据表明背景调查已完成且通过的状态变更得出。事件类型 inferred
	面试已完成	标记与候选人安排的面试已结束。通常可根据面试官或招聘人员将面试状态从“已安排”更新为“已完成”或“已进行”来推断。
重要性此活动标志着反馈提交时限的开始。分析从此时到提交反馈的耗时，是衡量招聘经理响应速度的关键。获取途径根据面试结束后Workday Recruiting中已安排面试对象的状态更新，或候选人阶段的手动变更推断。采集根据面试状态更新或面试后候选人阶段变更的时间戳得出。事件类型 inferred

建议填写选填

数据提取指南

如何从Workday Recruiting获取数据

步骤

登录Workday：使用具备创建自定义报告和访问招聘数据权限的用户账户登录Workday环境。
创建自定义报告：进入“Create Custom Report”任务。将报告类型设为“Advanced”，并启用“Enable as Web Service”选项。为提升性能，数据源请选择“All Job Applications”等已建立索引的数据源。
定义主要业务对象：将主要业务对象设为“Job Application”。该对象将作为报告的基础和案例标识符。
添加数据列：在报告列网格中添加所需字段和建议字段。为JobApplicationId添加“Job Application”字段。对于“Recruiter”和“Hiring Manager”等其他属性，需从与Job Application关联的业务对象中添加。
为活动创建计算字段：这是最关键的一步。针对15项活动中的每一项，创建两个计算字段：一个用于活动名称，另一个用于事件时间戳。查询部分详细说明了字段逻辑。例如，要记录“Offer Extended”，需创建一个字段，用于检查“Propose Compensation”业务流程是否已完成；另一个字段则提取该流程的完成时间戳。
将计算字段添加到报告：将所有新建的计算字段（共30个，15个活动名称字段和15个时间戳字段）添加为报告列。报告采用“宽表”格式，每个职位申请占一行，多列分别表示可能发生的活动。
配置Web服务选项：在报告定义的“Web Service”选项卡中，确认已勾选“Enable as Web Service”。您可以在此查看报告的命名空间和URL，并记下“Namespace”以供后续使用。
设置权限：将报告共享给用于调用RaaS端点的集成系统用户（ISU）或指定安全组。该用户必须有权访问数据源所属的安全域，例如“Recruiting: Job Applications”。
运行并测试报告：在Workday界面中运行报告，检查输出结果。确认行数合理，并抽查几个职位申请，确保计算字段已正确填充。
安排数据提取：使用外部调度工具或中间件（如MuleSoft、Boomi或自定义脚本）定期调用报告的RaaS URL。该工具需通过适当的身份验证处理Workday SOAP或REST API调用。
转换数据：RaaS调用的原始输出为宽表XML或CSV文件。您必须在中间件或脚本语言（如Python）中执行转换，将宽表转成长表。脚本应遍历每一行（职位申请），为每组非空的活动和时间戳创建一条事件日志记录，最终生成包含三个主要列的长表：JobApplicationId、ActivityName和EventTime。

配置

报告类型：始终选择“Advanced”，以支持复杂的计算字段并访问相关业务对象。
数据源：选择“All Job Applications”等已建立索引的数据源，确保报告高效运行。大型数据集应避免使用未建立索引的数据源。
日期范围筛选：务必按Job Application业务对象中的“Application Date”字段筛选。建议先选取较短的时间范围，例如最近3至6个月，以控制数据量并保障报告性能。
主要业务对象：主要对象必须设为“Job Application”，以确保JobApplicationId作为案例标识符。
启用Web服务：必须在报告配置中勾选“Enable as Web Service”，才能通过API访问报告。
安全与权限：报告必须共享给专用的集成系统用户（ISU）。该用户所属安全组必须有权访问所需数据域，包括“Recruiting: Job Applications”、“Business Process Transactions”和“Worker Data”。
输出格式：Workday支持多种输出格式（XML、CSV、JSON），但通过API提取结构化数据时，XML（尤其是“Simple XML”格式）通常最可靠。

查询示例 sql

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.

步骤

配置Workday访问权限：在Workday中创建集成系统用户（ISU），并授予其访问Recruiting API所需安全域的权限。主要安全域包括“Worker Data: Public Worker Reports”、“Job Application”和“Recruiting: Reports”。
查找API端点：在您的Workday环境中找到“Get Job Applications”操作对应的REST API端点。URL通常采用以下格式：https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications。
设置Python环境：确保已安装Python。使用pip安装所需库：pip install requests pandas。
编写身份验证脚本：在Python脚本中，使用第1步创建的ISU凭据实现基本身份验证。用户名和密码将通过请求标头发送。
编写API请求逻辑：编写调用“Get Job Applications”端点的函数。使用请求参数筛选数据，例如通过updatedSince获取某个日期之后修改的职位申请。这对控制数据量至关重要。
处理API分页：Workday API每次请求返回的记录数有限。脚本必须检查响应中的total计数以及下一页链接或偏移参数，并循环请求所有页面以获取完整数据集。
定义活动映射：在脚本中创建映射字典或一系列条件语句，将Workday业务流程状态和招聘阶段（如“Screen”“Interview”“Offer”“Hire”）转换为所需的活动名称（如“Application Screened”“Candidate Moved To Interview”）。
转换职位申请数据：对从API获取的每份职位申请，解析其审计轨迹或阶段历史记录。这些历史记录包含各阶段、处理结果和业务流程事件的顺序及对应时间戳。
生成事件日志行：遍历每份职位申请的历史记录。对于符合活动映射的相关历史事件，创建一个字典，作为最终事件日志中的一行。填入JobApplicationId、ActivityName、EventTime及其他必需属性。
汇总并整理数据：将所有职位申请生成的事件日志行汇总到一个列表中。
创建并导出CSV文件：使用pandas库将事件字典列表转换为DataFrame，再导出为CSV文件。确保列标题符合ProcessMind的要求，例如CaseId、Activity和Timestamp。
检查并上传：打开最终CSV文件，检查内容是否准确、完整，然后上传至流程挖掘工具。

配置

Workday集成系统用户（ISU）：需要一个密码强度高且永不过期的ISU账户。该账户须拥有“Recruiting”和“Worker Data”安全域的权限，以访问职位申请和候选人详情。
API端点和版本：必须使用与您的Workday环境对应的REST API端点。请在请求中指定API版本，以确保行为一致。
日期范围筛选：脚本应使用日期筛选条件（例如updatedSince）将查询范围控制在合理时间段内。首次提取建议选择3至6个月；后续增量加载则使用上次成功提取的时间戳。
分页限制：请留意API中的limit参数，它决定每页返回的记录数。通常最大值为100。脚本必须通过多次分页请求处理这一限制。
响应字段：如果API支持fields或类似参数，可指定返回字段以提升性能，减少API响应数据量。
活动映射配置：脚本的核心逻辑是将Workday阶段映射为定义好的活动。您可能需要根据组织的Workday招聘流程配置进行调整。

查询示例 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.")

步骤

前提条件与设置：确保您已获授权使用CData、MuleSoft或类似第三方ETL或iPaaS工具，并已安装其Workday连接器。确认您拥有Workday集成系统用户（ISU）的凭据，且该用户具备访问Recruiting和Staffing域所需的API权限。
配置Workday连接：在ETL工具中创建新的Workday连接。填写Workday环境URL、API版本和ISU凭据，例如用户名和密码或OAuth 2.0令牌。测试连接，确认连接成功。
查看数据架构：使用ETL工具中的架构浏览器或数据源浏览器，查看连接器可访问的Workday对象。这些对象通常以表或视图的形式呈现，例如Job_Application、Job_Requisition和Candidate_Stage_History。熟悉可用字段及其关系。
确定关键数据对象：此次提取主要需要职位申请、候选人历史记录、面试、录用通知和录用相关对象的数据。具体名称取决于连接器，请查找代表这些核心实体的对象。
编写SQL查询：创建新的数据提取作业或管道。使用SQL转换步骤，对Workday连接运行查询。将提供的SQL查询复制并粘贴到该步骤中。此查询用于从多个Workday对象收集数据，并将其合并为统一的事件日志格式。
为查询设置参数：修改查询的WHERE子句，加入日期范围参数，例如startDate和endDate。在ETL作业中配置这些参数，以便调整提取时间范围，而无需修改代码。
执行提取作业：运行配置好的ETL作业。工具将连接Workday，通过API执行SQL查询，并将数据提取到暂存区或内存中。
检查并验证数据：写入最终输出前，使用ETL工具的预览功能检查结果。确认行数合理、各列按预期填充，并核实包含不同活动的数据。
配置目标位置：指定提取数据的目标位置，通常是供ProcessMind上传的CSV文件。配置文件名、分隔符（逗号）和编码（UTF-8）。
完成并导出：运行完整提取作业，生成最终CSV文件。确保输出文件的列标题符合所需属性：JobApplicationId、ActivityName、EventTime、RecruiterName、HiringManager、ApplicationSource、Department和ApplicationStatus。

配置

Workday连接器凭据：连接需要Workday环境URL，以及经授权的集成系统用户（ISU）和密码或OAuth 2.0客户端凭据。该用户必须拥有“Recruiting”和“Staffing”职能领域的安全权限。
启用Web服务：连接器可能要求您指定要公开的Workday Web服务。请启用与Recruiting、Staffing和Human Resources相关的服务，以访问所有必需的数据对象。
日期范围：为控制性能和数据量，必须按特定时间范围筛选提取数据。建议首次加载3至6个月的数据，之后每天或每周增量加载。通过SQL查询中的WHERE子句进行筛选。
数据范围筛选：如果只需分析组织中特定部分的流程，可在WHERE子句中添加Company、Cost Center或Supervisory Organization等字段的筛选条件。
API版本：某些连接器要求您指定Workday API版本。建议使用较新且受支持的版本，以访问最新的数据对象和功能。
性能注意事项：从Workday完整提取数据可能占用大量资源。请在非高峰时段安排大型作业。持续分析时，可根据“上次修改”时间戳实施增量加载策略，仅提取新增或更新的记录。

查询示例 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]'

准备好开始了吗？

使用此模板，将人才招募数据转化为可执行的洞察，提升招聘效率。立即开始，打造更顺畅、更有效的招聘流程。

返回改进指南

下载模板

消除招聘瓶颈：立即优化人才招聘流程

找出低效环节，将招聘周期缩短30%，更快实现人才目标。

开始免费试用

无需信用卡。免费试用14天。

您的招聘与人才招募数据模板

您的招聘与人才招募数据模板

招聘与人才招募属性

招聘与人才招募活动

数据提取指南

通过Workday Report-as-a-Service（RaaS）提取数据

步骤

配置

查询示例 sql

通过Python脚本提取Workday招聘API数据

步骤

配置

查询示例 python

使用Workday连接器通过ETL工具提取数据

步骤

配置

查询示例 sql

准备好开始了吗？

消除招聘瓶颈：立即优化人才招聘流程