> Amélioration continue des processus > Recrutement et acquisition de talents > Workday Recruiting > Modèle de données

Votre modèle de données pour le recrutement et l’acquisition de talents

Workday Recruiting

Attributs du recrutement et de l’acquisition de talents (19) Activités de recrutement et d’acquisition de talents (15) Guides d’extraction (3)

Votre modèle de données pour le recrutement et l’acquisition de talents

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse de vos processus de recrutement et d’acquisition de talents. Il présente les attributs essentiels à recueillir, les activités clés à suivre et les méthodes d’extraction des données depuis Workday Recruiting. Utilisez cette ressource pour préparer vos données plus simplement et commencer plus rapidement votre analyse Process Mining.

Attributs recommandés à recueillir
Activités clés à suivre
Guide d’extraction des données de Workday Recruiting

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du recrutement et de l’acquisition de talents

Voici les champs de données recommandés pour votre journal d’événements. Ils permettent d’analyser en détail le recrutement et l’acquisition de talents.

3 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Description
	Candidature à un poste JobApplicationId	Identifiant unique de la candidature d’une personne à un poste. Il sert d’ID de cas central pour le processus de recrutement.
Description L’identifiant de la candidature permet de suivre le parcours d’une personne pour un poste précis, de la soumission initiale à la décision finale. Chaque interaction, changement de statut ou décision concernant cette candidature est associé à cet identifiant. En Process Mining, cet attribut est fondamental. Il permet de reconstituer le parcours de chaque candidat de bout en bout et d’analyser les temps de cycle, les goulots d’étranglement et les chemins suivis. Il relie toutes les activités associées pour former un cas cohérent. Pourquoi est-ce important ? Cet ID de cas essentiel relie toutes les activités de recrutement concernant une même personne et permet d’analyser l’ensemble de son parcours jusqu’à l’embauche. Où trouver ces données Cet identifiant est un élément central de Workday Recruiting. Il figure généralement dans les rapports et les sources de données liés aux candidatures. Exemples APP-2023-001234APP-2023-005678APP-2024-009101
	Heure de l’événement EventTime	Horodatage indiquant le moment où l’activité ou l’événement s’est produit.
Description Cet attribut enregistre la date et l’heure exactes d’une activité de recrutement. Les horodatages constituent la base du Process Mining, car ils établissent l’ordre chronologique des événements. Lors de l’analyse, ils servent à calculer les délais entre les activités, à mesurer les temps de cycle globaux, comme le délai de recrutement, et à repérer les goulots d’étranglement qui ralentissent le processus. Ils sont indispensables à toute analyse temporelle du processus de recrutement. Pourquoi est-ce important ? Les horodatages sont indispensables au calcul des KPI temporels, à la compréhension de la durée du processus et à la détection des goulots d’étranglement. Où trouver ces données Correspond à la date de fin ou à la date de transaction d’une étape du processus métier dans Workday Recruiting. Exemples 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche qui s’est produit à un moment donné du processus de recrutement.
Description Le nom de l’activité désigne une étape ou un jalon du parcours de recrutement, par exemple « Candidature présélectionnée », « Entretien planifié » ou « Offre envoyée ». Ces activités forment la séquence d’événements qui constitue le processus. Cet attribut est essentiel pour visualiser la cartographie du processus, repérer les différents parcours des candidatures et analyser la fréquence et l’ordre des événements. Il permet de comprendre ce qui se passe dans le processus. Pourquoi est-ce important ? Cet attribut définit les étapes du processus de recrutement et permet de visualiser et d’analyser son déroulement. Où trouver ces données Cet attribut est dérivé des noms des étapes du processus métier ou des changements de statut dans les données de candidature de Workday Recruiting. Exemples Candidature présélectionnéeEntretien terminéOffre acceptéeCandidat refusé
	Nom du recruteur RecruiterName	Nom du recruteur chargé de gérer la candidature.
Description Cet attribut identifie le partenaire chargé de l’acquisition de talents ou le recruteur affecté à la candidature et à la demande de recrutement. Cette personne accompagne généralement le candidat tout au long du processus. L’analyse du processus par recruteur permet de comprendre les résultats de l’équipe et sa charge de travail. Elle sert à créer le Dashboard « Résultats et volume de traitement des recruteurs » et à calculer des KPI comme « Écart du délai entre le recruteur et l’offre », afin de comparer l’efficacité et de repérer les bonnes pratiques. Pourquoi est-ce important ? Permet d’analyser les résultats par recruteur, de repérer les personnes les plus performantes, les besoins de formation et les déséquilibres de charge de travail. Où trouver ces données Consultez la documentation de Workday Recruiting. Cet attribut est généralement associé aux objets Job Requisition ou Job Application. Exemples John SmithEmily JonesMaria Garcia
	Responsable du recrutement HiringManager	Nom du responsable du recrutement pour le poste auquel le candidat a postulé.
Description Cet attribut identifie le responsable de l’équipe ou du service qui propose le poste. Le responsable du recrutement joue un rôle important dans la prise de décision, notamment lors des entretiens et de la transmission des commentaires. Ces données sont essentielles au Dashboard « Respect des délais de retour des responsables du recrutement ». En analysant, pour chaque responsable, le délai entre « Entretien terminé » et « Commentaires soumis », les organisations peuvent repérer les retards et collaborer avec les responsables concernés pour accélérer le processus de recrutement. Pourquoi est-ce important ? Essentiel pour analyser la participation des responsables du recrutement et repérer les retards dans la transmission des commentaires, qui ont une incidence directe sur l’expérience candidat. Où trouver ces données Consultez la documentation de Workday Recruiting. Cet attribut figure généralement dans les détails de l’organisation hiérarchique ou de la demande de recrutement. Exemples Susan AdamsDavid ChenAngela Rodriguez
	Service Department	Service ou unité opérationnelle associé à la demande de recrutement.
