> 継続的なプロセス改善 > 採用・人材獲得 > Workday Recruiting > データテンプレート

採用・タレントアクイジション向けデータテンプレート

Workday Recruiting

採用・人材獲得の属性 (19) 採用・人材獲得のアクティビティ (15) 抽出ガイド (3)

採用・タレントアクイジション向けデータテンプレート

このテンプレートでは、採用・タレントアクイジションのプロセスを分析するために必要なデータの収集方法を詳しく説明します。収集すべき属性、追跡すべき主要なアクティビティ、Workday Recruitingシステムからデータを抽出する方法をまとめています。この資料を使ってデータ準備を効率化し、プロセスマイニングを早く始められます。

収集を推奨する属性
追跡すべき主要なアクティビティ
Workday Recruitingからの抽出方法

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

採用・人材獲得の属性

採用・人材獲得を詳細に分析し、採用プロセスへの深いインサイトを得るためにイベントログへ含める推奨データ項目です。

3 必須 5 推奨 11 任意

	名前	説明
	アクティビティ名 ActivityName	採用プロセス内のある時点で発生した特定のイベントまたはタスクの名称です。
説明 Activity Nameは、「Application Screened」、「Interview Scheduled」、「Offer Extended」など、採用活動における1つのステップまたはマイルストーンを示します。これらのアクティビティが、プロセスを構成するイベントの順序を形成します。この属性は、プロセスマップの可視化、応募がたどるさまざまな経路の特定、イベントの発生頻度と順序の分析に欠かせません。プロセスで何が起きているかを理解する基盤となります。重要な理由この属性によって採用プロセスの各ステップを定義し、プロセスフローを可視化・分析できます。入手先 Workday Recruitingの求人応募データにあるビジネスプロセスのステップ名またはステータス変更から取得します。例応募書類の選考完了面接完了オファー受諾候補者不採用
	イベント時刻 EventTime	アクティビティまたはイベントが発生した時点を示すタイムスタンプです。
説明この属性には、特定の採用アクティビティが実施された正確な日時が記録されます。タイムスタンプはイベントの時系列を示すため、プロセスマイニングの基盤となります。分析では、アクティビティ間の所要時間の算出、「Time to Hire」などの全体サイクルタイムの測定、プロセスが遅延しているボトルネックの特定に使います。採用ファネルを時間軸で分析するうえで欠かせません。重要な理由タイムスタンプは、時間に関するすべてのKPIの算出、プロセス期間の把握、ボトルネックの発見に欠かせません。入手先 Workday Recruitingにおけるビジネスプロセスステップの完了日または取引日を示します。例 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	求人応募 JobApplicationId	候補者の求人応募を一意に識別するIDで、採用プロセスの中心となるケースIDです。
説明 Job Application IDは、特定の求人への候補者1人の応募から最終決定までの過程を一意に追跡します。この応募に関連する各インタラクション、ステータス変更、意思決定ポイントは、この識別子に紐づきます。プロセスマイニングでは、この属性が基本となります。候補者ごとのエンドツーエンドのプロセスフローを再構成し、サイクルタイム、ボトルネック、たどった経路を分析できます。関連するすべてのアクティビティを一貫したケースとして結び付ける中核要素です。重要な理由 1人の候補者に関する採用アクティビティをすべて結び付ける必須のケースIDであり、採用活動全体を分析できます。入手先 Workday Recruitingの中核要素で、通常は求人応募に関するレポートやデータソースで確認できます。例 APP-2023-001234APP-2023-005678APP-2024-009101
	応募ステータス ApplicationStatus	求人応募の最終結果または現在の状態です。
説明この属性には、「Hired」、「Rejected by Company」、「Offer Declined」、「Withdrawn by Candidate」など、求人応募の最終処遇が記録されます。特定の応募におけるプロセスの終端状態を示します。このステータスは、結果分析に欠かせません。各段階の転換率、オファー受諾率、候補者離脱率の算出に使います。応募がどの段階で、なぜ終了したかを理解することは、プロセス全体の有効性を高めるうえで重要です。重要な理由各ケースの結果を定義します。コンバージョン率、離脱率、プロセス全体の成功率を計算するうえで欠かせません。入手先通常、Workday RecruitingのJob Applicationオブジェクトにある、最終処理またはステータス理由のフィールドです。例採用済み不採用オファー辞退応募辞退
	応募経路 ApplicationSource	候補者の応募を受け付けた経路またはソースです。
説明この属性は、候補者がどのように求人を知り、応募したかを示します。たとえば、企業の採用ページ、LinkedIn、社員紹介、採用エージェンシーなどです。応募経路を把握することは、採用戦略と予算を最適化するうえで重要です。「Sourcing Channel Effectiveness」ダッシュボードや「Offer Acceptance Rate by Source」KPIに利用でき、最も多く、質の高い候補者を生み出す経路を判断できます。重要な理由さまざまな応募経路の有効性を評価し、採用リソースをどこに投じるかをデータに基づいて判断できます。入手先 Workday Recruitingのドキュメントを参照してください。求人応募に標準で用意されているフィールドです。例 LinkedIn社員紹介会社の採用サイトIndeed
	採用担当者名 RecruiterName	求人応募の管理を担当する採用担当者の名前です。
