> 持续流程改进 > 入职到退休——职位管理 > Workday HCM > 数据模板

您的入职到退休 — 岗位管理数据模板

Workday HCM

入职到退休——职位管理属性 (22) 入职到退休——职位管理活动 (13) 提取指南 (3)

您的入职到退休 — 岗位管理数据模板

此模板为您收集分析“从入职到离职 - 职位管理”流程所需的核心 data 提供了清晰的路线图。它概述了需要收集的关键属性、要跟踪的核心活动，以及从 Workday HCM 提取这些信息的实用指南。利用此资源确保您的 event 日志完整无误，为强大的 Process Mining 洞察做好准备。

建议收集的属性
需要追踪的关键活动
提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

入职到退休——职位管理属性

这些是建议包含在您的 event 日志中的 data 字段，用于全面的“从入职到离职 - 职位管理”分析。

3 必填 7 推荐 12 可选

	名称	描述
	岗位ID PositionId	组织内特定职位的唯一标识符，作为职位管理流程的主要 case 标识符。
描述职位 ID（Position ID）是职位管理流程分析的基石。每个 ID 代表一个职位的完整生命周期，从初始申请和创建到任何修改、重新分类，以及最终的停用或关闭。在 Process Mining 中，此属性用于将所有相关 activity（如审批、data 变更和状态更新）关联到特定的 case。这实现了对职位历程的端到端完整视角，从而可以分析周期时间、识别流程变体并跟踪每个唯一职位的合规性。为何重要这对于追踪职位的整个生命周期至关重要，可实现端到端的流程分析，并有助于识别特定案例的瓶颈或偏差。获取方式这是 Workday HCM 中的核心标识符，通常可在与人员配置和职位管理相关的报告和业务流程 data 中找到。示例 POS-0012345POS-0067890POS-0112233
	Event 时间 EventTime	指示特定活动或事件发生时间的时间戳。
描述 Event Time 是一个精确的 timestamp，记录了流程中每个 activity 的日期和时间。此 data 对于任何基于时间的分析都至关重要，包括计算周期时间、等待时间和持续时间。在 Process Mining 中，此 timestamp 用于按时间顺序排列 event，形成构成流程流的 activity 序列。它是绩效诊断的基础，支持识别瓶颈、分析吞吐量以及监控 SLA。为何重要这对于事件排序、计算周期时间和时长等所有基于时间的指标以及诊断流程瓶颈至关重要。获取方式 Workday HCM 中的每个业务流程事务都会自动记录此 timestamp。示例 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z
	活动名称 ActivityName	发生的特定业务流程步骤或 event 的名称，例如“职位已创建”或“预算已批准”。
描述 Activity Name 描述了职位管理生命周期中的单个步骤。这些 event 是流程图的基石，展示了每个职位的操作序列。通过分析这些 activity，可以实现流程流的可视化，识别常见和罕见的路径，并衡量关键里程碑之间花费的时间。示例包括“职位申请已发起”、“职位属性已修改”和“职位已关闭”，它们共同构成了运营流的图景。为何重要此属性是构建流程图、流程流可视化以及识别导致延迟或重工的特定 event 的基础。获取方式从 Workday 的业务流程框架事务日志中提取。业务流程定义中的每个步骤都会生成一条事件记录。示例职位申请已发起经理审批已提交职位已创建职位已停用
	变更原因 ReasonForChange	为变更 event 提供的理由，例如职位的重新分类、修改或关闭。
描述此属性捕获了对职位进行特定变更的业务正当理由。为了确保一致性，通常从 Workday 的预定义列表中选择原因，如“组织重组”、“新项目”或“预算调整”。分析此属性为流程流提供了极其宝贵的背景信息。它有助于回答“是什么”背后的“为什么”，例如，通过将重新分类 event 与特定原因相关联，以识别组织重组或角色演变的趋势。为何重要解释修改和重新分类等流程活动背后的业务背景，有助于分析流程变异的根本原因。获取方式这是 Workday 中许多业务流程事务（如“编辑职位限制”或“关闭职位”）的必填字段。示例新部门创建组织重组数据更正项目结项
	成本中心 CostCenter	与职位相关的财务成本中心，用于预算和财务报告。
描述成本中心（Cost Center）是一个财务维度，将职位与特定预算挂钩。它对于跟踪成本和确保人员配置符合财务计划至关重要。在 Process Mining 中，此属性对于预算审批和财务影响相关的分析至关重要。它有助于了解不同成本中心的预算审批时间差异，并将职位管理活动与财务结果相关联。这也是在类似财务单位之间实现角色属性标准化的关键。为何重要为分析提供财务维度，支持按预算单位查看流程，并辅助进行与预算相关的瓶颈分析。获取方式这是 Workday HCM 中分配给职位的财务或“工作标签”（Worktags）信息的一部分。示例 CC4010_市场营销CC2050_RD_软件研发CC7000_行政管理
	用户 User	执行该活动的人员的用户 ID 或姓名。
描述此属性识别负责完成流程中特定 task 的员工或系统用户，例如提交审批或修改职位属性。这可能是经理、HR 伙伴或财务分析师。按用户分析 data 有助于识别培训机会、工作负载分配不平衡以及个人绩效差异。例如，它可以精准锁定哪些用户最频繁地参与重工 activity，从而提示需要更清晰的指令或系统改进。为何重要支持对工作负载分布和特定用户行为进行分析，并识别培训需求或表现优异的个人。获取方式可在 Workday 的业务流程事务日志中查看，该日志记录了每个步骤的发起者或参与者。示例 jsmithdavis_janehr_admin_svc
	结束时间 EndTime	指示 activity 完成时间的 timestamp。用于计算单个 activity 的持续时间。
描述 End Time 标记特定 activity 的完成。Start Time 显示 event 发生的时刻，而结合 Start Time 和 End Time 则可以计算该 event 的 Processing Time。这对于非瞬时完成的 activity（如合规审查步骤）特别有用。通过将一个 activity 的 End Time 与下一个 activity 的 Start Time 进行比较，可以精确衡量 Processing Time 和等待时间，从而提供对流程效率的深度洞察。为何重要这对于计算活动的精确时长非常必要，有助于区分实际处理时间与空闲等待时间。获取方式某些 Workday 业务流程步骤可能有明确的开始和结束时间。如果没有，可以将其推导为同一 case 中后续 event 的 Start Time。示例 2023-04-15T09:05:12Z2023-04-15T17:00:00Z2023-04-18T11:21:55Z
	职位状态 PositionStatus	职位的当前或历史状态，例如“开放”、“已填补”、“冻结”或“已关闭”。