Description Cet attribut indique l’unité organisationnelle, par exemple « Ingénierie », « Marketing » ou « Finance », pour laquelle le candidat est recruté. Il est dérivé de l’organisation hiérarchique associée à la demande de recrutement. Dans le cadre d’une analyse, le filtrage par service permet de comparer les processus de recrutement entre différentes parties de l’entreprise. Le Dashboard « Efficacité de la présélection des candidatures » permet de vérifier si certains services ont des délais de présélection plus longs, ce qui peut révéler des pratiques différentes ou des besoins en ressources. Pourquoi est-ce important ? Permet de comparer les résultats et l’efficacité des processus de recrutement entre différents services ou unités opérationnelles. Où trouver ces données Consultez la documentation de Workday Recruiting. Cet attribut est dérivé de l’organisation hiérarchique associée à la demande de recrutement. Exemples IngénierieVentesRessources humainesFinance
	Source de la candidature ApplicationSource	Canal ou source par lequel la candidature a été reçue.
Description Cet attribut indique comment le candidat a découvert le poste et a postulé, par exemple via la page carrières de l’entreprise, LinkedIn, une recommandation d’un employé ou une agence de recrutement. Connaître la source est essentiel pour optimiser la stratégie et le budget de recrutement. Cet attribut alimente le Dashboard « Efficacité des canaux de sourcing » et le KPI « Taux d’acceptation des offres par source », qui permettent de déterminer quels canaux attirent le plus de candidats et les profils les plus qualifiés. Pourquoi est-ce important ? Permet d’évaluer l’efficacité des différents canaux de sourcing et de décider, à partir des données, où investir les ressources consacrées au recrutement. Où trouver ces données Consultez la documentation de Workday Recruiting. Il s’agit d’un champ standard de la candidature. Exemples LinkedInRecommandation d’un employéSite carrières de l’entrepriseIndeed
	Statut de la candidature ApplicationStatus	Résultat final ou état actuel de la candidature.
Description Cet attribut indique l’issue finale d’une candidature, par exemple « Recruté », « Refusé par l’entreprise », « Offre refusée » ou « Candidature retirée ». Il correspond à l’état final du processus pour une candidature donnée. Ce statut est essentiel pour analyser les résultats. Il sert à calculer les taux de conversion et d’acceptation des offres, ainsi que les taux d’abandon des candidats à différentes étapes. Comprendre pourquoi et à quel moment les candidatures prennent fin est indispensable pour améliorer l’efficacité globale du processus. Pourquoi est-ce important ? Définit l’issue de chaque dossier, indispensable au calcul des taux de conversion et d’abandon ainsi qu’à l’évaluation de la réussite globale du processus. Où trouver ces données Il s’agit généralement du champ indiquant l’issue finale ou le motif du statut de l’objet Job Application dans Workday Recruiting. Exemples EmbauchéRefuséOffre refuséeCandidature retirée
	Candidature retirée IsWithdrawn	Indique si le candidat a retiré sa candidature.
Description Cet attribut booléen calculé prend la valeur vraie lorsque le statut final de la candidature est « Retirée par le candidat » ou un statut équivalent. Il permet d’isoler les dossiers dans lesquels le candidat a abandonné le processus. Cet indicateur simplifie l’analyse dans le Dashboard « Points d’abandon des candidats » et pour l’indicateur de taux d’abandon des candidats. Il facilite le filtrage et l’agrégation des données afin de repérer les étapes auxquelles les candidats retirent le plus souvent leur candidature. Pourquoi est-ce important ? Permet d’analyser spécifiquement les abandons à l’initiative des candidats et d’étudier leur expérience ainsi que les points de friction du processus. Où trouver ces données Cet attribut est calculé à partir de l’attribut « ApplicationStatus » lors de la transformation des données. Exemples truefalse
	Délai de recrutement TimeToHire	Durée totale entre la réception d’une candidature et le recrutement du candidat.
Description Ce calcul au niveau du dossier mesure la durée totale du processus de recrutement pour les candidats retenus. Il correspond à l’écart entre l’événement « Candidature reçue » et l’événement « Candidat recruté ». Le délai moyen de recrutement est l’un des indicateurs les plus importants du recrutement. Il donne une mesure globale de l’efficacité du processus. Le suivi de cet indicateur dans le temps et entre les services permet de repérer les améliorations ou les reculs systémiques. Pourquoi est-ce important ? Indicateur clé de haut niveau, il mesure l’efficacité globale du parcours de recrutement, du début à la fin. Où trouver ces données Ce calcul s’effectue à partir des données du journal d’événements extraites de Workday. Exemples 259200043200003456000
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données ou de leur dernière extraction du système source.
Description Cet attribut indique si les données analysées sont à jour. Il précise la date et l’heure de la dernière extraction des données de Workday Recruiting. Il aide les utilisateurs à évaluer l’actualité de l’analyse et à interpréter correctement les résultats, en sachant s’ils consultent des données en temps réel ou un instantané pris à un moment donné. Pourquoi est-ce important ? Indique l’actualité des données et permet aux utilisateurs de savoir dans quelle mesure l’analyse du processus est à jour. Où trouver ces données Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement des données (ETL). Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	Est automatisé IsAutomated	Indique si l’activité a été exécutée automatiquement par le système.
Description Cet attribut booléen indique si une étape a été exécutée par un utilisateur ou automatiquement par le système. Par exemple, l’envoi d’un e-mail confirmant la réception d’une candidature peut être automatisé. Il est important de savoir quelles étapes sont automatisées pour repérer les possibilités d’améliorer l’efficacité. Cela permet d’évaluer l’effet de l’automatisation sur les temps de cycle et la répartition des ressources. Pourquoi est-ce important ? Distingue les activités manuelles de celles exécutées par le système, ce qui permet de repérer les possibilités d’automatisation et d’en mesurer les effets. Où trouver ces données Cette information doit être déduite en repérant les comptes système ou les types d’événements connus comme automatisés dans Workday. Exemples truefalse
	Identifiant de la demande de recrutement JobRequisitionId	Identifiant unique de l’offre d’emploi à laquelle le candidat a postulé.