説明この属性は、求人応募と求人要件に割り当てられた主な人材獲得担当者または採用担当者を示します。通常、候補者がプロセスを進められるよう支援します。採用担当者別にプロセスを分析することは、チームのパフォーマンスと業務量を把握するうえで重要です。「Recruiter Performance And Throughput」ダッシュボードの作成や、「Recruiter Time-to-Offer Variance」などのKPIの算出に役立ち、効率の比較やベストプラクティスの特定が可能になります。重要な理由採用担当者別のパフォーマンス分析が可能になり、高い成果を上げている担当者、トレーニングの必要性、業務量の偏りを特定できます。入手先 Workday Recruitingのドキュメントを参照してください。通常はJob RequisitionまたはJob Applicationオブジェクトに紐づいています。例 John SmithEmily JonesMaria Garcia
	採用責任者 HiringManager	候補者が応募したポジションの採用責任者の名前です。
説明この属性は、募集ポジションがあるチームまたは部門の責任者を示します。採用責任者は、特に面接やフィードバックの段階で意思決定に関わる重要な関係者です。このデータは「Hiring Manager Feedback Timeliness」ダッシュボードに欠かせません。採用責任者ごとに「Interview Completed」から「Feedback Submitted」までの時間を分析することで、遅延箇所を特定し、特定の責任者と連携して採用サイクルを短縮できます。重要な理由採用責任者の関与度を分析し、フィードバック提出の遅延を特定するうえで重要です。候補者体験に直接影響します。入手先 Workday Recruitingのドキュメントを参照してください。通常は監督組織または求人要件の詳細の一部です。例 Susan AdamsDavid ChenAngela Rodriguez
	部門 Department	求人要件に関連付けられた部門または事業部門です。
説明この属性は、候補者を採用する組織単位を示します。たとえば、「Engineering」、「Marketing」、「Finance」などです。求人要件に関連付けられた監督組織から取得します。分析で部門を絞り込むと、事業の各部門における採用プロセスを比較できます。「Application Screening Efficiency」ダッシュボードで利用し、特定の部門の選考時間が長いかどうかを確認して、異なる運用やリソースの必要性を把握できます。重要な理由異なる事業部門や部門間で、採用プロセスのパフォーマンスと効率を比較できます。入手先 Workday Recruitingのドキュメントを参照してください。Job Requisitionに紐づくSupervisory Organizationから取得します。例エンジニアリング営業人事財務
	ソースシステム SourceSystem	データを抽出したシステムです。
説明この属性はデータの出所を示します。この場合はWorkday Recruitingです。複数のシステムのデータを統合する際に、データガバナンスやトラブルシューティングに役立ちます。単一システムの分析では不要に見える場合でも、常に含めることが推奨されます。データの来歴を確認でき、将来ほかのHRシステムを統合する際に重要になります。重要な理由データの出所を示します。データガバナンス、検証、複数のソースからのデータ管理に欠かせません。入手先データの抽出・変換プロセスで追加される固定値（「Workday Recruiting」）です。例 Workday Recruiting
	不採用理由 RejectionReason	候補者の応募が不採用になった際に入力される理由です。
説明応募が「Rejected」ステータスに変更されると、この属性によって判断の背景を確認できます。理由には、「カルチャーフィットしない」「必要なスキルが不足している」「別の候補者でポジションが充足した」などがあります。不採用理由を分析すると、採用プロセスの傾向を把握できます。たとえば、後半の段階で「必要なスキルが不足している」ことを理由とする不採用が多い場合、求人票の内容に問題がある可能性があります。このデータは、「Candidate Drop-Off Hotspots」ダッシュボードで、候補者が離脱する「理由」を把握するための重要な情報です。重要な理由候補者が選考を進められない理由を定性的に把握し、求人票やスクリーニング基準の改善に役立ちます。入手先 Workday Recruitingのドキュメントを参照してください。通常、不採用ステップに関連付けられたサブステータスまたは理由コードです。例応募条件を満たしていない経験が要件と合わないより適任の候補者が見つかった募集終了
	候補者ID CandidateId	候補者を一意に識別するIDです。
説明 Candidate IDは、応募した求人の数にかかわらず、採用システム内の個人を一意に識別します。これにより、候補者の企業内での応募履歴を追跡できます。この属性は、候補者体験を長期的に分析する際に役立ちます。たとえば、以前不採用となった候補者が再応募しているか、その経路がどのように異なるか、1人の候補者が複数のポジションで同時に選考されているかを確認できます。重要な理由候補者を中心にプロセスを把握し、複数の応募や長期的な経過を追跡できます。入手先 Workday RecruitingのCandidateオブジェクトにおける主要識別子です。例 CAND-98765CAND-11223CAND-54321
	候補者タイプ CandidateType	候補者が社内従業員か社外応募者かを示します。