描述职位状态（Position Status）显示了职位在特定时间点的状态。此属性对于了解职位的当前可用性和生命周期阶段至关重要。在分析中，按状态过滤有助于专注于流程的特定部分。例如，分析处于“冻结”状态的职位有助于创建账龄报告，以查看资源被占用了多久。跟踪状态之间的转换是理解流程流的关键。为何重要提供关于职位状态的关键上下文，支持冻结职位账龄分析并跟踪生命周期进程。获取方式作为 Workday HCM 中职位对象上的标准字段提供。示例开放 - 已批准已填补已冻结已结案
	职务族 JobFamily	具有相似特征、技能和工作内容的工作分组，例如“工程”或“人力资源”。
描述职务族 (Job Family) 是将相关的职务概况进行分组的分类方式。例如，“软件工程师”和“高级软件工程师”职务概况可能都属于“工程”职务族。这提供了一种在更高层级对角色进行分类和分析的方法。此属性支持诸如监控重新分类或标准化职位属性之类的分析。通过分析职务族内部或跨职务族的变化，组织可以洞察职业路径、角色定义的一致性以及劳动力趋势。为何重要支持对角色进行更高层级的分析，助力标准化工作以及对相关职类之间重新分类的分析。获取方式这是 Workday HCM 职位目录结构的一部分，与职位的职位描述相关联。示例信息技术财务与会计销售专业人员
	部门 Department	职位所属的部门或管理组织。
描述部门属性（在 Workday 术语中通常称为“管理组织”）为职位提供主要的组织上下文。它定义了职位所在的团队或业务领域。这是一个关键的分析维度，支持不同业务部门之间的绩效对比。例如，您可以比较工程部和市场部的新职位审批周期，从而确定最佳实践或局部瓶颈。为何重要允许按不同组织单位筛选并比较流程绩效，揭示特定部门的瓶颈或效率表现。获取方式通过分配给 Workday HCM 中的管理组织与职位相关联。示例销售部 - 北美工程部 - 平台开发财务部 - 企业 FP&A
	业务单元 BusinessUnit	职位所属的高级业务部门或单元，例如“消费品”或“企业解决方案”。
描述业务单元（Business Unit）代表公司的主要板块，在组织层级上高于部门。它用于高层战略和财务报告。按业务单元分析职位管理流程可以提供劳动力动态的战略视角。它可以突出主要公司部门在招聘速度、重新分类率或流程效率方面的差异，从而在宏观层面让领导层了解运营差距。为何重要支持对公司主要部门的流程绩效进行高层级的战略分析，为高管决策提供信息。获取方式这通常在 Workday 中作为“工作标签”实施，可以分配给职位或其相关的成本中心。示例消费品企业解决方案企业服务
	最后数据更新 LastDataUpdate	指示 data 上次从源系统提取并在 Process Mining 工具中刷新的 timestamp。
描述此属性提供最新 data 刷新的 timestamp。它本身不是流程 data 的一部分，而是关于数据集新鲜度的元数据。这对于分析的所有用户都很重要，因为它告诉他们 data 的时效性。它有助于了解洞察是反映了最新的运营状态，还是基于稍旧的快照，从而管理对研究结果及时性的预期。为何重要告知用户数据的实时性，确保他们了解流程分析和洞察的时效性。获取方式此 timestamp 由 data 管道或 ETL 工具在 data 加载过程结束时生成。示例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	合规状态 ComplianceStatus	表示合规性审查步骤的结果，例如“合规”或“不合规”。
描述此属性捕获正式“职位合规性已审查” activity 的结果。它确认职位的属性、审批历史或正当理由是否符合内部政策或外部法规。这是“职位操作合规概览”仪表板的关键属性。它支持对合规率进行直接监控，并帮助审计人员或 HR 团队快速识别并调查被标记为违规的职位，从而实现纠正行动和风险缓解。为何重要直接衡量合规检查的结果，实现对政策遵循情况的监控，并标记高风险案例以供审查。获取方式这可能是 Workday 业务流程中某个特定的、已配置步骤的输出。它可能以注释或自定义字段的形式存储。示例合规不合规需要后续跟进
	地点 Location	与职位相关的物理或逻辑工作地点。
描述地点属性指定职位所在的地理站点或办公室。其范围可以从具体的建筑物地址到更广泛的国家或地区，也可以包含“远程”作为取值。按地点进行分析可以揭示流程绩效的区域差异，例如审批时间或合规率的变化。它有助于了解流程是否在全球范围内实现了标准化，或者局部做法是否造成了偏差。为何重要支持地理维度分析，以识别区域流程差异、合规性变化或特定地点的瓶颈。获取方式可以在 Workday HCM 中分配给职位的标准属性。示例美国纽约英国伦敦远程办公（德国）
	处理时间 ProcessingTime	单个 activity 的持续时间，计算方法为结束时间与开始时间之差。
描述 Processing Time 衡量的是实际处理 task 的时间，而不是 task 之间的等待时间。计算方法是从 activity 的 Start Time 中减去其 End Time。该指标是绩效分析的基础。它有助于识别流程中哪些特定步骤最耗时。例如，“预算已批准”的 Processing Time 过长可能意味着评审流程复杂，而之前的等待时间过长则表明申请正处于排队中。为何重要量化 activity 的实际工作时长，有助于区分活跃工作与闲置等待时间，并精准锁定低效步骤。获取方式计算字段，派生自 EventTime (StartTime) 和 EndTime 属性 (EndTime - StartTime)。示例 PT8H30M2天4小时PT15M
	新职位审批时长 NewPositionApprovalCycleTime	从发起职位申请到在系统中创建职位所花费的总时间。
描述此属性衡量新职位审批流程的端到端周期时间。计算方法为给定职位 ID 的“职位申请已发起” event 与“职位已创建” event 之间的时长。这直接支持“平均新职位审批周期时间”KPI 和相关仪表板。通过在 case 级别进行计算，您可以分析周期时间的分布，识别异常值，并调查与较长或较短审批时长相关的因素（如部门或职位类型）。为何重要直接衡量关键绩效指标，支持对审批效率的分析，并识别导致延迟的因素。获取方式通过查找特定开始活动和结束活动之间的时间差，在流程挖掘工具的案例层级进行计算。示例 5天6小时12天P2DT12H30M
	是否已进行合规审查 IsComplianceReviewed	一个布尔值标记。如果案例中已发生“职位合规性已审查”活动，则该标记为 true。