Description L’identifiant de la demande de recrutement désigne l’offre d’emploi approuvée. Une même demande peut être associée à plusieurs candidatures. Cet attribut permet d’analyser le processus au niveau de la demande. Vous pouvez, par exemple, calculer la durée pendant laquelle une demande est restée ouverte, le nombre de candidats recherchés ou comparer les parcours de recrutement selon le type de poste, par exemple en ingénierie ou dans les ventes. Pourquoi est-ce important ? Associe plusieurs candidatures à une même offre d’emploi et permet d’analyser les indicateurs et les parcours de recrutement au niveau de la demande. Où trouver ces données Il s’agit de l’identifiant principal de l’objet Job Requisition dans Workday Recruiting. Il est associé à chaque candidature. Exemples REQ-2023-105REQ-2024-012REQ-2024-345
	Identifiant du candidat CandidateId	Identifiant unique du candidat.
Description L’identifiant du candidat désigne une personne de manière unique dans le système de recrutement, quel que soit le nombre de postes auxquels elle a postulé. Il permet de suivre son parcours au sein de l’entreprise à travers plusieurs candidatures. Cet attribut est utile pour analyser l’expérience des candidats dans le temps. Il peut, par exemple, aider à repérer les candidats précédemment refusés qui postulent de nouveau et à comparer leurs parcours, ou à savoir si une même personne est étudiée simultanément pour plusieurs postes. Pourquoi est-ce important ? Permet d’analyser le processus du point de vue du candidat en suivant une personne à travers plusieurs candidatures et dans le temps. Où trouver ces données Il s’agit de l’identifiant principal de l’objet Candidate dans Workday Recruiting. Exemples CAND-98765CAND-11223CAND-54321
	Lieu du poste JobLocation	Lieu géographique ou pays du poste.
Description Cet attribut indique la ville, l’État ou le pays où se trouve le poste. Pour les postes à distance, il peut désigner une région ou porter la mention « À distance ». Le lieu constitue un axe d’analyse utile. Il permet de comparer le délai de recrutement et d’autres indicateurs entre différentes régions, et de repérer les écarts liés aux conditions du marché local, à la disponibilité des talents ou aux différences régionales dans le processus. Pourquoi est-ce important ? Permet d’analyser le recrutement par zone géographique et de mettre en évidence les différences régionales de temps de cycle et d’efficacité. Où trouver ces données Cette information figure dans les détails de la demande de recrutement dans Workday. Exemples New York, NYLondres, Royaume-UniÀ distance (États-Unis)Berlin, Allemagne
	Montant de l’offre OfferAmount	Montant du salaire proposé au candidat.
Description Cet attribut indique le montant du salaire de base proposé au candidat dans l’offre d’emploi. Il s’agit d’une information importante dans les dernières étapes du recrutement. L’analyse des montants proposés permet d’étudier les tendances de rémunération et la compétitivité des offres. Associée au statut « Offre acceptée », elle peut aider à déterminer si la rémunération explique les refus. C’est un élément clé du Dashboard « Gestion des offres et taux d’acceptation ». Pourquoi est-ce important ? Permet d’analyser la politique de rémunération et son effet sur les taux d’acceptation des offres. Où trouver ces données Consultez la documentation de Workday Recruiting. Cette information fait partie des données du processus métier « Offer ». Exemples 8500012000065000
	Motif du refus RejectionReason	Motif indiqué lorsque la candidature d’un candidat est refusée.
Description Lorsqu’une candidature passe au statut « Refusé », cet attribut précise le motif de la décision. Il peut s’agir, par exemple, d’une inadéquation avec la culture de l’entreprise, de compétences insuffisantes ou du pourvoi du poste par un autre candidat. L’analyse des motifs de refus permet de repérer des tendances dans le processus de recrutement. Par exemple, un nombre élevé de refus tardifs pour compétences insuffisantes peut révéler une description de poste mal rédigée. Ces données sont essentielles au Dashboard « Points d’abandon des candidats », qui aide à comprendre les raisons de ces abandons. Pourquoi est-ce important ? Apporte des éléments qualitatifs sur les raisons pour lesquelles les candidats ne poursuivent pas le processus, afin d’améliorer les descriptions de poste et les critères de sélection. Où trouver ces données Consultez la documentation de Workday Recruiting. Il s’agit souvent d’un sous-statut ou d’un code de motif associé à l’étape de refus. Exemples Profil non qualifiéExpérience inadéquateCandidats plus adaptés identifiésPoste pourvu
	Système source SourceSystem	Système à partir duquel les données ont été extraites.