説明この属性では、候補者を「Internal」や「External」などのグループに分類します。採用プロセス、所要期間、ポリシーは、この2つのタイプで大きく異なる場合があります。社内候補者と社外候補者のプロセスを分けて分析することは、全体像を把握するうえで重要です。組織は、社内異動プログラムと社外採用の取り組みの効率を比較し、双方のプロセスを改善できます。重要な理由社内採用と社外採用のプロセスを分けて分析できます。両者では、ステップ、SLA、目標が異なることが多くあります。入手先 Workday Recruitingのドキュメントを参照してください。候補者プロフィールまたは求人応募にある標準フィールドです。例社内社外
	最終データ更新 LastDataUpdate	ソースシステムからデータが最後に更新または抽出された時点のタイムスタンプです。
説明この属性は、分析対象データの鮮度を示します。Workday Recruitingから最後にデータを取得した日時を確認できます。分析がどの程度最新のものかを理解するうえで重要です。リアルタイムデータを見ているのか、特定時点のスナップショットを見ているのかを把握でき、分析結果を適切に解釈できます。重要な理由データの鮮度を把握するための情報を提供し、プロセス分析がどの程度最新かを理解できるようにします。入手先このタイムスタンプは、データの抽出・変換・ロード（ETL）プロセスで生成され、追加されます。例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	取り下げ済み IsWithdrawn	候補者が応募を取り下げたかどうかを示すフラグです。
説明応募の最終ステータスが「Withdrawn by Candidate」または同様の状態の場合にtrueとなる、計算された真偽値の属性です。候補者がプロセスから離脱したケースを切り分けるのに役立ちます。このフラグを使うと、「Candidate Drop-Off Hotspots」ダッシュボードや「Candidate Drop-off Rate」KPIを簡単に分析できます。フィルタリングや集計によって、候補者がどの段階で取り下げやすいかを把握できます。重要な理由候補者自身による離脱を個別に分析し、候補者体験やプロセス上の摩擦点を把握するのに役立ちます。入手先データ変換時に「ApplicationStatus」属性を基に計算します。例 truefalse
	採用所要時間 TimeToHire	応募を受け付けてから候補者を採用するまでの合計時間です。
説明成功した候補者について、採用プロセス全体の所要時間を測定するケース単位の計算値です。「Application Received」イベントから「Candidate Hired」イベントまでの時間差として計算します。採用における最も重要なKPIの1つである「Average Time to Hire」です。採用プロセス全体の効率を大きな視点で測定できます。この指標を期間別、部門別に追跡すると、全社的な改善や悪化を特定できます。重要な理由採用ファネルの開始から終了までの全体的な効率を測定する、重要な上位レベルのKPIです。入手先 Workdayから抽出したイベントログのデータを基に計算します。例 259200043200003456000
	提示金額 OfferAmount	候補者に提示した給与額です。
説明この属性には、求人オファーで候補者に提示した基本給の金額が入ります。採用プロセスの最終段階で必要となる重要なデータです。提示金額を分析すると、報酬の傾向や競争力を把握できます。「Offer Accepted」ステータスと組み合わせれば、オファー辞退の要因として報酬が影響しているかを確認できます。「Offer Management And Acceptance Rates」ダッシュボードの主要な要素です。重要な理由報酬戦略と、オファー承諾率への影響を分析するのに役立ちます。入手先 Workday Recruitingのドキュメントを参照してください。「Offer」ビジネスプロセスのデータに含まれます。例 8500012000065000
	求人勤務地 JobLocation	求人の地理的な勤務地または国です。
説明この属性では、求人ポジションが置かれている市区町村、州、または国を指定します。リモートポジションの場合は、地域を示すか、「Remote」と記録されることがあります。勤務地は、分析において有効な切り口です。地域ごとに「Time to Hire」などのKPIを比較できるため、現地の市場環境、人材の確保しやすさ、地域ごとのプロセスの違いによる差を明らかにできます。重要な理由採用プロセスを地理的に分析し、地域ごとのサイクルタイムや効率の違いを明らかにします。入手先この情報は、WorkdayのJob Requisitionの詳細に含まれています。例ニューヨーク州ニューヨーク英国ロンドン米国リモートドイツ・ベルリン
	求人要件ID JobRequisitionId	候補者が応募した求人ポジションを一意に識別するIDです。