描述此标记指示职位在其生命周期的任何时间点是否经历过正式的合规性审查。它是通过检查给定职位 ID 是否存在“职位合规性已审查” activity 来确定的。此属性简化了合规性监控和 KPI 计算。它支持对所有已审查或未审查的 case 进行轻松过滤，并通过简化合规人数的统计，直接支持“职位操作合规率”KPI 的计算。为何重要简化合规率的衡量，并支持轻松过滤，以隔离和分析绕过必要审查的职位。获取方式这是一个派生标记，在 case 级别计算。如果 case 日志中存在“职位合规性已审查” activity，则将其设为 true。示例 truefalse
	是否返工 IsRework	一个布尔值标记。如果某项活动被视为返工（例如多次修改职位属性），则该标记为 true。
描述 Is Rework 标记识别代表更正或重复工作的 activity，这通常表明流程效率低下或存在质量问题。对于在创建后不久发生或在一个序列中多次发生的 event（如“职位属性已修改”），通常将其设为 true。此计算属性对于“职位 data 重工分析”仪表板至关重要。它支持轻松量化重工率，通过分析被标记 event 的上下文来帮助识别根本原因，并支持诸如“职位 data 重工率”之类的 KPI。为何重要直接标记低效的返工活动，使其易于量化、分析，并针对性地开展流程改进工作以减少浪费。获取方式这是一个派生标记，基于 activity 的顺序和频率计算。例如，如果同一 case 多次出现“职位属性已修改”，则将其设为 true。示例 truefalse
	源系统 SourceSystem	data 来源系统，在本案例中为 Workday HCM。
描述此属性识别生成职位管理流程 data 的源应用程序。虽然对于此次特定分析，来源始终是 Workday HCM，但在可能从多个系统合并 data 的企业环境中，这是一个至关重要的字段。包含此属性可确保 data 血缘清晰，并有助于区分可能跨越不同平台的流程。它提供了背景信息，是 data 治理的最佳实践。为何重要提供关于 data 来源的关键上下文，确保多系统环境下的清晰度，并支持 data 治理标准。获取方式这通常是在 data 提取和转换过程中添加的静态值（“Workday HCM”）。示例 Workday HCMWorkdayHCM_Prod
	职位名称 PositionTitle	职位的具体名称，例如“高级财务分析师”或“首席软件工程师”。
描述职衔（Position Title）是角色面向用户的正式名称。它比职系（Job Family）或职位描述（Job Profile）更具细粒度，通常出现在招聘启事或组织架构图中。分析此属性对于了解职位变更的细节非常重要。例如，在重新分类分析中，您可以查看职衔是否发生了重大变化。它还用于标准化仪表板，以检查不同部门之间类似角色的命名一致性。为何重要提供关于角色的细粒度详情，这对于分析重新分类和角色标准化至关重要。获取方式 Workday HCM 中职位对象上的标准字段。示例高级产品经理高级 HR 业务伙伴初级会计师
	职位类型 PositionType	根据雇佣条款对职位进行分类，如全职、兼职或承包商。
描述职位类型（在 Workday 中通常称为“员工类型”或“时间类型”）对与该职位相关的雇用性质进行分类。这是劳动力规划和管理的基础属性。在 Process Mining 中，这一维度支持对比不同类型员工的职位管理流程。例如，您可以调查外部顾问的审批流程是否比全职员工更快或更简单，从而发现流程优化的机会。为何重要允许比较不同员工类别（如全职与承包商）的职位管理流程，以寻找优化机会。获取方式作为职位定义的一部分提供，通常为“员工类型”或“时间类型”。示例正式全职正式兼职定期合同工
	职务概况 JobProfile	工作的标准化模板，定义了其核心特征，如职责和任职资格。
描述职位描述（Job Profile）是 Workday 职位架构的基础元素。它作为一个模板定义了一项工作，包括其默认职衔、任职资格和薪酬等级。职位是特定部门内职位描述的一个实例。此属性是理解流程标准化的关键。按职位描述分析流程可以揭示某些类型的角色是否具有更长的审批周期，或者更容易发生重工。它对于跟踪职位从一个职位描述转移到另一个职位描述的重新分类也至关重要。为何重要将职位链接到标准工作模板，从而能够基于标准化的角色特征对流程变异进行分析。获取方式 Workday HCM 中每个职位的必填字段。它是用人数据模型的核心部分。示例 JP-财务-分析3JP-工程-开发5JP-HR-通才2

必填推荐可选

入职到退休——职位管理活动

这些是在您的 event 日志中捕获的关键流程步骤和里程碑，用于在“从入职到离职 - 职位管理”中进行准确的流程发现。

6 推荐 7 可选

	活动	描述
	职位属性已修改	表示现有职位的一个或多个属性（如职称或部门）已发生更改。当用户成功完成“编辑职位限制”业务流程时，会明确记录此信息。
为何重要频繁修改可能预示着数据输入错误、工作职责演变或流程效率低下。分析此活动是“职位数据返工分析”仪表板以及提高数据质量的关键。获取方式这捕获自 Workday 的“编辑职位限制”或类似业务流程的完成日志。审计轨迹显示了哪些字段发生了变更。捕获 “编辑职位限制”业务流程成功完成时记录的事件。事件类型 explicit
	职位已停用	表示职位不再处于活动状态且无法填补，通常是正式关闭前的初步步骤。这是在完成“停用职位”业务流程时捕获的显性事件。
为何重要停用是职位生命周期中的一个关键里程碑，与最终关闭不同。停用与关闭之间的时间是衡量清理组织结构行政效率的一个指标。获取方式此 event 在“失效职位”业务流程成功完成时记录在 Workday 的审计日志中。捕获 “停用职位”业务流程成功完成时记录的事件。事件类型 explicit
	职位已关闭	这是生命周期中的最后一个 activity，代表从组织中永久取消该职位。Workday 在“关闭职位”业务流程成功完成时记录此 event。