Description Cet attribut indique l’origine des données, ici Workday Recruiting. Il facilite la gouvernance des données et la résolution des problèmes, notamment lorsque des données provenant de plusieurs systèmes sont regroupées. Même si cet attribut peut sembler superflu pour l’analyse d’un seul système, il est recommandé de toujours l’inclure. Il confirme la provenance des données et devient essentiel si d’autres systèmes RH sont intégrés par la suite. Pourquoi est-ce important ? Indique l’origine des données, ce qui est essentiel pour leur gouvernance et leur validation, ainsi que pour la gestion de données provenant de plusieurs sources. Où trouver ces données Valeur statique (« Workday Recruiting ») ajoutée lors de l’extraction et de la transformation des données. Exemples Workday Recruiting
	Type de candidat CandidateType	Indique si le candidat est un salarié de l’entreprise ou un candidat externe.
Description Cet attribut classe les candidats dans des catégories telles que « Interne » ou « Externe ». Le processus de recrutement, les délais et les règles peuvent varier considérablement entre ces deux catégories. Analyser séparément les candidatures internes et externes est nécessaire pour obtenir une vue complète. L’organisation peut ainsi mesurer l’efficacité de ses programmes de mobilité interne par rapport à ses recrutements externes et veiller à optimiser les deux processus. Pourquoi est-ce important ? Permet d’analyser séparément les recrutements internes et externes, qui comportent souvent des étapes, des SLA et des objectifs différents. Où trouver ces données Consultez la documentation de Workday Recruiting. Il s’agit d’un champ standard du profil du candidat ou de la candidature. Exemples InterneExterne

Obligatoire Recommandé Facultatif

Activités de recrutement et d’acquisition de talents

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir le processus avec précision et repérer les goulots d’étranglement de votre flux de travail de recrutement.

7 Recommandé 8 Facultatif

	Activité	Description
	Candidat embauché	Marque la fin réussie du processus de recrutement : le candidat est officiellement embauché. Cet événement est enregistré lorsque le processus métier « Hire » se termine avec succès dans Workday et qu’un dossier d’employé est créé.
Pourquoi est-ce important ? Il s’agit de l’événement de fin qui marque la réussite du processus. Son horodatage est essentiel pour calculer le délai de recrutement et mesurer l’efficacité globale du processus ainsi que son taux de réussite. Où trouver ces données Il s’agit d’un événement explicite important, consigné par le processus métier « Hire » dans Workday HCM. Son horodatage de fin figure dans l’historique du processus. Données à recueillir Récupéré à partir de l’horodatage de fin du processus métier « Hire » associé au candidat. Type d’événement explicit
	Candidat passé à l’entretien	Indique que le candidat a franchi la présélection initiale et peut désormais passer un entretien. Cet événement est enregistré lorsque le recruteur fait passer le candidat à l’étape « Interview » du processus de recrutement.
Pourquoi est-ce important ? Cette étape marque le passage de la présélection à l’évaluation active. Elle est importante pour analyser les taux de conversion et l’efficacité du début du processus de recrutement. Où trouver ces données Déduit de l’horodatage du changement d’étape du candidat vers « Interview » ou une étape équivalente dans l’historique de sa candidature. Données à recueillir Repéré grâce au passage du candidat à l’étape « Interview ». Type d’événement inferred
	Candidat passé à l’étape de l’offre	Cette étape importante indique qu’il a été décidé de proposer un poste au candidat. Elle est enregistrée lorsque sa candidature passe à l’étape « Offer » du processus de recrutement.
Pourquoi est-ce important ? Cette activité constitue un point de passage important du processus : elle marque la fin des étapes d’évaluation et précède l’offre officielle. Elle est également utile pour l’analyse par cohorte. Où trouver ces données Déduit de la piste d’audit de la candidature, plus précisément de l’horodatage du passage du statut du candidat à « Offer ». Données à recueillir Repéré grâce au passage du candidat à l’étape « Offer ». Type d’événement inferred
	Candidat refusé	Marque la fin du processus sans embauche, lorsque l’entreprise décide de ne pas poursuivre avec le candidat. Cette étape est déduite du passage du candidat au statut « Rejected » ou « Not Hired » par le recruteur.
Pourquoi est-ce important ? Cet événement de fin est important pour analyser les étapes où les candidats abandonnent et les taux de refus. Il aide à repérer les problèmes liés aux entretiens ou à la présélection. Où trouver ces données Déduit de l’horodatage du passage du statut du candidat à « Rejected » dans l’historique de la candidature. Le motif du refus est souvent également consigné. Données à recueillir Déduit de l’horodatage d’effet du passage au statut « Rejected ». Type d’événement inferred
	Candidature reçue	Marque le début du processus de recrutement pour la candidature d’une personne. Cet événement est enregistré lorsque le candidat soumet avec succès sa candidature à une offre précise via le portail Workday ou un site carrière connecté.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. L’analyse du délai entre cette activité et les étapes suivantes est essentielle pour mesurer le délai total de recrutement et l’efficacité des canaux de sourcing. Où trouver ces données Workday enregistre explicitement cet événement lorsque le processus métier « Apply for Job » se termine avec succès pour un candidat. L’horodatage de l’événement figure dans l’historique de sa candidature. Données à recueillir Récupéré à partir de l’horodatage de soumission de la candidature dans le profil du candidat. Type d’événement explicit
	Offre acceptée	Indique que le candidat a officiellement accepté l’offre d’emploi. Cet événement est enregistré lorsque le candidat termine la tâche « Accept Offer » dans son portail Workday ou lorsqu’un recruteur met manuellement à jour le statut.