説明 Job Requisition IDは、承認済みの求人ポジションを識別します。1つの求人要件に複数の応募を関連付けることができます。この属性によって、求人要件単位で分析できます。たとえば、求人要件が公開されていた期間、獲得した候補者数、職種別の採用ファネル（エンジニア職と営業職など）を分析できます。重要な理由複数の応募を1つの求人ポジションに紐付け、求人要件単位の指標や採用ファネルを分析できます。入手先 Workday RecruitingのJob Requisitionオブジェクトにある主要識別子で、すべての求人応募に紐付いています。例 REQ-2023-105REQ-2024-012REQ-2024-345
	自動化済み IsAutomated	アクティビティがシステムによって自動的に実行されたかどうかを示すフラグです。
説明この真偽値の属性によって、ステップがユーザーによって実行されたか、自動化されたシステムプロセスによって実行されたかを識別できます。たとえば、最初に送信する「Application Received」の確認メールは、自動化されたアクティビティである可能性があります。どのステップが自動化されているかを把握すると、効率化の機会を見つけやすくなります。自動化がサイクルタイムやリソース配分に与える影響の評価にも役立ちます。重要な理由手動で実行されたアクティビティとシステム主導のアクティビティを区別します。自動化の機会を見つけ、その効果を測定するうえで重要です。入手先 Workdayで自動化されていることが分かっているシステムユーザーアカウントまたは特定のイベントタイプを特定し、この情報を導出する必要があります。例 truefalse

必須推奨任意

採用・人材獲得のアクティビティ

採用ワークフローを正確にディスカバリーし、ボトルネックを特定するためにイベントログへ記録する主要なプロセスステップとマイルストーンです。

7 推奨 8 任意

	アクティビティ	説明
	オファー受諾	候補者が求人オファーを正式に受諾したことを示します。候補者がWorkdayポータルで「Accept Offer」タスクを完了した時点、または採用担当者がステータスを手動で更新した時点で記録されます。
重要な理由応募経路、部門、採用担当者別のオファー受諾率を算出するうえで重要です。また、身元調査など、採用前に行う後続アクティビティの開始にもつながります。入手先候補者が候補者ポータルからオファーを受諾した時点で明示的に記録されます。操作は求人応募のビジネスプロセス履歴にタイムスタンプ付きで保存されます。取得「Accept Offer」タスクの完了時のタイムスタンプから取得します。イベントタイプ explicit
	オファー提示	候補者に求人オファーを正式に提示したことを示します。Workdayで求人応募に対する「Create Offer」または「Propose Compensation」ビジネスプロセスが正常に完了した時点で、個別のイベントとして記録されます。
重要な理由「Time to Offer」の算出や、オファープロセスの適合性分析に使う主要なマイルストーンです。オファー受諾率の測定開始点にもなります。入手先このイベントは求人応募のビジネスプロセス履歴に明示的に記録されます。オファー作成ステップの完了時のタイムスタンプがアクティビティ時刻となります。取得「Create Offer」ビジネスプロセスの完了時のタイムスタンプから取得します。イベントタイプ explicit
	候補者をオファーステージへ移行	候補者に求人オファーを提示する決定が下されたことを示す重要なマイルストーンです。採用プロセスで候補者の応募が「Offer」ステージに進んだ時点で記録されます。
重要な理由このアクティビティはプロセス上の重要なゲートウェイであり、すべての評価段階が正常に完了したことを示します。正式なオファーに先立つ段階であり、コホート分析の重要なポイントです。入手先求人応募の監査証跡にある、候補者のステータスが「Offer」に変更された時点のタイムスタンプから推定します。取得候補者の進捗が「Offer」ステージに変更されたことから特定します。イベントタイプ inferred
	候補者を面接へ移行	候補者が初期選考を通過し、面接の対象になったことを示します。採用担当者が採用プロセス内で候補者を「Interview」ステージへ移行した時点で記録されます。
重要な理由このマイルストーンは、選考から本格的な評価への移行を示します。転換率や採用ファネル上流の効率を分析するうえで重要なポイントです。入手先求人応募履歴内で、候補者の採用ステージが「Interview」または同様の名称に変更された時点のタイムスタンプから推定します。取得候補者の進捗が「Interview」ステージに変更されたことから特定します。イベントタイプ inferred
	候補者不採用	企業が候補者の採用を進めないと決定した場合の、プロセスの不成立終了を示します。採用担当者が候補者を「Rejected」または「Not Hired」の処遇ステータスに移行した時点から推定します。
重要な理由各段階における候補者離脱の集中箇所や不採用率を分析するうえで重要な終了イベントです。面接や選考プロセスの問題特定に役立ちます。入手先求人応募履歴で候補者の処遇が「Rejected」に変更された時点のタイムスタンプから推定します。不採用理由も記録されることが一般的です。取得「Rejected」の処遇への移行時の有効なタイムスタンプから取得します。イベントタイプ inferred
	候補者採用	候補者が正式に従業員として採用され、採用プロセスが正常に完了したことを示します。Workdayで「Hire」ビジネスプロセスが正常に完了し、従業員レコードが作成された時点で記録されます。