为何重要作为大多数案例的终结事件，此活动定义了职位生命周期的结束。这对于了解完整流程时长以及保持准确的人头数 (headcount) 数据至关重要。获取方式从 Workday 审计跟踪或业务流程日志中“关闭职位”业务流程的完成时间戳捕获。捕获 “关闭职位”业务流程完成时记录的事件。事件类型 explicit
	职位已创建	此 activity 标志着职位在 Workday 系统中成功创建并正式存在。它在“创建职位”业务流程成功完成时记录。
为何重要这是一个关键里程碑，标志着审批阶段的结束以及职位已准备好进行人员配置。它对于衡量整体审批周期时间 KPI 至关重要。获取方式该 event 捕获自 Workday event 日志或审计轨迹中“创建职位”业务流程的完成 timestamp。捕获 “创建职位”业务流程成功完成时记录的事件。事件类型 explicit
	职位申请已发起	这标志着职位管理生命周期的开始，即正式提交创建新职位的申请。当用户在 Workday 中启动“创建职位”业务流程时，这将被捕获为一个明确的 event。
为何重要此 activity 是流程的主要开始 event。分析从该 event 到后续审批的时间对于衡量整个职位创建周期的效率至关重要。获取方式此 event 记录在 Workday 业务流程 event 日志中。请查找特定职位 ID 的“创建职位”业务流程事务的发起 timestamp。捕获 “创建职位”业务流程发起时记录的事件。事件类型 explicit
	预算已批准	这是一个关键里程碑，即财务部门或预算经理确认新职位有可用资金。当指定的审批人在业务流程流中完成预算审批步骤时，该信息会被捕获。
为何重要预算审批通常是一个主要的瓶颈。衡量这一特定活动的周期时间有助于组织精简财务审核并加快招聘速度。获取方式这记录在 Workday “创建职位”业务流程的审计历史中。它对应于预算审批步骤的完成 event。捕获业务流程日志中财务或预算审批步骤的完成时间戳。事件类型 explicit
	HR 审批已提交	表示 HR 伙伴或代表已审查并批准了职位申请。当 HR 审批人在 Workday 业务流程中完成其分配的步骤时，会明确记录此信息。
为何重要此审批是确保职位符合公司政策和职位架构的关键检查点。此处的延迟会显著影响整体周期时间。获取方式源自相关业务流程的 Workday 审计轨迹。该 event 为“HR 审批”步骤的完成。捕获业务流程日志中 HR 审批步骤的完成时间戳。事件类型 explicit
	经理审批已提交	代表招聘经理或管理组织经理完成评审和审批步骤。Workday 将其捕获为“创建职位”业务流程中审批步骤的一个独立完成 event。
为何重要这是一个常见的早期里程碑和潜在瓶颈。跟踪此审批花费的时间有助于识别职位创建工作流初始阶段的延迟。获取方式从“创建职位”业务流程的审计跟踪中捕获。它对应于特定“经理审批”步骤的完成。捕获业务流程日志中经理审批步骤的完成时间戳。事件类型 explicit
	职位合规性已审查	表示职位已进行正式合规检查，例如针对内部政策或外部法规的检查。这通常作为父级业务流程中的特定“待办事项”或“检查清单”步骤被捕获。
为何重要跟踪合规性审查对于降低风险并确保符合组织标准至关重要。此项活动直接支持“岗位变动合规率”这一 KPI。获取方式这可能被捕获为业务流程（如“创建职位”或“编辑职位”）中已完成的“待办”步骤或特定的审批步骤。需要进行系统分析以确认确切机制。捕获业务流程日志中合规相关审批或“待办”步骤的完成时间戳。事件类型 explicit
	职位已冻结	代表临时暂停职位的操作，防止其被填补。当用户在 Workday 中成功完成“冻结职位”业务流程时，将捕获此项。
为何重要此 activity 对于管理编制和预算至关重要。分析职位保持冻结状态的持续时间有助于识别停滞的决策并优化资源规划。获取方式从“冻结职位”业务流程的完成中捕获。职位状态字段通常会因该事件而更新。捕获 “冻结职位”业务流程完成时记录的事件。事件类型 explicit
	职位已解冻	这是冻结的相反操作，即让暂停的职位重新活跃并可供人员配置。通常通过推断职位的状态字段从“冻结”到“活跃”的变更来捕获。
为何重要此 event 标志着冻结职位的解决。衡量从“职位已冻结”到此 event 的时间是“冻结职位解决时间”KPI 的关键。获取方式这可以从职位历史或审计日志中职位状态字段的生效日期变更中推断出来。在某些配置中，它也可能是一个明确的“解冻”业务流程 event。捕获根据生效日期历史记录，检测职位状态从“已冻结”到“活动”的变更。事件类型 inferred
	职位已重新分类	代表与职位相关的职位描述或分类的正式变更。当特定职位的“变更工作”业务流程成功完成时，将捕获此 event。
为何重要此 activity 有助于理解组织重组或职位职责的重大转变。跟踪重新分类支持对劳动力演变和职位架构稳定性的分析。获取方式源自应用于职位时的“变更工作”业务流程完成日志，区别于应用于员工的情况。捕获职位“岗位变动”业务流程成功完成时记录的事件。事件类型 explicit
	职位申请被拒绝	此 activity 代表职位创建申请未获成功，审批人已将其拒绝。Workday 将其记录为“创建职位”业务流程的“拒绝”终结状态。
为何重要分析被拒绝的申请有助于识别常见的拒绝原因，如预算限制或政策不符，从而改进流程并为申请人提供更好的指导。获取方式这捕获自“创建职位”业务流程实例的最终状态。event timestamp 是采取拒绝操作的时间。捕获审批人在业务流程步骤中选择“拒绝”操作时记录的事件。事件类型 explicit

推荐可选

提取指南

如何从 Workday HCM 获取数据

步骤