Pourquoi est-ce important ? Cette activité est essentielle pour calculer les taux d’acceptation des offres par source, service ou recruteur. Elle déclenche également les activités préalables à l’embauche, comme les vérifications d’antécédents. Où trouver ces données L’acceptation de l’offre par le candidat via son portail est consignée explicitement. L’action est horodatée dans l’historique du processus métier associé à la candidature. Données à recueillir Récupéré à partir de l’horodatage de fin de la tâche « Accept Offer ». Type d’événement explicit
	Offre envoyée	Marque l’envoi officiel d’une offre d’emploi à un candidat. Cet événement distinct est enregistré lorsque le processus métier « Create Offer » ou « Propose Compensation » se termine avec succès pour la candidature dans Workday.
Pourquoi est-ce important ? Cette étape importante sert à calculer le délai jusqu’à l’offre et à analyser le respect du processus d’offre. Elle marque le début de la mesure du taux d’acceptation des offres. Où trouver ces données Cet événement est consigné explicitement dans l’historique du processus métier associé à la candidature. L’horodatage de fin de l’étape de création de l’offre indique le moment de l’activité. Données à recueillir Récupéré à partir de l’horodatage de fin du processus métier « Create Offer ». Type d’événement explicit
	Candidature présélectionnée	Indique que le recruteur ou l’équipe de présélection a terminé l’examen initial de la candidature. Cette étape est généralement déduite du passage du statut « Applied » ou « New » à une étape « Screening » ou « Under Review ».
Pourquoi est-ce important ? Cette activité permet d’analyser l’efficacité de la présélection initiale. Le suivi du volume traité et de la durée aide à repérer rapidement les goulots d’étranglement dans le processus de recrutement. Où trouver ces données Déduit de la date d’effet du changement d’étape du candidat vers une étape de présélection ou d’examen dans la piste d’audit du processus métier « Recruiting ». Données à recueillir Déduit de l’horodatage de la mise à jour de l’étape du candidat vers « Screen ». Type d’événement inferred
	Candidature retirée	Marque la fin du processus lorsque le candidat décide de ne plus postuler au poste. Cet événement est enregistré lorsque son statut passe à « Withdrawn », à son initiative ou à celle d’un recruteur.
Pourquoi est-ce important ? Le suivi du moment et des raisons du retrait des candidatures est essentiel pour comprendre les difficultés liées à l’expérience candidat, la durée du processus ou l’attractivité des offres. C’est une métrique importante pour analyser les abandons. Où trouver ces données Déduit de l’horodatage du passage du statut du candidat à « Withdrawn ». Le candidat peut effectuer cette action dans son portail, ou un recruteur peut la faire à sa place. Données à recueillir Déduit de l’horodatage d’effet du passage au statut « Withdrawn ». Type d’événement inferred
	Commentaires soumis	Indique le moment où un intervieweur soumet officiellement son évaluation du candidat après l’entretien. Workday permet aux intervieweurs de saisir directement leurs commentaires dans le profil du candidat.
Pourquoi est-ce important ? Cette activité est essentielle à l’analyse du respect des délais de retour des responsables du recrutement. Les retards constituent un goulot d’étranglement fréquent ; leur suivi aide à respecter les accords de niveau de service. Où trouver ces données Cet événement est enregistré explicitement lorsque les commentaires sont soumis via la tâche « Provide Interview Feedback ». L’horodatage de la soumission est consigné dans l’enregistrement de l’entretien. Données à recueillir Récupéré à partir de l’horodatage de fin de l’événement « Provide Interview Feedback ». Type d’événement explicit
	Entretien planifié	Indique qu’un entretien avec le candidat a été officiellement planifié. L’événement est généralement enregistré lors de la création et de la confirmation d’un entretien dans la fonctionnalité de planification de Workday, pour la candidature concernée.
Pourquoi est-ce important ? La mesure du délai entre cette activité et les précédentes permet de repérer les retards de coordination. Elle est essentielle pour améliorer l’expérience candidat et accélérer le processus d’entretien. Où trouver ces données La fonctionnalité de planification des entretiens de Workday crée des événements horodatés. Cette activité peut être récupérée à partir de la date de création de l’entretien planifié associé à la candidature. Données à recueillir Récupéré à partir de l’événement de création d’un entretien dans le module de recrutement. Type d’événement explicit
	Entretien terminé	Marque la fin d’un entretien planifié avec un candidat. Cette étape est généralement déduite du passage du statut de l’entretien de « Scheduled » à « Completed » ou « Conducted », effectué par l’intervieweur ou le recruteur.
Pourquoi est-ce important ? Cette activité marque le début du délai de soumission des commentaires. Le temps écoulé entre cette étape et la soumission des commentaires permet de mesurer la réactivité du responsable du recrutement. Où trouver ces données Déduit d’une mise à jour du statut de l’entretien planifié ou d’un changement manuel de l’étape du candidat dans Workday Recruiting, après la tenue de l’entretien. Données à recueillir Déduit de l’horodatage de la mise à jour du statut de l’entretien ou du changement d’étape du candidat après l’entretien. Type d’événement inferred
	Intégration lancée	Marque le lancement du processus d’intégration du nouvel employé dans Workday. Il s’agit généralement d’un événement explicite faisant partie du processus métier principal « Hire » ou déclenché juste après.
Pourquoi est-ce important ? L’analyse du délai entre « Offer Accepted » et cette activité aide à améliorer l’expérience du candidat après l’offre. Elle permet de s’assurer que les nouvelles recrues restent mobilisées et sont prêtes pour leur premier jour. Où trouver ces données Le processus métier « Onboarding » de Workday comporte un horodatage de lancement précis. Celui-ci peut être récupéré dans la piste d’audit du dossier du nouvel employé. Données à recueillir Récupéré à partir de l’horodatage de lancement du processus métier « Onboarding ». Type d’événement explicit
	Vérification des antécédents lancée	Indique le début des vérifications d’antécédents pour un candidat ayant accepté une offre. Cette étape est généralement déduite du passage du candidat à l’étape « Background Check », qui déclenche souvent une intégration avec un prestataire tiers.