重要な理由プロセスの主要な成功終了イベントです。採用期間の算出、プロセス全体の効率と成功率の測定に欠かせないタイムスタンプです。入手先 Workday HCMの「Hire」ビジネスプロセスによって記録される、主要かつ明示的なイベントです。完了時のタイムスタンプはプロセス履歴に保存されます。取得候補者の「Hire」ビジネスプロセス完了時のタイムスタンプから取得します。イベントタイプ explicit
	応募受付	候補者の求人応募における採用プロセスの開始を示します。候補者がWorkdayポータルまたは連携した採用サイトから、特定の求人への応募を正常に送信した時点で記録されます。
重要な理由これはプロセスの主要な開始イベントです。このアクティビティから後続のマイルストーンまでの時間を分析することは、採用期間全体と応募経路の有効性を測定するうえで基本となります。入手先候補者について「Apply for Job」ビジネスプロセスが正常に完了した時点で、Workdayに明示的なイベントとして記録されます。イベントのタイムスタンプは候補者の応募履歴で確認できます。取得候補者プロフィールに記録された応募送信時のタイムスタンプから取得します。イベントタイプ explicit
	オンボーディング開始	Workday内で新規採用者のオンボーディングプロセスが開始されたことを示します。通常は、主要な「Hire」ビジネスプロセスの一部として明示的に記録されるか、その直後に開始されます。
重要な理由「Offer Accepted」からこのアクティビティまでの時間を分析することで、オファー受諾後の候補者体験を効率化できます。新規採用者が入社初日に向けて関心を保ち、準備できるようにします。入手先 Workdayの「Onboarding」ビジネスプロセスには明確な開始時刻が記録されます。新入社員レコードのプロセス監査証跡から取得できます。取得「Onboarding」ビジネスプロセスの開始時のタイムスタンプから取得します。イベントタイプ explicit
	フィードバック提出	面接担当者が面接後に候補者の評価を正式に提出した時点を示します。Workdayでは、面接担当者が候補者プロフィールから直接フィードバックを入力できます。
重要な理由これは「Hiring Manager Feedback Timeliness」分析に欠かせません。ここでの遅延は一般的なボトルネックであり、追跡することでサービスレベル合意の遵守を徹底できます。入手先「Provide Interview Feedback」タスクからフィードバックが提出された時点で、明示的なイベントとして記録されます。提出時のタイムスタンプは面接レコードに記録されます。取得「Provide Interview Feedback」イベントの完了時のタイムスタンプから抽出します。イベントタイプ explicit
	応募書類の選考完了	採用担当者または選考チームによる候補者の応募書類の初回確認が完了したことを示します。通常は、候補者のステータスが「Applied」または「New」から「Screening」または「Under Review」に変更された時点から推定します。
重要な理由このアクティビティは、初期選考段階の効率を分析するうえで重要です。処理量と所要時間を追跡することで、採用ファネルの早い段階にあるボトルネックを特定できます。入手先「Recruiting」ビジネスプロセスの監査証跡にある、候補者のステージが選考または確認ステップに変更された有効日から推定します。取得候補者のステージが「Screen」に更新された時点のタイムスタンプから取得します。イベントタイプ inferred
	応募辞退	候補者がそのポジションの選考対象から自ら外れる終了イベントです。候補者本人または採用担当者によって、候補者のステータスが「Withdrawn」に更新された時点で記録されます。
重要な理由候補者がいつ、なぜ辞退したかを追跡することは、候補者体験の問題、プロセスの長さ、オファーの競争力を理解するうえで欠かせません。離脱分析の主要指標です。入手先候補者の処遇が「Withdrawn」に更新された時点のタイムスタンプから推定します。候補者がポータルで操作する場合と、採用担当者が操作する場合があります。取得「Withdrawn」の処遇への移行時の有効なタイムスタンプから取得します。イベントタイプ inferred
	身元調査完了	身元調査プロセスが正常に完了したことを示します。必要なチェックに合格し、採用可能になったことを示すステータスに候補者が更新された時点から推定します。
重要な理由採用プロセスを確定できるようになる前の最終チェックポイントです。このクリアランスの受領や記録が遅れると、候補者の入社日が遅れる可能性があります。入手先候補者の応募ステータスが「Ready for Hire」または「Background Check Complete」などのステージに更新された時点から推定します。取得身元調査が完了し、合格したことを示すステータス変更から取得します。イベントタイプ inferred
	身元調査開始	オファーを受諾した候補者について、身元調査プロセスが開始されたことを示します。通常は、候補者が「Background Check」ステージへ移行した時点から推定され、第三者ベンダーとの連携が開始される場合があります。
重要な理由コンプライアンスの監視や、オファー受諾から採用前チェック開始までの遅延分析に欠かせません。オンボーディングへのスムーズな移行にも役立ちます。入手先候補者の採用プロセスフローが「Background Check」ステージへ移行した時点のタイムスタンプから推定します。求人応募の監査証跡で、このステータス変更を確認できます。取得「Background Check」ステージへの移行時の有効なタイムスタンプから取得します。イベントタイプ inferred
	面接完了	候補者との予定された面接が完了したことを示します。通常は、面接担当者または採用担当者が面接のステータスを「Scheduled」から「Completed」または「Conducted」に更新した時点から推定します。