登录 Workday：使用具有创建自定义报表权限并可访问所需人力资本管理 (HCM) 数据域的用户账号登录您的 Workday 租户。
创建自定义报表：使用搜索栏找到并打开“创建自定义报表”任务。
选择报表类型和数据源：为报表命名，例如“ProcessMind 职位管理事件”。报表类型选择“Advanced”。数据源选择“Business Process Transactions”。该源可提供有关业务流程步骤的详细事件级信息。
定义报表列：在“列”选项卡中，添加将成为事件日志列的字段。您需要将 Workday 对象和字段映射到所需属性。例如：
- PositionId：映射到业务流程上下文中的“职位 ID”。
- EventTime：映射到每个步骤的“完成日期”或“校正后的完成时刻”。
- User：映射到事务的“完成者”。
- PositionStatus、Department、CostCenter、JobFamily：映射到“职位”业务对象上的相应字段。
为活动名称创建计算字段：此次提取的核心是将业务流程步骤转换为标准化的活动名称。转到“相关业务对象”菜单并创建“计算字段”。使用“Evaluate Expression”类型创建逻辑树。例如：
- 如果“业务流程类型”为“创建职位”且“事务状态”为“成功完成”，则返回文本“职位已创建”。
- 如果“业务流程类型”为“创建职位”，“步骤”为“[您的经理审批步骤名称]”且“状态”为“已完成”，则返回文本“经理审批已提交”。
- 为 13 个所需活动中的每一个创建条件。
配置报表筛选器：在“筛选器”选项卡中，添加提示和筛选器以限定数据范围。为“完成日期”创建一个提示，以便进行日期范围选择。添加一个筛选器，仅包含相关的“业务流程类型”，如“创建职位”、“编辑职位限制”、“岗位变动”、“冻结职位”、“停用职位”和“关闭职位”。
优化排序和输出：在“排序”选项卡中，按 PositionId 然后按 EventTime 对结果进行排序，以确保每个案例都遵循时间顺序。
启用为 Web 服务 (RaaS)：报表在界面中正确运行后，转到“操作”>“Web 服务”>“启用为 Web 服务”。在选项中，将“内容类型”设置为“JSON”以便于集成。
安全配置与测试端点：配置 Web 服务安全设置，定义哪些用户或系统可以访问它。记录生成的 JSON 或 WSDL URL。使用 Postman 或简单脚本测试端点，验证是否收到数据。
自动提取数据：使用您的集成平台或脚本按计划调用 RaaS URL。脚本应在请求中将所需的日期范围作为参数传递。
为 ProcessMind 格式化数据：脚本应解析来自 Workday 的 JSON 响应，并将其转换为扁平的 CSV 文件。确保 CSV 中的列标题与所需的属性名称匹配：PositionId、ActivityName、EventTime、User 等。
上传到 ProcessMind：格式化后的最终 CSV 文件即可上传到 ProcessMind 进行分析。

配置

报表类型：Advanced。此类型对于创建计算字段以及跨不同业务对象关联数据至关重要。
主要数据源：'Business Process Transactions'。该数据源以事件为导向，包含业务流程每一步所需的详细信息，如状态、时间戳和参与者。
关键筛选条件：
- 业务流程类型：筛选报表以仅包含相关流程，如“创建职位”、“关闭职位”、“冻结职位”、“岗位变动”、“编辑职位限制”和“停用职位”。这对于系统性能至关重要。
- 完成日期：对此字段使用提示筛选器，允许用户指定数据提取的日期范围。建议初始加载 3-6 个月的数据。
计算字段：需要大量使用“Evaluate Expression”和“Lookup Related Value”计算字段，以便派生标准化的 ActivityName，并将核心“职位”对象的属性引入事件流中。
Web 服务输出：将 RaaS 输出格式配置为 JSON。虽然也支持 XML，但 JSON 通常更易于被现代应用程序解析。
权限：创建报表的用户需要具备“业务流程事务”、“职位管理”和“员工数据”等数据域的安全访问权限。RaaS 调用返回的数据将受这些权限的限制。

a 查询示例 config

/*
 This is a logical representation of the Workday Advanced Report configuration.
 It is built using the Workday Report Writer UI, not by writing code.
 Each 'SELECT' block represents a set of conditions within a single 'Evaluate Expression' calculated field for the 'ActivityName' column.
 The report's primary data source is 'Business Process Transactions'.
*/

// Calculated Field for ActivityName: 'cf_ActivityName'
// Type: Evaluate Expression

// Condition 1: Position Request Initiated
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Transaction'.Is First Step = true)
THEN 'Position Request Initiated'
// Column Mapping for this condition:
// PositionId: 'Position' From Business Process -> Position ID
// ActivityName: 'cf_ActivityName' (this calculated field)
// EventTime: 'Business Process' -> Initiation Moment
// User: 'Business Process' -> Initiator

// Condition 2: Manager Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Manager Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Manager Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 3: HR Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'HR Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'HR Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 4: Budget Approved
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Budget Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Budget Approved'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 5: Position Request Denied
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Denied')
THEN 'Position Request Denied'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process Transaction' -> Completed By (on the denial step)

// Condition 6: Position Created
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Created'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business process' -> Initiator