Pourquoi est-ce important ? Cette activité est essentielle au suivi de la conformité et à l’analyse des délais entre l’acceptation de l’offre et le début des vérifications préalables à l’embauche. Elle contribue à assurer une transition simple vers l’intégration. Où trouver ces données Déduit de l’horodatage du passage du candidat à l’étape « Background Check » dans le flux de recrutement. La piste d’audit de la candidature indique ce changement de statut. Données à recueillir Déduit de l’horodatage d’effet du passage à l’étape « Background Check ». Type d’événement inferred
	Vérification des antécédents validée	Marque la fin réussie des vérifications d’antécédents. Cet événement est déduit de la mise à jour du statut du candidat indiquant qu’il a satisfait aux vérifications requises et peut être embauché.
Pourquoi est-ce important ? Il s’agit du dernier contrôle avant la finalisation du recrutement. Tout retard dans la réception ou l’enregistrement de cette validation peut repousser la date d’entrée en fonction du candidat. Où trouver ces données Déduit d’une mise à jour du statut de la candidature, par exemple le passage à l’étape « Ready for Hire » ou « Background Check Complete ». Données à recueillir Déduit du changement de statut indiquant que les vérifications d’antécédents sont terminées et validées. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Workday Recruiting

Étapes

Connexion à Workday : accédez à votre environnement Workday avec un compte utilisateur autorisé à créer des rapports personnalisés et à consulter les données de recrutement.
Création d’un rapport personnalisé : accédez à la tâche « Create Custom Report ». Sélectionnez « Advanced » comme type de rapport et activez l’option « Enable as Web Service ». Pour la source de données, choisissez une source indexée, comme « All Job Applications », afin d’obtenir de meilleures performances.
Définition de l’objet métier principal : définissez « Job Application » comme objet métier principal. Cet objet servira de base au rapport et d’identifiant de cas.
Ajout de colonnes de données : ajoutez les champs requis et recommandés à la grille de colonnes du rapport. Ajoutez « Job Application » pour JobApplicationId. Pour les autres attributs, comme « Recruiter » et « Hiring Manager », ajoutez les objets métier associés à la candidature.
Création de champs calculés pour les activités : il s’agit de l’étape la plus importante. Pour chacune des 15 activités, créez deux champs calculés : l’un pour le nom de l’activité et l’autre pour l’horodatage de l’événement. La section Requête détaille la logique à appliquer. Par exemple, pour enregistrer « Offer Extended », créez un champ qui vérifie si le processus métier « Propose Compensation » est terminé, puis un autre qui extrait son horodatage de fin.
Ajout des champs calculés au rapport : ajoutez toutes les colonnes calculées créées (30 au total, soit 15 noms d’activité et 15 horodatages). Le rapport sera au format « large », avec une ligne par candidature et de nombreuses colonnes correspondant aux activités possibles.
Configuration des options du service Web : dans l’onglet « Web Service » de la définition du rapport, vérifiez que la case « Enable as Web Service » est cochée. Vous pouvez consulter ici l’espace de noms et l’URL du rapport. Notez l’espace de noms pour l’utiliser ultérieurement.
Définition des autorisations : partagez le rapport avec un utilisateur système d’intégration (ISU) ou un groupe de sécurité précis qui appellera le point de terminaison RaaS. Cet utilisateur doit avoir accès au domaine de la source de données, par exemple « Recruiting : Job Applications ».
Exécution et vérification du rapport : exécutez le rapport depuis l’interface Workday pour vérifier le résultat. Vérifiez que le nombre de lignes est cohérent et que les champs calculés sont correctement renseignés pour quelques candidatures.
Planification de l’extraction : utilisez un outil de planification externe ou un intergiciel, comme MuleSoft, Boomi ou un script personnalisé, pour appeler régulièrement l’URL RaaS du rapport. L’outil devra gérer l’appel à l’API SOAP ou REST de Workday avec une authentification appropriée.
Transformation des données : le résultat brut de l’appel RaaS sera un fichier XML ou CSV au format large. Vous devez le transformer à l’aide de votre intergiciel ou d’un langage de script comme Python afin de le convertir en format long. Le script doit parcourir chaque ligne (candidature) et créer une ligne dans le journal d’événements final pour chaque paire activité/horodatage non vide. Le résultat comportera trois colonnes principales : JobApplicationId, ActivityName et EventTime.

Configuration

Type de rapport : utilisez toujours « Advanced » pour pouvoir créer des champs calculés complexes et accéder aux objets métier associés.
Source de données : choisissez une source indexée, comme « All Job Applications », pour que le rapport s’exécute efficacement. Évitez les sources non indexées pour les grands jeux de données.
Filtrage par période : il est essentiel de filtrer le champ « Application Date » de l’objet métier Job Application. Commencez par une période plus courte, par exemple les trois à six derniers mois, afin de maîtriser le volume de données et les performances du rapport.
Objet métier principal : l’objet principal doit être « Job Application » pour que JobApplicationId serve d’identifiant de cas.
Activation du service Web : cochez l’option « Enable as Web Service » dans la configuration du rapport pour le rendre accessible par API.
Sécurité et autorisations : le rapport doit être partagé avec un utilisateur système d’intégration (ISU) dédié. Cet ISU doit appartenir à des groupes de sécurité autorisés à accéder aux domaines de données requis, notamment « Recruiting : Job Applications », « Business Process Transactions » et « Worker Data ».
Format de sortie : Workday propose plusieurs formats de sortie (XML, CSV, JSON). Le format XML, et plus précisément « Simple XML », est souvent le plus fiable pour extraire des données structurées par API.