重要な理由このアクティビティは、フィードバック提出期間の開始点となります。この時点からフィードバック提出までの時間を分析することは、採用責任者の対応速度を測定するうえで重要です。入手先面接実施後、Workday Recruitingで予定された面接オブジェクトのステータス更新、または候補者のステージの手動変更から推定します。取得面接ステータスの更新時、または面接後に候補者のステージが変更された時点のタイムスタンプから取得します。イベントタイプ inferred
	面接日程確定	候補者との面接日程が正式に設定されたことを示します。通常は、対象の求人応募についてWorkdayのスケジュール機能で面接イベントが作成され、確定した時点で記録されます。
重要な理由このアクティビティと直前のアクティビティとの間隔を測定することで、調整上の遅延を特定できます。候補者体験の向上と面接プロセスの迅速化に欠かせません。入手先 Workdayの面接日程調整機能では、タイムスタンプ付きのイベントが作成されます。応募に紐づく面接の作成日から、このアクティビティを取得できます。取得採用モジュールで面接レコードが作成されたイベントから取得します。イベントタイプ explicit

推奨任意

抽出ガイド

Workday Recruitingからデータを取得する方法

ステップ

**Workdayにログインする：**カスタムレポートの作成と採用データへのアクセス権限を持つユーザーアカウントで、Workdayテナントにアクセスします。
カスタムレポートを作成する：「Create Custom Report」タスクに移動します。レポートタイプに「Advanced」を選択し、「Enable as Web Service」を有効にします。データソースには、パフォーマンス向上のため、「All Job Applications」などのインデックス付きソースを使用します。
**プライマリビジネスオブジェクトを定義する：**プライマリビジネスオブジェクトに「Job Application」を設定します。このオブジェクトがレポートの基礎となり、ケース識別子にもなります。
**データ列を追加する：**必要なフィールドと推奨フィールドをレポートの列グリッドに追加します。「Job Application」を追加してJobApplicationIdを取得します。「Recruiter」や「Hiring Manager」などの属性は、Job Applicationに関連付けられたビジネスオブジェクトから追加します。
**アクティビティ用の計算フィールドを作成する：**最も重要なステップです。15個のアクティビティそれぞれについて、アクティビティ名用とイベントタイムスタンプ用の2つの計算フィールドを作成します。フィールドのロジックはQueryセクションに記載しています。たとえば「Offer Extended」を取得するには、「Propose Compensation」ビジネスプロセスの完了を確認するフィールドと、そのプロセスの完了タイムスタンプを抽出するフィールドを作成します。
**計算フィールドをレポートに追加する：**新しく作成した計算フィールドをすべて、レポートの列として追加します。合計30個で、アクティビティ名が15個、タイムスタンプが15個です。レポートは「wide」形式となり、求人応募1件につき1行、候補となるアクティビティごとに複数の列が並びます。
**Webサービスのオプションを設定する：**レポート定義の「Web Service」タブで、「Enable as Web Service」にチェックが入っていることを確認します。ここでレポートの名前空間とURLを確認できます。後で使うため、「Namespace」を控えておきます。
**権限を設定する：**RaaSエンドポイントの呼び出しに使うIntegration System User（ISU）または特定のセキュリティグループにレポートを共有します。このユーザーには、データソースのドメイン、たとえば「Recruiting: Job Applications」へのアクセス権限が必要です。
**レポートを実行してテストする：**WorkdayのUIからレポートを実行し、出力を確認します。行数が妥当であること、いくつかのサンプル応募について計算フィールドが正しく入力されていることを確認します。
**抽出をスケジュールする：**外部のスケジューリングツールまたはミドルウェア（MuleSoft、Boomi、カスタムスクリプトなど）を使い、RaaS URLを定期的に呼び出します。適切な認証を使ってWorkday SOAPまたはREST APIを呼び出せるように設定します。
**データを変換する：**RaaS呼び出しから返される生のデータは、wide形式のXMLまたはCSVファイルです。ミドルウェアまたはPythonなどのスクリプト言語で、このデータをアンピボットする変換処理を実装します。各行（求人応募）を反復処理し、空でないアクティビティとタイムスタンプの組み合わせごとに、最終イベントログへ新しい行を作成します。最終的には、JobApplicationId、ActivityName、EventTimeの3つの主要列を持つlong形式になります。

設定