// Condition 7: Position Attributes Modified
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Attributes Modified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 8: Position Reclassified
WHEN ('Business Process'.Type = 'Change Job' AND 'Business Process'.Context.Is Position = true AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Reclassified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 9: Position Compliance Reviewed
WHEN ('Business Process Step'.Name CONTAINS 'Compliance Review' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Position Compliance Reviewed'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 10: Position Frozen
WHEN ('Business Process'.Type = 'Freeze Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Frozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 11: Position Unfrozen
// Note: This often relies on a different data source, 'Position History', to track status changes.
// If using 'Business Process Transactions', this assumes an 'Unfreeze' BP exists or is part of another BP.
// The example below assumes an 'Edit Position' BP is used to change the status.
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Position'.Is Frozen (Prior) = true AND 'Position'.Is Frozen = false AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Unfrozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 12: Position Deactivated
WHEN ('Business Process'.Type = 'Inactivate Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Deactivated'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 13: Position Closed
WHEN ('Business Process'.Type = 'Close Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Closed'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Default case for the calculated field
ELSE 'Other Activity'

/*
Final Report Structure:
- Data Source: Business Process Transactions
- Columns:
  - Position ID (from Position)
  - cf_ActivityName
  - Event Time (Calculated field to pick correct timestamp based on activity)
  - User (Calculated field to pick correct user)
  - End Time (same as Event Time for discrete events)
  - Position Status (from Position)
  - Reason For Change (from Business Process -> Reason)
  - Department (Supervisory Organization from Position)
  - Cost Center (from Position)
  - Job Family (from Job Profile)
- Filter:
  - Business Process Type IN ('Create Position', 'Edit Position Restrictions', 'Change Job', 'Freeze Position', 'Inactivate Position', 'Close Position', ...)
  - Completed Date IS IN [Prompted Date Range]
  - cf_ActivityName IS NOT 'Other Activity'
*/

步骤

前提条件：创建 Workday 自定义报表。 在运行脚本之前，在 Workday 中创建一个提供必要数据的自定义报表。使用“Business Process Transactions”数据源。公开事件日志所需的字段，包括职位 ID、业务流程类型、步骤名称、状态、生效日期、完成日期和发起人。在“Advanced”选项卡上选择“启用为 Web 服务”，并为您的集成系统用户 (ISU) 配置必要权限。
前提条件：配置 Workday 集成用户。 确保您拥有一个具有访问上一步创建的自定义报表权限的集成系统用户 (ISU)。记录用户名、密码以及为报表生成的 RaaS (Reports-as-a-Service) JSON 端点 URL。
设置 Python 环境。 在将要运行提取任务的计算机上安装 Python。使用 pip 安装必要的库：pip install requests pandas。
配置 Python 脚本。 下载提供的 Python 脚本。在文本编辑器中打开文件，并更新脚本顶部的占位符变量。您必须提供 Workday RaaS URL、用户名和密码。此外，设置提取周期所需的 START_DATE 和 END_DATE。
了解脚本逻辑。 脚本向 Workday 进行身份验证，调用自定义报表 Web 服务，并将日期范围作为参数传递。Workday 以 JSON 格式返回数据。如果报表返回多页结果，脚本会自动处理分页。
执行脚本。 打开终端或命令提示符，导航到保存脚本的目录，然后使用以下命令运行脚本：python workday_extraction.py。
活动映射。 脚本包含一个映射字典 (activity_map)，用于将 Workday 业务流程和步骤状态的组合翻译为 ProcessMind 所需的标准活动名称。您可能需要调整此字典中的键，以匹配您 Workday 租户中配置的准确业务流程名称。
数据转换。 脚本会遍历从 Workday 报表返回的每条记录。它应用活动映射，提取所需属性，并正确格式化时间戳。每个有效事件都会添加到列表中。
输出生成。 处理完所有数据后，脚本将事件列表转换为 pandas DataFrame。这将数据构建为具有所需列名的表格格式：PositionId、ActivityName、EventTime、User 等。
导出 ProcessMind 所需的 CSV。 脚本将最终的 DataFrame 保存为名为 position_management_event_log.csv 的 CSV 文件。该文件采用 UTF-8 编码，无需进一步修改即可上传到 ProcessMind。

配置

Workday 自定义报表 (RaaS)： 主要数据源是已启用 Web 服务的 Workday 自定义报表。此报表必须基于 'Business Process Transactions' 数据源构建。
报表字段： 报表必须包含职位 ID、业务流程定义、业务流程步骤、事务状态、生效时间戳、完成时间戳、发起人，以及成本中心或上级组织等任何其他必要属性。
集成系统用户 (ISU)： 身份验证需要具备用户名和密码的 ISU。该用户必须属于有权访问自定义报表 Web 服务端点的安全组。
日期范围： 脚本使用 START_DATE 和 END_DATE 参数。对于初始提取，建议选择 3-6 个月的时间段，以确保数据量适中并提高执行速度。随后的提取可以使用更短的增量周期。
API 端点： 脚本需要自定义报表的 JSON 端点 URL。此 URL 位于 Workday 自定义报表定义的“Web 服务”选项卡中。
活动映射： 脚本逻辑依赖于 Workday 流程名称、状态与最终活动名称之间的可配置映射。这可能需要根据您具体的 Workday 业务流程配置进行自定义。

a 查询示例 python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Workday RaaS endpoint, username, and password
WORKDAY_RAAS_URL = class="hl-string">'[Your_Workday_RaaS_JSON_Endpoint_URL]'
WORKDAY_USERNAME = class="hl-string">'[Your_ISU_Username]'
WORKDAY_PASSWORD = class="hl-string">'[Your_ISU_Password]'

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-12-31'

class=class="hl-string">"hl-comment"># --- Activity Mapping --- #
class=class="hl-string">"hl-comment"># This dictionary maps Workday processes and statuses to standardized activity names.
class=class="hl-string">"hl-comment"># The keys are tuples: (class="hl-string">'Business Process Name', class="hl-string">'Step Name / Status').
class=class="hl-string">"hl-comment"># You MAY need to adjust the class="hl-string">'Business Process Name' to match your Workday configuration.
activity_map = {
    (class="hl-string">'Create Position', class="hl-string">'Initiation Step'): class="hl-string">'Position Request Initiated',
    (class="hl-string">'Create Position', class="hl-string">'Manager Approval'): class="hl-string">'Manager Approval Submitted',
    (class="hl-string">'Create Position', class="hl-string">'HR Approval'): class="hl-string">'HR Approval Submitted',
    (class="hl-string">'Create Position', class="hl-string">'Budget Approval'): class="hl-string">'Budget Approved',
    (class="hl-string">'Create Position', class="hl-string">'Denied'): class="hl-string">'Position Request Denied',
    (class="hl-string">'Create Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Created',
    (class="hl-string">'Edit Position Restrictions', class="hl-string">'Successfully Completed'): class="hl-string">'Position Attributes Modified',
    (class="hl-string">'Change Job', class="hl-string">'Successfully Completed'): class="hl-string">'Position Reclassified',
    (class="hl-string">'Freeze Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Frozen',
    class=class="hl-string">"hl-comment"># Assuming a business process exists for this. If not, this requires a different approach.
    (class="hl-string">'Unfreeze Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Unfrozen',
    (class="hl-string">'Inactivate Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Deactivated',
    (class="hl-string">'Close Position', class="hl-string">'Successfully Completed'): class="hl-string">'Position Closed',
    class=class="hl-string">"hl-comment"># Mapping a class="hl-string">'To Do' step within a parent process for compliance review
    (class="hl-string">'Create Position', class="hl-string">'Compliance Review To Do'): class="hl-string">'Position Compliance Reviewed',
    (class="hl-string">'Edit Position Restrictions', class="hl-string">'Compliance Review To Do'): class="hl-string">'Position Compliance Reviewed'
}

def get_activity_name(process, step, status):
    class="hl-string">"""Determines the activity name based on the mapping."""
    class=class="hl-string">"hl-comment"># Denied and successful completion are based on the overall process status
    if status == class="hl-string">'Denied':
        return activity_map.get((process, class="hl-string">'Denied'))
    if status == class="hl-string">'Successfully Completed':
        return activity_map.get((process, class="hl-string">'Successfully Completed'))

    class=class="hl-string">"hl-comment"># Other activities are based on specific steps
    return activity_map.get((process, step))

def fetch_workday_data():
    class="hl-string">"""Fetches data from the Workday RaaS endpoint with pagination."""
    all_entries = []
    page = 1
    while True:
        params = {
            class="hl-string">'format': class="hl-string">'json',
            class="hl-string">'page': page,
            class="hl-string">'StartDate': fclass="hl-string">'{START_DATE}T00:00:00Z',
            class="hl-string">'EndDate': fclass="hl-string">'{END_DATE}T23:59:59Z'
        }
        print(fclass="hl-string">"Fetching page {page}...")
        try:
            response = requests.get(
                WORKDAY_RAAS_URL,
                auth=(WORKDAY_USERNAME, WORKDAY_PASSWORD),
                params=params
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            entries = data.get(class="hl-string">'Report_Entry', [])
            if not entries:
                print(class="hl-string">"No more entries found. Concluding fetch.")
                break
            all_entries.extend(entries)
            class=class="hl-string">"hl-comment"># Check if this is the last page
            if len(entries) < data.get(class="hl-string">'Report_Data', {}).get(class="hl-string">'Page_Size', 1000):
                 break
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Workday: {e}")
            break
        except ValueError:
            print(class="hl-string">"Error parsing JSON response. Check the URL and credentials.")
            print(class="hl-string">"Response text:", response.text)
            break

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

def main():
    class="hl-string">"""Main function to extract, transform, and save data."""
    report_entries = fetch_workday_data()
    if not report_entries:
        print(class="hl-string">"No data extracted. Exiting.")
        return

    event_log = []
    for entry in report_entries:
        class=class="hl-string">"hl-comment"># Assuming your RaaS report column names are aliased for clarity
        process_name = entry.get(class="hl-string">'BusinessProcessType')
        step_name = entry.get(class="hl-string">'BusinessProcessStep')
        status = entry.get(class="hl-string">'TransactionStatus')
        position_id = entry.get(class="hl-string">'PositionID')
        
        activity = get_activity_name(process_name, step_name, status)
        
        if not activity or not position_id:
            continue class=class="hl-string">"hl-comment"># Skip records that don't map to a required activity or have no Position ID

        event_log.append({
            class="hl-string">'PositionId': position_id,
            class="hl-string">'ActivityName': activity,
            class="hl-string">'EventTime': entry.get(class="hl-string">'CompletedDateTime', entry.get(class="hl-string">'EffectiveDateTime')),
            class="hl-string">'EndTime': entry.get(class="hl-string">'CompletedDateTime'),
            class="hl-string">'User': entry.get(class="hl-string">'InitiatorName'),
            class="hl-string">'PositionStatus': entry.get(class="hl-string">'PositionStatus'), class=class="hl-string">"hl-comment"># Assumes this field is in the report
            class="hl-string">'ReasonForChange': entry.get(class="hl-string">'Reason'),
            class="hl-string">'Department': entry.get(class="hl-string">'SupervisoryOrganization'),
            class="hl-string">'CostCenter': entry.get(class="hl-string">'CostCenter'),
            class="hl-string">'JobFamily': entry.get(class="hl-string">'JobFamily')
        })

    if not event_log:
        print(class="hl-string">"No processable events found after mapping. Exiting.")
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Data Cleaning and Formatting
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'], errors=class="hl-string">'coerce')
    df.dropna(subset=[class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'PositionId', class="hl-string">'EventTime'], inplace=True)

    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    final_columns = [
        class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'User', class="hl-string">'EndTime', 
        class="hl-string">'PositionStatus', class="hl-string">'ReasonForChange', class="hl-string">'Department', class="hl-string">'CostCenter', class="hl-string">'JobFamily'
    ]
    df = df.reindex(columns=final_columns)

    output_filename = class="hl-string">'position_management_event_log.csv'
    df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully created event log: {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

步骤

登录 Workday：使用具有创建自定义报表权限并可访问所需人力资本管理 (HCM) 数据域的用户账号登录您的 Workday 租户。
创建自定义报表：使用搜索栏找到并打开“创建自定义报表”任务。
选择报表类型和数据源：为报表命名，例如“ProcessMind 职位管理事件”。报表类型选择“Advanced”。数据源选择“Business Process Transactions”。该源可提供有关业务流程步骤的详细事件级信息。
定义报表列：在“列”选项卡中，添加将成为事件日志列的字段。您需要将 Workday 对象和字段映射到所需属性。例如：
- PositionId：映射到业务流程上下文中的“职位 ID”。
- EventTime：映射到每个步骤的“完成日期”或“校正后的完成时刻”。
- User：映射到事务的“完成者”。
- PositionStatus、Department、CostCenter、JobFamily：映射到“职位”业务对象上的相应字段。
为活动名称创建计算字段：此次提取的核心是将业务流程步骤转换为标准化的活动名称。转到“相关业务对象”菜单并创建“计算字段”。使用“Evaluate Expression”类型创建逻辑树。例如：
- 如果“业务流程类型”为“创建职位”且“事务状态”为“成功完成”，则返回文本“职位已创建”。
- 如果“业务流程类型”为“创建职位”，“步骤”为“[您的经理审批步骤名称]”且“状态”为“已完成”，则返回文本“经理审批已提交”。
- 为 13 个所需活动中的每一个创建条件。
配置报表筛选器：在“筛选器”选项卡中，添加提示和筛选器以限定数据范围。为“完成日期”创建一个提示，以便进行日期范围选择。添加一个筛选器，仅包含相关的“业务流程类型”，如“创建职位”、“编辑职位限制”、“岗位变动”、“冻结职位”、“停用职位”和“关闭职位”。
优化排序和输出：在“排序”选项卡中，按 PositionId 然后按 EventTime 对结果进行排序，以确保每个案例都遵循时间顺序。
启用为 Web 服务 (RaaS)：报表在界面中正确运行后，转到“操作”>“Web 服务”>“启用为 Web 服务”。在选项中，将“内容类型”设置为“JSON”以便于集成。
安全配置与测试端点：配置 Web 服务安全设置，定义哪些用户或系统可以访问它。记录生成的 JSON 或 WSDL URL。使用 Postman 或简单脚本测试端点，验证是否收到数据。
自动提取数据：使用您的集成平台或脚本按计划调用 RaaS URL。脚本应在请求中将所需的日期范围作为参数传递。
为 ProcessMind 格式化数据：脚本应解析来自 Workday 的 JSON 响应，并将其转换为扁平的 CSV 文件。确保 CSV 中的列标题与所需的属性名称匹配：PositionId、ActivityName、EventTime、User 等。
上传到 ProcessMind：格式化后的最终 CSV 文件即可上传到 ProcessMind 进行分析。

配置

报表类型：Advanced。此类型对于创建计算字段以及跨不同业务对象关联数据至关重要。
主要数据源：'Business Process Transactions'。该数据源以事件为导向，包含业务流程每一步所需的详细信息，如状态、时间戳和参与者。
关键筛选条件：
- 业务流程类型：筛选报表以仅包含相关流程，如“创建职位”、“关闭职位”、“冻结职位”、“岗位变动”、“编辑职位限制”和“停用职位”。这对于系统性能至关重要。
- 完成日期：对此字段使用提示筛选器，允许用户指定数据提取的日期范围。建议初始加载 3-6 个月的数据。
计算字段：需要大量使用“Evaluate Expression”和“Lookup Related Value”计算字段，以便派生标准化的 ActivityName，并将核心“职位”对象的属性引入事件流中。
Web 服务输出：将 RaaS 输出格式配置为 JSON。虽然也支持 XML，但 JSON 通常更易于被现代应用程序解析。
权限：创建报表的用户需要具备“业务流程事务”、“职位管理”和“员工数据”等数据域的安全访问权限。RaaS 调用返回的数据将受这些权限的限制。

a 查询示例 config

/*
 This is a logical representation of the Workday Advanced Report configuration.
 It is built using the Workday Report Writer UI, not by writing code.
 Each 'SELECT' block represents a set of conditions within a single 'Evaluate Expression' calculated field for the 'ActivityName' column.
 The report's primary data source is 'Business Process Transactions'.
*/

// Calculated Field for ActivityName: 'cf_ActivityName'
// Type: Evaluate Expression

// Condition 1: Position Request Initiated
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Transaction'.Is First Step = true)
THEN 'Position Request Initiated'
// Column Mapping for this condition:
// PositionId: 'Position' From Business Process -> Position ID
// ActivityName: 'cf_ActivityName' (this calculated field)
// EventTime: 'Business Process' -> Initiation Moment
// User: 'Business Process' -> Initiator

// Condition 2: Manager Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Manager Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Manager Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 3: HR Approval Submitted
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'HR Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'HR Approval Submitted'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 4: Budget Approved
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process Step'.Name CONTAINS 'Budget Approval' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Budget Approved'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 5: Position Request Denied
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Denied')
THEN 'Position Request Denied'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process Transaction' -> Completed By (on the denial step)

// Condition 6: Position Created
WHEN ('Business Process'.Type = 'Create Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Created'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business process' -> Initiator

// Condition 7: Position Attributes Modified
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Attributes Modified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 8: Position Reclassified
WHEN ('Business Process'.Type = 'Change Job' AND 'Business Process'.Context.Is Position = true AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Reclassified'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 9: Position Compliance Reviewed
WHEN ('Business Process Step'.Name CONTAINS 'Compliance Review' AND 'Business Process Transaction'.Status = 'Completed')
THEN 'Position Compliance Reviewed'
// Column Mapping for this condition:
// EventTime: 'Business Process Transaction' -> Completed Moment
// User: 'Business Process Transaction' -> Completed By

// Condition 10: Position Frozen
WHEN ('Business Process'.Type = 'Freeze Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Frozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 11: Position Unfrozen
// Note: This often relies on a different data source, 'Position History', to track status changes.
// If using 'Business Process Transactions', this assumes an 'Unfreeze' BP exists or is part of another BP.
// The example below assumes an 'Edit Position' BP is used to change the status.
WHEN ('Business Process'.Type = 'Edit Position Restrictions' AND 'Position'.Is Frozen (Prior) = true AND 'Position'.Is Frozen = false AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Unfrozen'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 12: Position Deactivated
WHEN ('Business Process'.Type = 'Inactivate Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Deactivated'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Condition 13: Position Closed
WHEN ('Business Process'.Type = 'Close Position' AND 'Business Process'.Status = 'Successfully Completed')
THEN 'Position Closed'
// Column Mapping for this condition:
// EventTime: 'Business Process' -> Overall Process Completed Moment
// User: 'Business Process' -> Initiator

// Default case for the calculated field
ELSE 'Other Activity'

/*
Final Report Structure:
- Data Source: Business Process Transactions
- Columns:
  - Position ID (from Position)
  - cf_ActivityName
  - Event Time (Calculated field to pick correct timestamp based on activity)
  - User (Calculated field to pick correct user)
  - End Time (same as Event Time for discrete events)
  - Position Status (from Position)
  - Reason For Change (from Business Process -> Reason)
  - Department (Supervisory Organization from Position)
  - Cost Center (from Position)
  - Job Family (from Job Profile)
- Filter:
  - Business Process Type IN ('Create Position', 'Edit Position Restrictions', 'Change Job', 'Freeze Position', 'Inactivate Position', 'Close Position', ...)
  - Completed Date IS IN [Prompted Date Range]
  - cf_ActivityName IS NOT 'Other Activity'
*/

您的入职到退休 — 岗位管理数据模板

您的入职到退休 — 岗位管理数据模板

入职到退休——职位管理属性

入职到退休——职位管理活动

提取指南

Workday 自定义报表服务 (RaaS) 提取

步骤

配置

a 查询示例 config

使用 Workday Web Services (WWS) API 的 Python 脚本

步骤

配置

a 查询示例 python

带有 Workday 连接器的中间件或 ETL 平台

步骤

配置

a 查询示例 config

准备好开始了吗？

立即优化 Workday HCM “入职到退休”职位管理

您的入职到退休 — 岗位管理数据模板

您的入职到退休 — 岗位管理数据模板

入职到退休——职位管理属性

入职到退休——职位管理活动

提取指南

Workday 自定义报表服务 (RaaS) 提取

步骤

配置

a 查询示例 config

使用 Workday Web Services (WWS) API 的 Python 脚本

步骤

配置

a 查询示例 python

带有 Workday 连接器的中间件或 ETL 平台

步骤

配置

a 查询示例 config

我们重视您的隐私

准备好开始了吗？

立即优化 Workday HCM “入职到退休”职位管理