a Exemple de requête 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.

Étapes

Configurez l’accès à Workday : créez un utilisateur système d’intégration (ISU) dans Workday. Accordez-lui l’accès aux domaines de sécurité nécessaires pour l’API Recruiting. Les principaux domaines sont « Worker Data : Public Worker Reports », « Job Application » et « Recruiting : Reports ».
Repérez le point de terminaison de l’API : trouvez, dans votre environnement Workday, le point de terminaison de l’API REST correspondant à l’opération « Get Job Applications ». L’URL suit généralement ce format : https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications.
Configurez l’environnement Python : vérifiez que Python est installé. Installez les bibliothèques nécessaires avec pip : pip install requests pandas.
Créez le script d’authentification : dans votre script Python, configurez l’authentification de base avec les identifiants de l’ISU créé à l’étape 1. Le nom d’utilisateur et le mot de passe seront transmis dans l’en-tête de la requête.
Mettez en place les appels à l’API : écrivez la fonction qui appelle le point de terminaison « Get Job Applications ». Utilisez des paramètres de requête pour filtrer les données, par exemple updatedSince, afin de récupérer les candidatures modifiées après une date donnée. Ce filtrage est essentiel pour maîtriser le volume de données.
Gérez la pagination de l’API : l’API Workday renvoie un nombre limité d’enregistrements par requête. Votre script doit vérifier si la réponse contient un total (total) et un lien vers la page suivante (next) ou un paramètre de décalage, puis parcourir toutes les pages pour récupérer l’ensemble des données.
Définissez l’association des activités : créez un dictionnaire d’association ou une série de conditions dans votre script. Cette logique convertira les statuts des processus métier et les étapes de recrutement de Workday, par exemple « Screen », « Interview », « Offer » et « Hire », en noms d’activité requis, comme « Application Screened » et « Candidate Moved To Interview ».
Transformez les données des candidatures : pour chaque candidature récupérée par l’API, analysez sa piste d’audit ou l’historique de ses étapes. Cet historique contient la séquence des étapes, des décisions et des événements de processus métier, avec leurs horodatages respectifs.
Générez les lignes du journal d’événements : parcourez l’historique de chaque candidature. Pour chaque événement historique pertinent correspondant à l’association définie, créez un dictionnaire représentant une ligne du journal d’événements final. Renseignez JobApplicationId, ActivityName, EventTime et les autres attributs requis.
Rassemblez et structurez les données : regroupez dans une seule liste toutes les lignes du journal d’événements générées pour l’ensemble des candidatures.
Créez et exportez un fichier CSV : utilisez la bibliothèque pandas pour convertir la liste des dictionnaires d’événements en DataFrame, puis exportez le DataFrame dans un fichier CSV. Vérifiez que les en-têtes de colonnes correspondent aux exigences de ProcessMind, par exemple CaseId, Activité et Horodatage.
Vérifiez et importez le fichier : ouvrez le fichier CSV final pour en vérifier l’exactitude et l’exhaustivité avant de l’importer dans l’outil de Process Mining.

Configuration

Utilisateur système d’intégration Workday (ISU) : un ISU doté d’un mot de passe sécurisé et sans date d’expiration est requis. Il doit avoir accès aux domaines de sécurité « Recruiting » et « Worker Data » pour consulter les candidatures et les informations sur les candidats.
Point de terminaison et version de l’API : utilisez le point de terminaison REST correspondant à votre environnement Workday. Précisez la version de l’API dans la requête pour garantir un comportement cohérent.
Filtre de période : le script doit utiliser un filtre de date, par exemple updatedSince, pour limiter la requête à une période gérable. Pour les premières extractions, une période de trois à six mois est recommandée. Pour les chargements différentiels suivants, utilisez l’horodatage de la dernière extraction réussie.
Limite de pagination : tenez compte du paramètre limit de l’API, qui détermine le nombre d’enregistrements renvoyés par page. La limite maximale habituelle est de 100. Le script doit gérer cette contrainte en effectuant plusieurs requêtes paginées.
Champs de la réponse : pour améliorer les performances, vous pouvez préciser les champs à renvoyer à l’aide du paramètre fields ou d’un paramètre équivalent, si l’API le permet. Cela réduit la taille de la réponse.
Configuration de l’association des activités : la logique centrale du script consiste à associer les étapes Workday aux activités définies. Vous devrez peut-être l’adapter à la configuration du processus de recrutement Workday propre à votre organisation.

a Exemple de requête 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.")

Étapes