**レポートタイプ：**複雑な計算フィールドや関連ビジネスオブジェクトにアクセスできるよう、必ず「Advanced」を使用します。
**データソース：**レポートを効率よく実行するため、「All Job Applications」などのインデックス付きデータソースを使用します。大規模なデータセットでは、インデックスのないソースを避けてください。
**日付範囲フィルタリング：**Job Applicationビジネスオブジェクトの「Application Date」フィールドにフィルターを設定することが重要です。データ量とレポートのパフォーマンスを管理するため、まずは過去3～6か月など、短い範囲から始めます。
プライマリビジネスオブジェクト：JobApplicationIdをケース識別子として使用できるよう、プライマリオブジェクトには「Job Application」を指定します。
**Webサービスの有効化：**APIからアクセスできるよう、レポート設定で「Enable as Web Service」にチェックを入れます。
**セキュリティと権限：**レポートを専用のIntegration System User（ISU）と共有します。このISUには、「Recruiting: Job Applications」「Business Process Transactions」「Worker Data」など、必要なデータドメインへのアクセス権限を持つセキュリティグループ権限が必要です。
**出力形式：**WorkdayではXML、CSV、JSONなど複数の出力形式を選べます。API経由で構造化データを抽出する場合は、XML、特に「Simple XML」形式が最も安定していることが多くあります。

a サンプルクエリ 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でIntegration System User（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 install requests pandasを使って必要なライブラリをインストールします。
認証スクリプトを作成：Pythonスクリプトで、手順1で作成したISUの資格情報を使って基本認証を実装します。ユーザー名とパスワードはリクエストヘッダーで送信します。
APIリクエストのロジックを実装：「Get Job Applications」エンドポイントを呼び出す関数を記述します。updatedSinceなどのリクエストパラメータを使い、特定の日付以降に更新された応募を取得するなど、データを絞り込みます。これはデータ量を管理するうえで重要です。
APIのページネーションを処理：Workday APIは、1回のリクエストで取得できるレコード数を制限しています。スクリプトでレスポンスのtotal件数と、次のページへのリンクまたはオフセットパラメータを確認し、すべてのページを取得するまでループ処理する必要があります。
アクティビティマッピングを定義：スクリプトにマッピング辞書または条件分岐を作成します。このロジックで、Workdayの業務プロセスステータスと採用ステージ（例：「スクリーニング」「面接」「オファー」「採用」）を、必要なアクティビティ名（例：「応募書類スクリーニング済み」「候補者を面接へ移行」）に変換します。
応募データを変換：APIから取得した各求人応募について、監査証跡またはステージ履歴データを解析します。この履歴には、対応するタイムスタンプとともに、ステージ、判定、業務プロセスイベントの順序が含まれます。
イベントログの行を生成：各応募の履歴を順に処理します。アクティビティマッピングに一致する関連履歴イベントごとに、最終イベントログの1行を表す辞書を作成します。JobApplicationId、ActivityName、EventTime、その他の必須属性を設定します。
データを集約して構造化：すべての応募から生成したイベントログの行を1つのリストに集めます。
CSVファイルを作成してエクスポート：pandasライブラリを使い、イベント辞書のリストをDataFrameに変換します。その後、DataFrameをCSVファイルにエクスポートします。列見出しがProcessMindの要件（例：CaseId、アクティビティ、タイムスタンプ）と一致していることを確認します。
確認してアップロード：最終CSVファイルを開き、内容が正確かつ完全であることを確認してから、プロセスマイニングツールにアップロードします。

設定

**Workday Integration System User（ISU）：**有効期限のない強力なパスワードを設定したISUが必要です。求人応募と候補者の詳細にアクセスできるよう、「Recruiting」と「Worker Data」のセキュリティドメインへの権限を付与します。
**APIエンドポイントとバージョン：**Workdayテナントに対応する正しいREST APIエンドポイントを使用します。一貫した動作を確保するため、リクエストでAPIバージョンを指定することが重要です。
**日付範囲フィルター：**スクリプトでは、updatedSinceなどの日付フィルターを使い、クエリを処理可能な期間に限定します。初回抽出では3～6か月を推奨します。以降の差分ロードでは、最後に成功した抽出のタイムスタンプを使用します。
**ページネーションの上限：**1ページあたりの返却レコード数を制御するAPIのlimitパラメーターに注意してください。一般的な最大値は100です。スクリプトでは、複数回に分けてリクエストを実行できるようにします。
**レスポンスフィールド：**APIが対応している場合は、fieldsなどのパラメーターで返却フィールドを指定すると、パフォーマンスを改善できます。APIレスポンスのサイズを削減できます。
**アクティビティマッピングの設定：**スクリプトの中心となるロジックは、Workdayのステージと定義済みアクティビティのマッピングです。組織固有のWorkday Recruitingのプロセス設定に応じて、カスタマイズが必要になる場合があります。