Prérequis et configuration : assurez-vous de disposer d’une licence pour un outil ETL ou iPaaS tiers, comme CData, MuleSoft ou une plateforme similaire, et d’y avoir installé son connecteur Workday. Vérifiez que vous avez les identifiants d’un utilisateur système d’intégration Workday (ISU) disposant des autorisations API nécessaires pour les domaines Recruiting et Staffing.
Configuration de la connexion Workday : créez une nouvelle connexion à Workday dans votre outil ETL. Indiquez l’URL de votre environnement Workday, la version de l’API et les identifiants de l’ISU, par exemple son nom d’utilisateur et son mot de passe ou des jetons OAuth 2.0. Testez la connexion pour vérifier qu’elle fonctionne.
Exploration du schéma de données : utilisez l’explorateur de schéma ou de sources de données de votre outil ETL pour consulter les objets Workday accessibles par le connecteur. Ils se présentent généralement sous forme de tables ou de vues, comme Job_Application, Job_Requisition et Candidate_Stage_History. Repérez les champs et les relations disponibles.
Repérage des objets de données clés : pour cette extraction, vous aurez principalement besoin des données relatives aux candidatures, à l’historique des candidats, aux entretiens, aux offres et aux embauches. Les noms exacts dépendent de votre connecteur. Recherchez les objets correspondant à ces entités principales.
Création de la requête SQL : créez une tâche ou un pipeline d’extraction. Ajoutez une étape de transformation SQL pour exécuter une requête sur la connexion Workday, puis copiez-y la requête SQL fournie. Elle est conçue pour récupérer des données issues de plusieurs objets Workday et les réunir dans un journal d’événements unique.
Paramétrage de la requête : modifiez la clause WHERE de la requête pour ajouter des paramètres de période, par exemple startDate et endDate. Configurez-les dans votre tâche ETL afin de pouvoir modifier facilement la période d’extraction sans changer le code.
Exécution de la tâche d’extraction : lancez la tâche ETL configurée. L’outil se connectera à Workday, exécutera la requête SQL via l’API et récupérera les données dans une zone de préparation ou en mémoire.
Vérification et validation des données : avant d’écrire le résultat final, utilisez l’aperçu de votre outil ETL pour examiner les données. Vérifiez que le nombre de lignes est cohérent, que toutes les colonnes sont renseignées comme prévu et que les différentes activités sont présentes.
Configuration de la destination : définissez la destination des données extraites. Il s’agit généralement d’un fichier CSV à importer dans ProcessMind. Configurez le nom du fichier, le séparateur (virgule) et l’encodage (UTF-8).
Finalisation et exportation : exécutez la tâche d’extraction complète pour générer le fichier CSV final. Vérifiez que ses en-têtes de colonnes correspondent aux attributs requis : JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Department et ApplicationStatus.

Configuration

Identifiants du connecteur Workday : la connexion nécessite l’URL de votre environnement Workday et un utilisateur système d’intégration (ISU) autorisé, avec un mot de passe ou des identifiants client OAuth 2.0. Cet utilisateur doit disposer des autorisations de sécurité pour les domaines fonctionnels « Recruiting » et « Staffing ».
Activation du service Web : le connecteur peut vous demander de préciser les services Web Workday à exposer. Vérifiez que les services liés au recrutement, à la gestion du personnel et aux ressources humaines sont activés afin d’accéder à tous les objets de données nécessaires.
Période : pour maîtriser les performances et le volume de données, il est essentiel de limiter l’extraction à une période précise. Nous recommandons un premier chargement de trois à six mois de données, suivi de chargements incrémentiels quotidiens ou hebdomadaires. Cette période se définit dans la clause WHERE de la requête SQL.
Filtres de périmètre des données : si vous souhaitez analyser le processus pour certaines parties de l’organisation uniquement, ajoutez dans la clause WHERE des filtres portant sur des champs comme Company, Cost Center ou Supervisory Organization.
Version de l’API : certains connecteurs vous demandent de préciser la version de l’API Workday. Il est préférable d’utiliser une version récente et prise en charge pour accéder aux objets de données et aux fonctionnalités les plus récents.
Performances : les extractions complètes de Workday peuvent mobiliser beaucoup de ressources. Planifiez les tâches volumineuses en dehors des heures de pointe. Pour les analyses récurrentes, mettez en place un chargement incrémentiel fondé sur l’horodatage de dernière modification afin de ne récupérer que les enregistrements nouveaux ou modifiés.

a Exemple de requête 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]'

Prêt à commencer ?

Utilisez ce modèle pour transformer vos données d’acquisition de talents en analyses concrètes et améliorer l’efficacité de vos recrutements. Commencez dès aujourd’hui à optimiser votre processus de recrutement.

Retour au guide d’amélioration Télécharger le modèle

Mettez fin aux goulots d’étranglement du recrutement : optimisez votre processus dès aujourd’hui

Repérez les inefficacités, réduisez de 30 % le temps de cycle du recrutement et atteignez plus rapidement vos objectifs de recrutement.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

Votre modèle de données pour le recrutement et l’acquisition de talents

Votre modèle de données pour le recrutement et l’acquisition de talents

Attributs du recrutement et de l’acquisition de talents

Activités de recrutement et d’acquisition de talents

Guides d’extraction

Extraction des rapports Workday en tant que service (RaaS)

Étapes

Configuration

a Exemple de requête sql

Extraction des données de recrutement Workday par API avec un script Python

Étapes

Configuration

a Exemple de requête python

Extraction avec un outil ETL et un connecteur Workday

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Mettez fin aux goulots d’étranglement du recrutement : optimisez votre processus dès aujourd’hui

Votre modèle de données pour le recrutement et l’acquisition de talents

Votre modèle de données pour le recrutement et l’acquisition de talents

Attributs du recrutement et de l’acquisition de talents

Activités de recrutement et d’acquisition de talents

Guides d’extraction

Extraction des rapports Workday en tant que service (RaaS)

Étapes

Configuration

a Exemple de requête sql

Extraction des données de recrutement Workday par API avec un script Python

Étapes

Configuration

a Exemple de requête python

Extraction avec un outil ETL et un connecteur Workday

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Mettez fin aux goulots d’étranglement du recrutement : optimisez votre processus dès aujourd’hui

Nous respectons votre vie privée

Prêt à commencer ?

Mettez fin aux goulots d’étranglement du recrutement : optimisez votre processus dès aujourd’hui