a サンプルクエリ 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、または同様のプラットフォームなど、Workdayコネクターがインストールされたライセンス済みのサードパーティETLまたはiPaaSツールを用意します。RecruitingおよびStaffingドメインに必要なAPI権限を持つWorkday Integration System User（ISU）の認証情報があることを確認します。
Workday接続を設定：ETLツールでWorkdayへの新しい接続を作成します。WorkdayテナントURL、APIバージョン、ISUの認証情報（ユーザー名とパスワード、またはOAuth 2.0トークンなど）を入力します。接続テストを実行し、正常に接続できることを確認します。
データスキーマを確認：ETLツールのスキーマブラウザーまたはデータソースエクスプローラーを使い、コネクター経由で利用できるWorkdayオブジェクトを確認します。通常は、Job_Application、Job_Requisition、Candidate_Stage_Historyなどのテーブルまたはビューとして表示されます。利用可能なフィールドと関連性を確認します。
主要なData Objectを特定：この抽出では、求人応募、候補者履歴、面接、オファー、採用に関連するオブジェクトのデータが主に必要です。正確な名前はコネクターによって異なりますが、これらの主要エンティティを表すオブジェクトを探します。
SQLクエリを作成：新しいデータ抽出ジョブまたはパイプラインを作成します。SQL変換ステップを使い、Workday接続に対してクエリを実行します。提供されたSQLクエリをこのステップにコピーして貼り付けます。このクエリは、複数のWorkdayオブジェクトからデータを収集し、1つのイベントログ形式に統合するよう設計されています。
クエリをパラメーター化：クエリのWHERE句を変更し、startDateやendDateなどの日付範囲パラメーターを追加します。コードを変更せずに抽出期間を簡単に変更できるよう、ETLジョブでこれらのパラメーターを設定します。
抽出ジョブを実行：設定したETLジョブを実行します。ツールがWorkdayに接続し、API経由でSQLクエリを実行して、ステージング領域またはメモリにデータを取得します。
データを確認して検証：最終出力を書き込む前に、ETLツールのプレビュー機能で結果を確認します。行数が妥当であること、すべての列に想定どおり値が入っていること、複数のアクティビティが含まれていることを確認します。
出力先を設定：抽出データの保存先を定義します。通常は、ProcessMindへのアップロード用CSVファイルです。ファイル名、区切り文字（コンマ）、エンコーディング（UTF-8）を設定します。
確定してエクスポート：抽出ジョブ全体を実行し、最終CSVファイルを生成します。出力ファイルの列見出しが必要な属性（JobApplicationId、ActivityName、EventTime、RecruiterName、HiringManager、ApplicationSource、部門、ApplicationStatus）と一致していることを確認します。

設定

Workday Connectorの認証情報：接続には、WorkdayテナントURLと、パスワードまたはOAuth 2.0クライアント認証情報を持つ認証済みのIntegration System User（ISU）が必要です。このユーザーには、「Recruiting」および「Staffing」の機能領域に対するセキュリティ権限が必要です。
Web Serviceの有効化：Connectorでは、公開するWorkday Web Servicesの指定が必要になる場合があります。必要なすべてのデータオブジェクトにアクセスできるよう、Recruiting、Staffing、Human Resourcesに関連するサービスを有効にします。
期間：パフォーマンスとデータ量を管理するため、特定の期間で抽出を絞り込むことが重要です。最初に3～6か月分をロードし、その後は毎日または毎週の増分ロードを行うことを推奨します。これはSQLクエリのWHERE句で設定します。
データ範囲フィルター：組織の一部だけを分析する場合は、WHERE句にCompany、Cost Center、Supervisory Organizationなどのフィールドに対するフィルターを追加します。
APIバージョン：Connectorによっては、Workday APIのバージョン指定が必要です。最新のデータオブジェクトと機能にアクセスできるよう、サポート対象の新しいバージョンを使用することを推奨します。
パフォーマンスに関する考慮事項：Workdayからの全データ抽出は、リソースに大きな負荷をかける場合があります。大規模なジョブは、利用の少ない時間帯にスケジュールします。継続的な分析では、「最終更新」タイムスタンプに基づく増分ロード方式を実装し、新規または更新されたレコードだけを取得します。

a サンプルクエリ 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）による抽出

ステップ

設定

a サンプルクエリ sql

PythonスクリプトによるWorkday Recruiting API抽出

ステップ

設定

a サンプルクエリ python

Workday Connectorを使用したETLツールによる抽出

ステップ

設定

a サンプルクエリ sql

始める準備はできていますか？

採用のボトルネックを解消：今日からタレントアクイジションを最適化

採用・タレントアクイジション向けデータテンプレート

採用・タレントアクイジション向けデータテンプレート

採用・人材獲得の属性

採用・人材獲得のアクティビティ

抽出ガイド

Workday Report-as-a-Service（RaaS）による抽出

ステップ

設定

a サンプルクエリ sql

PythonスクリプトによるWorkday Recruiting API抽出

ステップ

設定

a サンプルクエリ python

Workday Connectorを使用したETLツールによる抽出

ステップ

設定

a サンプルクエリ sql

始める準備はできていますか？

採用のボトルネックを解消：今日からタレントアクイジションを最適化

プライバシーを大切にしています