> Amélioration Continue des Processusus > Recrutement et acquisition de talents > Workday Recruiting > Template de données

Votre modèle de données de recrutement et d'acquisition de talents

Workday Recruiting

← Retour au Guide d'amélioration

Attributs de Recrutement et acquisition de talents (19) Activités de Recrutement et acquisition de talents (15) Guides d'extraction (3)

Votre modèle de données de recrutement et d'acquisition de talents

Ce modèle fournit un guide détaillé pour la collecte des `données` nécessaires à l'analyse de vos processus de recrutement et d'acquisition de talents. Il décrit les attributs essentiels à collecter, les activités clés à suivre et offre des conseils sur la manière d'extraire ces `données` de votre système Workday Recruiting. Utilisez cette ressource pour simplifier la préparation de données et accélérer votre parcours de `Process Mining`.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour Workday Recruiting

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de Recrutement et acquisition de talents

Ce sont les champs de données recommandés à inclure dans votre `Journal d'événements` pour une analyse complète du recrutement et de l'acquisition de talents, permettant des `insights` approfondis sur votre processus d'embauche.

3 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Descriptionn
	Candidature au Poste JobApplicationId	L'identifiant unique d'une candidature, servant d'ID de cas central pour le processus de recrutement.
Descriptionn L'ID de Candidature suit de manière unique le parcours d'un seul candidat pour une demande de poste spécifique, de la soumission initiale à la décision finale. Chaque interaction, changement de statut ou point de décision lié à cette candidature est rattaché à cet identifiant. En `Process Mining`, cet attribut est clé. Il permet la reconstruction du flux de processus complet de chaque candidat, permettant l'analyse des temps de cycle, des `points de blocage` et des chemins parcourus. C'est l'élément central qui connecte toutes les activités connexes en un `case` cohérent. Pourquoi est-ce important ? : C'est l'ID de `Case` essentiel qui connecte toutes les activités de recrutement pour un seul candidat, permettant l'analyse de l'ensemble du parcours d'embauche. Source des données : Cet identifiant est un élément central dans Workday Recruiting, généralement disponible dans les rapports et les sources de données liées aux candidatures. Exemples APP-2023-001, 2, 3, 4APP-2023-005678APP-2024-009101
	Heure de l'événement EventTime	L'horodatage indiquant quand l'activité ou l'événement s'est produit.
Descriptionn Cet `attribut` enregistre la date et l'heure exactes auxquelles une activité de recrutement spécifique a eu lieu. Les `horodatages` sont l'pilier central du `Process Mining`, fournissant l'ordre chronologique des `events`. Dans l'analyse, les `horodatages` sont utilisés pour calculer les durées entre les activités, mesurer les temps de cycle globaux comme le 'Time to Hire' et identifier les `points de blocage` où le processus est retardé. Ils sont essentiels pour toute analyse basée sur le temps de l'entonnoir de recrutement. Pourquoi est-ce important ? : Les `horodatages` sont critiques pour calculer tous les KPI basés sur le temps, comprendre la durée des processus et découvrir les `points de blocage`. Source des données : Ceci correspond à la date d'achèvement ou à la date de transaction d'une étape de 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	Le nom de l'événement ou de la tâche spécifique qui s'est produit à un moment donné du processus de recrutement.
Descriptionn Le nom de l'activité décrit une étape unique ou un jalon dans le parcours d'embauche, comme 'Candidature présélectionnée', 'Entretien planifié' ou 'Offre émise'. Ces activités forment la séquence des événements qui constituent le processus. Cet attribut est impératif pour visualiser la cartographie des processus, identifier les différents chemins que prennent les candidatures et analyser la fréquence et l'ordre des événements. Il est la base pour comprendre ce qui se passe dans le processus. Pourquoi est-ce important ? : Cet `attribut` définit les étapes du processus de recrutement, pour visualiser et l'analyse du flux de processus. Source des données : Ceci est dérivé des noms d'étapes de processus métier ou des changements de statut danss `données` de candidature de Workday Recruiting. Exemples Demande examinéeEntretien terminéOffre acceptéeCandidat rejeté
	Département Department	Le département ou l'unité commerciale associée à la demande de poste.
Descriptionn Cet `attribut` spécifie l'unité organisationnelle, telle que 'Ingénierie', 'Marketing' ou 'Finance', pour laquelle le candidat est embauché. Il est dérivé de l'organisation de supervision associée à la demande de poste. Dans l'analyse, le filtrage par département permet de comparer les processus d'embauche entre différentes parties de l'entreprise. Il est utilisé dans le `Tableau de bord` 'Efficacité de la présélection des candidatures' pour voir si certains départements ont des temps de prélèvement.sélection plus longs, indiquant potentiellement des pratiques ou des besoins en ressources différents. Pourquoi est-ce important ? : Permet de comparer la performance et l'efficacité du processus de recrutement entre différentes unités commerciales ou départements. Source des données : Consultez la documentation Workday Recruiting. Ceci est dérivé de l'Organisation hiérarchique liée à la Demande de poste. Exemples IngénierieVentesRessources HumainesFinance
	Nom du recruteur RecruiterName	Le nom du recruteur responsable de la gestion de la candidature.
Descriptionn Cet `attribut` identifie le partenaire principal d'acquisition de talents ou le recruteur assigné à la candidature et à la demande de poste. Il est généralement responsable de guider le candidat tout au long du processus. Analyser le processus par recruteur est indispensable pour comprendre la performance et la charge de travail de l'équipe. Il aide à construire le `Tableau de bord` 'Performance et débit des recruteurs' et à calculer des KPI comme 'Variation du délai d'offre du recruteur', permettant des comparaisons d'efficacité et l'identification des meilleures pratiques. Pourquoi est-ce important ? : Permet une analyse de la performance par recruteur, aidant à identifier les performants, les besoins en formation et les déséquilibres de charge de travail. Source des données : Consultez la documentation Workday Recruiting. Ceci est généralement lié aux objets Demande de poste ou Candidature. Exemples John SmithEmily JonesMaria Garcia
	Responsable du recrutement HiringManager	Le nom du responsable du recrutement pour le poste auquel le candidat a postulé.
Descriptionn Cet `attribut` identifie le responsable.able de l'équipe ou du département avec le poste ouvert. Le responsable du recrutement est un acteur clé dans le processus de prise de décision, en particulier pendant les entretiens et les étapes de `feedback`. Ces `données` sont essentielles pour le `Tableau de bord` 'Délais de feedback des responsables du recrutement'. En analysant le temps entre 'Entretien terminé' et 'Feedback soumis' par responsable du recrutement, les organisations peuvent identifier les retards et travailler avec des responsables spécifiques pour accélérer la boucle de recrutement. Pourquoi est-ce important ? : Primordial pour analyser l'engagement du manager recruteur et identifier les retards dans la soumission des feedbacks, ce qui influence l'expérience candidat. Source des données : Consultez la documentation Workday Recruiting. Ceci fait généralement partie des détails de l'organisation hiérarchique ou de la demande de poste. Exemples Susan AdamsDavid ChenAngela Rodriguez
	Source de la candidature ApplicationSource	Le canal ou la source par laquelle la candidature du candidat a été reçue.
Descriptionn Cet `attribut` indique comment un candidat a découvert et postulé pour le poste, par exemple, via la page carrières de l'entreprise, LinkedIn, une recommandation d'employé ou une agence de recrutement. Comprendre la source est indispensable à optimiser la stratégie et le budget de recrutement. Il alimente le `Tableau de bord` 'Efficacité des canaux de sourcing' et le KPI 'Taux d'acceptation des offres par source', aidant à déterminer quels canaux produisent le plus et les meilleurs candidats. Pourquoi est-ce important ? : Aide à évaluer l'efficacité des différents canaux de sourcing, permettant des décisions basées sur les données quant à l'endroit où investir les ressources de recrutement. Source des données : Consultez la documentation Workday Recruiting. Il s'agit d'un champ standard sur la candidature. Exemples LinkedInRecommandation d'employéSite carrières de l'entrepriseIndeed
	Statut de la demande ApplicationStatus	Le résultat final ou l'état actuel de la candidature.
Descriptionn Cet `attribut` enregistre la décision finale d'une candidature, telle que 'Embauché', 'Rejeté par l'entreprise', 'Offre refusée' ou 'Retiré par le candidat'. Il représente l'état terminal du processus pour une application donnée. Ce statut est indispensable pour l'analyse des résultats. Il est utilisé pour calculer les taux de conversion, les taux d'acceptation des offres et les taux d'abandon de candidats à différentes étapes. Comprendre pourquoi et où les candidatures se terminent est indispensable pour améliorer l'efficacité globale du processus. Pourquoi est-ce important ? : Définit l'issue de chaque cas, ce qui est indispensable pour calculer les taux de conversion, les taux d'abandon et le succès global du processus. Source des données : Il s'agit généralement du champ de décision finale ou de raison du statut sur l'objet Candidature dans Workday Recruiting. Exemples EmbauchéRejetéOffre refuséeDemande retirée
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation ou extraction des données du système source.
Descriptionn Cet `attribut` indique la fraîcheur des `données` analysées. Il affiche la date et l'heure de la dernière extraction de données de Workday Recruiting. C'est important pour que les utilisateurs comprennent à quel point l'analyse est actuelle. Cela les aide à interpréter correctement les résultats, sachant s'ils consultent des `données` en temps réel ou un instantané d'un moment précis. Pourquoi est-ce important ? : Fournit un contexte sur la la réactualisation des données, garantissant que les utilisateurs comprennent à quel point l'analyse du processus est à jour. Source des données : Ce `horodatage` est généré et ajouté pendant le 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	Un indicateur signalant si l'activité a été effectuée automatiquement par le système.
Descriptionn Cet `attribut` booléen identifie si une étape a été exécutée par un utilisateur ou par un processus système automatisé. Par exemple, un e-mail de confirmation initial 'Candidature reçue' pourrait être une activité automatisée. Comprendre quelles étapes sont automatisées est important pour identifier les opportunités d'accroître l'efficacité. Cela aide à évaluer l'impact de l'automatisation sur les temps de cycle et l'allocation des ressources. Pourquoi est-ce important ? : Distingue les activités manuelles des activités automatisées, ce qui est indispensable pour identifier les opportunités d'automatisation et mesurer leur impact. Source des données : Ces informationsns doivent être dérivées en identifiant les comptes utilisateur système ou les types d'`events` spécifiques connus pour être automatisés dans Workday. Exemples truefaux
	Est retiré IsWithdrawn	Un indicateur qui signale si la candidature a été retirée par le candidat.
Descriptionn C'est un `attribut` booléen calculé qui est vrai si le statut final de la candidature est 'Retiré par le candidat' ou un état similaire. Il aide à isoler les `cases` où le candidat s'est retiré du processus. Ce drapeau simplifie l'analyse pour le `Tableau de bord` 'Points chauds d'abandon de candidats' et le KPI 'Taux d'abandon de candidats'. Il permet un filtrage et une agrégation faciles pour comprendre à quelles étapes les candidats sont les plus susceptibles de se retirer. Pourquoi est-ce important ? : Aide à analyser spécifiquement les abandons initiés par les candidats, fournissant des insights sur l'expérience candidat et les points de blocage du processus. Source des données : Ceci est calculé basé sur l'`attribut` 'ApplicationStatus' pendant la transformation des `données`. Exemples truefaux
	ID Candidat CandidateId	L'identifiant unique du candidat.
Descriptionn L'ID Candidat identifie de manière unique un individu dans le système de recrutement, quel que soit le nombre de postes auxquels il a postulé. Cela permet de suivre l'historique d'un candidat avec l'entreprise à travers plusieurs candidatures. Cet attribut est utile pour analyser l'expérience candidat au fil du temps. Par exemple, il peut aider à identifier si des candidats précédemment rejetés repostulent et comment leurs parcours diffèrent, ou si un seul candidat est envisagé pour plusieurs rôles simultanément. Pourquoi est-ce important ? : Permet une vision centrée sur le candidat du processus, en suivant un individu à travers plusieurs candidatures et dans le temps. Source des données : C'est l'identifiant principal de l'objet Candidat dans Workday Recruiting. Exemples CAND-98765CAND-11223CAND-54321
	ID de la demande d'emploi JobRequisitionId	L'identifiant unique de l'offre d'emploi à laquelle le candidat a postulé.
Descriptionn L'ID de Demande de poste est l'identifiant de l'ouverture de poste approuvée. Une seule demande peut avoir de nombreuses candidatures associées. Cet attribut permet une analyse au niveau de la demande. Par exemple, on peut analyser le temps total qu'une demande a été ouverte, le nombre de candidats trouvés, ou comparer les entonnoirs de recrutement pour différents types de postes (par exemple, les demandes d'ingénierie vs. de vente). Pourquoi est-ce important ? : Lie plusieurs candidatures à une seule offre d'emploi, permettant l'analyse des métriques au niveau de la demande de poste et des entonnoirs de recrutement. Source des données : C'est un identifiant principal sur l'objet Demande de poste dans Workday Recruiting et est lié à chaque candidature. Exemples REQ-2023-105REQ-2024-012REQ-2024-345
	Lieu du poste JobLocation	Le lieu géographique ou le pays de l'emploi.
Descriptionn Cet `attribut` spécifie la ville, l'état ou le pays où est basé le poste. Pour les postes à distance, il peut indiquer une région ou être marqué comme 'À distance'. La localisation est une dimension puissante pour l'analyse. Elle permet de comparer le 'Time to Hire' et d'autres KPI dans différentes régions, ce qui peut révéler des variations dues aux conditions du marché local, à la disponibilité des talents ou aux différences de processus régionaux. Pourquoi est-ce important ? : Permet une analyse géographique du processus de recrutement, mettant en évidence les différences régionales en termes de temps de cycle et d'efficacité. Source des données : Ces informationsns font partie des détails de la Demande de poste dans Workday. Exemples New York, NYLondres, Royaume-UniÀ distance (États-Unis)Berlin, Allemagne
	Montant de l'offre OfferAmount	Le montant du salaire offert au candidat.
Descriptionn Cet `attribut` contient la valeur du salaire de base proposé à un candidat dans l'offre d'emploi. C'est une `donnée` critique dans les dernières étapes du processus de recrutement. L'analyse des montants des offres peut fournir des `insights` sur les tendances de rémunération et la compétitivité. Combiné au statut 'Offre acceptée', il peut aider à déterminer si la rémunération est un facteur dans les refus d'offres. Il est indispensable pour le `Tableau de bord` 'Taux de gestion et d'acceptation des offres'. Pourquoi est-ce important ? : Aide à analyser la stratégie de rémunération et son impact sur les taux d'acceptation des offres. Source des données : Consultez la documentation Workday Recruiting. Cela ferait partie des données du processus métier 'Offer'. Exemples 8500012000065000
	Motif de refus RejectionReason	La raison fournie lorsque la candidature d'un candidat est rejetée.
Descriptionn Lorsqu'une candidature passe au statut 'Rejeté', cet `attribut` fournit un contexte à la décision. Les raisons peuvent inclure 'Non adapté à la culture', 'Manque de compétences requises' ou 'Poste pourvu par un autre candidat'. L'analyse des raisons de rejet aide à identifier des schémas dans le processus d'embauche. Par exemple, un nombre élevé de rejets pour 'Manque de compétences requises' à un stade avancé peut indiquer une description de poste mal rédigée. Ces `données` sont essentielles pour le `Tableau de bord` 'Points chauds d'abandon de candidats' afin de comprendre le 'pourquoi' des abandons. Pourquoi est-ce important ? : Fournit des `insights` qualitatifs sur les raisons pour lesquelles les candidats ne progressent pas, aidant à améliorer les descriptions de poste et les critères de prélèvement.sélection. Source des données : Consultez la documentation Workday Recruiting. Il s'agit souvent d'un sous-statut ou d'un code de motif associé à l'étape de rejet. Exemples Non qualifiéInadéquation de l'expérienceMeilleurs candidats identifiésPoste pourvu
	Système source SourceSystem	Le système d'où les données ont été extraites.
Descriptionn Cet `attribut` identifie l'origine des `données`, qui dans ce cas est Workday Recruiting. Il aide à la gouvernance des `données` et au dépannage, en particulier lorsque des `données` provenant de plusieurs systèmes sont combinées. Même si cela peut sembler trivial dans une analyse à système unique, c'est une bonne pratique de toujours l'inclure. Cela confirme la provenance des `données` et devient critique si d'autres systèmes RH sont intégrés ultérieurement. Pourquoi est-ce important ? : Identifie l'origine des données, ce qui est impératif pour la gouvernance des données, la validation et la gestion des données provenant de multiples sources. Source des données : C'est une valeur statique ('Workday Recruiting') ajoutée pendant le processus d'extraction et de transformation des `données`. Exemples Workday Recruiting
	Temps d'embauche TimeToHire	Le temps total entre la réception d'une candidature et l'embauche du candidat.
Descriptionn Il s'agit d'un calcul au niveau du `case` qui mesure la durée totale du processus de recrutement pour les candidats retenus. Il est calculé comme la différence de temps entre l'`event` 'Candidature reçue' et l'`event` 'Candidat embauché'. C'est l'un des KPI les plus importants en recrutement ('Délai moyen d'embauche'). Il fournit une mesure de haut niveau de l'efficacité globale du processus d'embauche. Le suivi de cette métrique dans le temps et à travers les départements aide à identifier les améliorations ou régressions systémiques. Pourquoi est-ce important ? : Un KPI clé de haut niveau qui mesure l'efficacité globale de l'entonnoir de recrutement du début à la fin. Source des données : Ceci est calculé à partir des `données` de l'`Journal d'événements` après leur extraction de Workday. Exemples 259200043200003456000
	Type de candidat CandidateType	Indique si le candidat est un employé interne ou un postulant externe.
Descriptionn Cet `attribut` catégorise les candidats en groupes tels que 'Interne' ou 'Externe'. Le processus d'embauche, les délais et les politiques peuvent différer considérablement entre ces deux types. Analyser le processus séparément pour les candidats internes et externes est impératif pour une vision globale. Cela permet à l'organisation de mesurer l'efficacité de ses programmes de mobilité interne par rapport aux efforts de recrutement externes et de garantir l'optimisation des deux processus. Pourquoi est-ce important ? : Permet une analyse séparée des processus d'embauche internes et externes, qui ont souvent des étapes, des SLAs et des objectifs différents. Source des données : Consultez la documentation Workday Recruiting. Il s'agit d'un champ standard sur le profil du candidat ou la candidature. Exemples InterneExterne

Obligatoire Recommandé Facultatif

Activités de Recrutement et acquisition de talents

Ce sont les étapes de processus et les jalons clés à capturer dans votre `Journal d'événements` pour une découverte précise des processus et l'identification des `points de blocage` dans votre `workflow` de recrutement.

7 Recommandé 8 Facultatif

	Activité	Descriptionn
	Candidat embauché	La conclusion réussie du processus de recrutement, où le candidat est formellement embauché en tant qu'employé. Cela est enregistré lorsque le processus métier 'Embauche' est mené à bien dans Workday, créant un dossier d'employé.
Pourquoi est-ce important ? : C'est l'`event` de fin de succès principal. Le `horodatage` est indispensable pour calculer le 'Time to Hire' et mesurer l'efficacité globale du processus et les taux de succès. Source des données : C'est un `event` majeur et explicite enregistré par le processus métier 'Embauche' dans Workday HCM. Le `horodatage` d'achèvement est enregistré dans l'historique du processus. Capture Capturé à partir de l'horodatage d'achèvement du processus métier 'Hire' pour le candidat. Type d'événement explicit
	Candidat passé à l'étape de l'offre	Une étape clé indiquant que la décision a été prise de faire une offre d'emploi au candidat. Cette information est enregistrée lorsque la candidature du candidat est avancée à l'étape 'Offer' du processus de recrutement.
Pourquoi est-ce important ? : Cette activité est une étape critique du processus, marquant l'achèvement réussi de toutes les phases d'évaluation. C'est un précurseur de l'offre formelle et un point clé pour l'analyse de cohorte. Source des données : Déduit du journal d'audit de la candidature, spécifiquement du horodatage où le statut du candidat passe à 'Offre'. Capture Identifié par le changement de statut vers une étape 'Offer' dans la progression du candidat. Type d'événement inferred
	Candidat passé en entretien	Indique qu'un candidat a réussi la présélection initiale et est maintenant admissible à un entretien. Cet événement est enregistré lorsqu'un recruteur fait passer le candidat à l'étape 'Entretien' du processus de recrutement.
Pourquoi est-ce important ? : Ce jalon marque la transition de la présélection à l'évaluation active. C'est un point clé pour analyser les taux de conversion et l'efficacité du haut de l'entonnoir de recrutement. Source des données : Déduit du horodatage où l'étape de recrutement du candidat est modifiée en 'Entretien' ou une désignation similaire dans l'historique de la candidature. Capture Identifié par le changement de statut vers une étape 'Interview' dans la progression du candidat. Type d'événement inferred
	Candidat rejeté	Marque une fin infructueuse au processus où l'entreprise décide de ne pas retenir un candidat. Cela est déduit lorsqu'un recruteur fait passer le candidat au statut 'Rejeté' ou 'Non embauché'.
Pourquoi est-ce important ? : C'est un `event` final critique pour analyser les zones critiques d'abandon de candidats et les taux de rejet à différentes étapes. Il aide à identifier les problèmes dans le processus d'entretien ou de prélèvement.sélection. Source des données : Déduit du horodatage où la décision concernant le candidat est modifiée en 'Rejeté' dans l'historique de la candidature. Une raison de rejet est souvent également enregistrée. Capture Dérivé de l'horodatage effectif du passage à une disposition 'Rejected'. Type d'événement inferred
	Candidature reçue	Marque le début du processus de recrutement pour la candidature d'un candidat. Cet événement est enregistré lorsqu'un candidat soumet avec succès sa candidature pour une demande de poste spécifique via le portail Workday ou un site carrière intégré.
Pourquoi est-ce important ? : C'est l'`event` de départ principal du processus. L'analyse du temps écoulé entre cette activité et les jalons ultérieurs est clée pour mesurer le 'Time to Hire' global et l'efficacité du canal de sourcing. Source des données : Workday enregistre ceci comme un `event` explicite lorsque le processus métier 'Postuler à un emploi' se termine avec succès pour un candidat. Le `horodatage` de l'`event` est disponibleble dans l'historique de candidature du candidat. Capture Capturé à partir de l'horodatage de soumission de la candidature dans le profil du candidat. Type d'événement explicit
	Offre acceptée	Représente l'acceptation formelle de l'offre d'emploi par le candidat. Cet événement est enregistré lorsque le candidat termine la tâche 'Accepter l'offre' dans son portail Workday, ou lorsqu'un recruteur met à jour manuellement le statut.
Pourquoi est-ce important ? : Cette activité est indispensablele pour calculer les taux d'acceptation d'offres par source, département ou recruteur. Elle déclenche également les activités de prélèvement.-embauche ultérieures telles que les vérifications d'antécédents. Source des données : Comptabilisé explicitement lorsqu'un candidat accepte l'offre via son portail candidat. L'action est enregistrée avec un horodatage dans l'historique du processus métier de la candidature. Capture Capturé à partir de l'horodatage d'achèvement de la tâche 'Accept Offer'. Type d'événement explicit
	Offre proposée.	Marque l'émission formelle d'une offre d'emploi à un candidat. Il s'agit d'un événement discret enregistré lorsque le processus métier 'Créer une offre' ou 'Proposer une rémunération' est mené à bien pour la candidature dans Workday.
Pourquoi est-ce important ? : C'est un jalon majeur utilisé pour calculer le délai d'offre et analyser la `conformité` du processus d'offre. C'est le point de départ pour mesurer les taux d'acceptation d'offres. Source des données : Cet `event` est explicitement enregistré dans l'historique du processus métier pour la candidature. Le `horodatage` d'achèvement de l'étape de création de l'offre fournit le temps d'activité. Capture Capturé à partir de l'horodatage d'achèvement du processus métier 'Create Offer'. Type d'événement explicit
	Demande examinée	Représente l'achèvement de l'examen initial de la candidature d'un candidat par un recruteur ou une équipe de prélèvement.sélection. Cela est généralement déduit lorsque le candidat passe d'un statut 'Candidat' ou 'Nouveau' à une étape de 'Présélection' ou 'En cours d'examen'.
Pourquoi est-ce important ? : Cette activité est indispensablele pour analyser l'efficacité de la phase de prélèvement.sélection initiale. Le suivi de son débit et de sa durée aide à identifier les `points de blocage` tôt dans l'entonnoir de recrutement. Source des données : Déduit de la date d'entrée en vigueur du changement d'étape du candidat vers une étape de prélèvement.sélection ou d'examen dans le journal d'audit du processus métier 'Recrutement'. Capture Dérivé de l'horodatage lorsque l'étape du candidat est mise à jour à 'Screen'. Type d'événement inferred
	Demande retirée	Un événement final où le candidat se retire volontairement de la considération pour le poste. Cette information est enregistrée lorsque le statut du candidat est mis à jour à 'Withdrawn', soit par lui-même, soit par un recruteur.
Pourquoi est-ce important ? : Suivre quand et pourquoi les candidats se retirent est impératif pour comprendre les problèmes d'expérience candidat, la durée du processus ou la compétitivité des offres. C'est une métrique clé pour l'analyse des abandons. Source des données : Déduit du horodatage où la décision concernant le candidat est mise à jour en 'Retiré'. Cela peut être fait par le candidat dans son portail ou par un recruteur. Capture Dérivé de l'horodatage effectif du passage à une disposition 'Withdrawn'. Type d'événement inferred
	Entretien planifié.	Représente la planification formelle d'un entretien avec le candidat. Cela est généralement enregistré lorsqu'un événement d'entretien est créé et confirmé dans la fonctionnalité de planification de Workday pour la candidature spécifique.
Pourquoi est-ce important ? : Mesurer le temps entre cette activité et les précédentes aide à identifier les retards de coordination. C'est impératif pour améliorer l'expérience candidat et accélérer le processus d'entretien. Source des données : La fonction de planification d'entretiens de Workday crée des `events` avec des `horodatages`. Cette activité peut être capturée à partir de la date de création de l'entretien planifié lié à la candidature. Capture Capturé à partir de l'événement de création d'un enregistrement d'entretien dans le module de recrutement. Type d'événement explicit
	Entretien terminé	Marque la fin d'un entretien planifié avec un candidat. Cela est généralement déduit lorsqu'un intervieweur ou un recruteur met à jour le statut de l'entretien de 'Planifié' à 'Terminé' ou 'Mené'.
Pourquoi est-ce important ? : Cette activité sert de déclencheur pour la fenêtre de soumission de `feedback`. L'analyse du temps écoulé entre ce point et la soumission du `feedback` est indispensablele pour mesurer la réactivité du responsable du recrutement. Source des données : Déduit d'une mise à jour de statut de l'objet d'entretien planifié ou d'un changement manuel d'étape pour le candidat dans Workday Recruiting après l'entretien. Capture Dérivé de l'horodatage de la mise à jour du statut d'entretien ou du changement d'étape du candidat après l'entretien. Type d'événement inferred
	Feedback soumis	Représente le moment où un intervieweur soumet formellement son évaluation d'un candidat après l'entretien. Workday fournit un mécanisme spécifique permettant aux intervieweurs de fournir des retours directement sur le profil du candidat.
Pourquoi est-ce important ? : Ceci est indispensable pour l'analyse des 'Délais de `feedback` des responsables du recrutement'. Les retards ici sont un `bottleneck` courant, et le suivi de cela aide à faire respecter les accords de niveau de service. Source des données : C'est un `event` explicite enregistré lorsque le `feedback` est soumis via la tâche 'Fournir le feedback d'entretien'. Le `horodatage` de soumission est enregistré par rapport au dossier d'entretien. Capture Extrait de l'horodatage d'achèvement de l'événement 'Provide Interview Feedback'. Type d'événement explicit
	Onboarding initié.	Représente le lancement du processus d'`intégration` des nouvelles recrues dans Workday. Il s'agit généralement d'un événement explicite qui fait partie du processus métier principal 'Embauche' ou qui est déclenché immédiatement après.
Pourquoi est-ce important ? : L'analyse du temps écoulé entre l'"Offer Accepted" et cette activité contribue à rationaliser l'expérience candidat post-offre. Elle garantit que les nouvelles recrues sont engagées et préparées pour leur premier jour. Source des données : Le processus métier 'Onboarding' de Workday a un `horodatage` d'initiation clair. Ceci peut être capturé à partir du journal d'audit du processus pour le dossier du nouvel employé. Capture Capturé à partir de l'horodatage d'initiation du processus métier 'Onboarding'. Type d'événement explicit
	Vérification des antécédents initiée	Indique le début du processus de vérification des antécédents pour un candidat ayant accepté une offre. Cela est généralement déduit du passage du candidat à l'étape 'Vérification des antécédents', ce qui déclenche souvent une intégration avec un fournisseur tiers.
Pourquoi est-ce important ? : Cette activité est indispensablele pour surveiller la `conformité` et analyser les délais entre l'acceptation de l'offre et le début des vérifications préalables à l'embauche. Elle contribue à assurer une transition fluide vers l'`intégration`. Source des données : Déduit du horodatage du passage du candidat à l'étape 'Vérification des antécédents' dans le flux de son processus de recrutement. Le journal d'audit de la candidature indiquera ce changement de statut. Capture Dérivé de l'horodatage effectif du passage à l'étape 'Background Check'. Type d'événement inferred
	Vérification des Antécédents Réussie	Marque la réussite du processus de vérification des antécédents. Cet événement est déduit lorsque le statut du candidat est mis à jour pour indiquer qu'il a réussi les vérifications nécessaires, l'autorisant à être embauché.
Pourquoi est-ce important ? : C'est le dernier point de contrôle avant que le processus d'embauche puisse être finalisé. Les retards dans la réception et l'enregistrement de cette autorisation peuvent retarder la date de début d'un candidat. Source des données : Déduit d'une mise à jour de statut de la candidature, telle que le passage à l'étape 'Prêt à être embauché' ou 'Vérification des antécédents terminée'. Capture Dérivé du changement de statut indiquant une vérification des antécédents terminée et réussie. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Workday Recruiting

Étapes

Se connecter à Workday : Accédez à votre tenant Workday avec un compte utilisateur disposant des autorisations pour créer des rapports personnalisés et accéder aux données de recrutement.
Créer un rapport personnalisé : Naviguez vers la tâche 'Créer un rapport personnalisé'. Sélectionnez 'Avancé' comme type de rapport et activez l'option 'Activer en tant que service Web'. Pour la source de données, utilisez une source indexée comme 'Toutes les candidatures' pour de meilleures performances.
Définir l'objet métier principal : Définissez l'objet métier principal sur 'Candidature'. Cet objet servira de base au rapport et d'identifiant de cas.
Ajouter des colonnes de données : Ajoutez les champs requis et recommandés à la grille des colonnes du rapport. Ajoutez 'Candidature' pour le JobApplicationId. Pour d'autres attributs comme 'Recruteur' et 'Manager recruteur', vous devrez les ajouter à partir des objets métier liés à la Candidature.
Créer des champs calculés pour les activités : Ceci est l'étape la plus critique. Pour chacune des 15 activités, vous créerez deux champs calculés : un pour le nom de l'activité et un pour l'horodatage de l'événement. La logique de ces champs est détaillée dans la section Requête. Par exemple, pour capturer 'Offer Extended', vous créerez un champ qui vérifie l'achèvement du processus métier 'Propose Compensation' et un autre champ pour extraire l'horodatage d'achèvement de ce processus.
Ajouter des champs calculés au rapport : Ajoutez tous les champs calculés nouvellement créés (30 au total, 15 pour les noms d'activités et 15 pour les horodatages) comme colonnes dans votre rapport. Le rapport sera au format 'large', avec une ligne par candidature et de nombreuses colonnes représentant les activités potentielles.
Configurer les options du service Web : Dans l'onglet 'Service Web' de la définition du rapport, assurez-vous que la case 'Activer en tant que service Web' est cochée. Vous pouvez consulter le namespace et l'URL du rapport ici. Notez le 'Namespace' pour une utilisation ultérieure.
Définir les autorisations : Partagez le rapport avec un Utilisateur Système d'Intégration (ISU) ou un groupe de sécurité spécifique qui sera utilisé pour appeler le point d'accès RaaS. Cet utilisateur doit avoir les autorisations sur le domaine de la source de données, par exemple, 'Recrutement : Candidatures'.
Exécuter et tester le rapport : Exécutez le rapport depuis l'interface utilisateur de Workday pour vérifier la sortie. Vérifiez un nombre raisonnable de lignes et assurez-vous que les champs calculés sont correctement renseignés pour quelques exemples de candidatures.
Planifier l'extraction : Utilisez un outil de planification externe ou un middleware (comme MuleSoft, Boomi, ou un script personnalisé) pour appeler l'URL RaaS du rapport régulièrement. L'outil devra gérer l'appel Workday SOAP ou REST API avec une authentification appropriée.
Transformer les données : La sortie brute de l'appel RaaS sera un fichier XML ou CSV de format large. Vous devez implémenter une étape de transformation dans votre middleware ou un langage de script (comme Python) pour 'dépivoter' ces données. Le script doit itérer à travers chaque ligne (candidature) et créer une nouvelle ligne dans le journal d'événements final pour chaque paire activité/horodatage non vide, résultant en un format 'long' avec trois colonnes principales : JobApplicationId, (ActivityName) et (EventTime).

Configuration

Type de rapport: Utilisez toujours 'Avancé' pour permettre des champs calculés complexes et l'accès aux objets métier associés.
Source de données: Utilisez une source de données indexée comme 'Toutes les candidatures' pour garantir l'exécution efficace du rapport. Évitez les sources non indexées pour les grands ensembles de données.
Filtrage par plage de dates: Il est impératif d'appliquer un filtre sur le champ 'Date de candidature' de l'objet métier Candidature. Commencez par une plage plus petite, telle que les 3 à 6 derniers mois, pour gérer le volume des données et les performances du rapport.
Objet métier principal: L'objet principal doit être 'Candidature' pour que le JobApplicationId serve d'identifiant de cas.
Activation des services web: Vous devez cocher l'option 'Activer en tant que service web' dans la configuration du rapport pour le rendre accessible via les API.
Sécurité et autorisations: Le rapport doit être partagé avec un Utilisateur Système d'Intégration (ISU) dédié. Cet ISU doit disposer des autorisations du groupe de sécurité pour accéder aux domaines de données requis, y compris 'Recrutement : Candidatures', 'Transactions de processus métier' et 'Données des employés'.
Format de sortie: Bien que Workday offre plusieurs formats de sortie (XML, CSV, JSON), le XML (spécifiquement le format 'Simple XML') est souvent le plus fiable pour l'extraction de données structurées via l'API.

a Exemple de requête config

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

Configurer l'accès Workday : Créez un Utilisateur Système d'Intégration (ISU) dans Workday. Accordez à cet utilisateur l'accès aux domaines de sécurité nécessaires pour l'API de recrutement. Les domaines clés incluent 'Données des employés : Rapports publics sur les employés', 'Candidature' et 'Recrutement : Rapports'.
Identifier le point d'accès de l'API : Localisez le point d'accès REST API pour l'opération 'Get Job Applications' dans votre tenant Workday. L'URL suit généralement le format : https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications.
Configurer l'environnement Python : Assurez-vous que Python est installé. Installez les bibliothèques nécessaires à l'aide de pip : pip install requests pandas.
Développer le script d'authentification : Dans votre script Python, implémentez l'authentification de base en utilisant les identifiants de l'ISU créé à l'étape 1. Le nom d'utilisateur et le mot de passe seront envoyés dans l'en-tête de la requête.
Implémenter la logique de requête API : Écrivez la fonction pour appeler le point d'accès 'Get Job Applications'. Utilisez les paramètres de requête pour filtrer les données, comme updatedSince pour récupérer les candidatures modifiées après une certaine date. Ceci est impératif pour gérer le volume des données.
Gérer la pagination de l'API : L'API Workday renvoie un nombre limité d'enregistrements par requête. Votre script doit vérifier la réponse pour un nombre total et un lien vers la page next ou un paramètre de décalage, et parcourir toutes les pages pour récupérer l'ensemble complet des données.
Définir le mappage des activités : Créez un dictionnaire de mappage ou une série d'instructions conditionnelles dans votre script. Cette logique traduira les statuts de processus métier et les étapes de recrutement de Workday (par exemple, 'Screen', 'Interview', 'Offer', 'Hire') en noms d'activités requis (par exemple, 'Application Screened', 'Candidate Moved To Interview').
Transformer les données de candidature : Pour chaque candidature récupérée de l'API, analysez son journal d'audit ou ses données d'historique d'étapes. Cet historique contient la séquence des étapes, des dispositions et des événements de processus métier avec leurs horodatages correspondants.
Générer les lignes de journal d'événements : Itérez à travers l'historique de chaque candidature. Pour chaque événement historique pertinent qui correspond à votre mappage d'activités, créez un dictionnaire représentant une ligne dans le journal d'événements final. Remplissez les attributs JobApplicationId, (ActivityName), (EventTime) et les autres attributs requis.
Agréger et structurer les données : Collectez toutes les lignes de journal d'événements générées à partir de toutes les candidatures dans une seule liste.
Créer et exporter un fichier CSV : Utilisez la bibliothèque pandas pour convertir la liste des dictionnaires d'événements en un DataFrame. Ensuite, exportez le DataFrame vers un fichier CSV. Assurez-vous que les en-têtes de colonne correspondent aux exigences de ProcessMind (par exemple, CaseId, Activity, Horodatage).
Examiner et télécharger : Ouvrez le fichier CSV final pour en examiner le contenu afin de vérifier son exactitude et son exhaustivité avant de le télécharger dans l'outil de Process Mining.

Configuration

Utilisateur Système d'Intégration Workday (ISU): Un ISU avec un mot de passe fort et sans expiration est requis. Il doit disposer des autorisations pour les domaines de sécurité 'Recrutement' et 'Données des employés' afin d'accéder aux détails des candidatures et des candidats.
Point d'accès (Endpoint) et version de l'API: Vous devez utiliser le bon point d'accès REST API pour votre tenant Workday. Il est important de spécifier la version de l'API dans la requête pour garantir un comportement cohérent.
Filtre de plage de dates: Le script doit utiliser un filtre de date (par exemple, updatedSince) pour limiter la requête à une période gérable. Pour les extractions initiales, une période de 3 à 6 mois est recommandée. Pour les chargements différentiels ultérieurs, utilisez l'horodatage de la dernière extraction réussie.
Limite de pagination: Soyez conscient du paramètre limit dans l'API, qui contrôle le nombre d'enregistrements renvoyés par page. Un maximum typique est de 100. Le script doit être conçu pour gérer cela en effectuant plusieurs requêtes paginées.
Champs de réponse: Pour améliorer les performances, vous pouvez spécifier les champs à renvoyer à l'aide d'un paramètre fields ou similaire si l'API le prend en charge. Cela réduit la taille de la charge utile de la réponse de l'API.
Configuration du mappage des activités: La logique centrale du script est le mappage des étapes Workday aux activités définies. Cela peut nécessiter une personnalisation en fonction de la configuration spécifique du processus de recrutement Workday de 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'un outil ETL ou iPaaS tiers sous licence, tel que CData, MuleSoft ou une plateforme similaire, avec son connecteur Workday installé. Confirmez que vous disposez des identifiants d'un Utilisateur Système d'Intégration (ISU) Workday avec les autorisations API nécessaires pour les domaines Recrutement et Gestion du personnel.
Configurer la connexion Workday : Dans votre outil ETL, créez une nouvelle connexion à Workday. Fournissez l'URL de votre tenant Workday, la version de l'API et les identifiants ISU, par exemple, le nom d'utilisateur et le mot de passe ou les jetons OAuth 2.0. Testez la connexion pour vous assurer qu'elle est réussie.
Explorer le schéma de données : Utilisez l'explorateur de schéma ou de source de données dans votre outil ETL pour visualiser les objets Workday disponibles via le connecteur. Ceux-ci sont généralement présentés sous forme de tables ou de vues, telles que Job_Application, Job_Requisition et Candidate_Stage_History. Familiarisez-vous avec les champs et les relations disponibles.
Identifier les objets de données clés : Pour cette extraction, vous aurez principalement besoin de données provenant d'objets liés aux candidatures, à l'historique des candidats, aux entretiens, aux offres et aux embauches. Les noms exacts dépendront de votre connecteur, mais recherchez les objets représentant ces entités clées.
Développer la requête SQL : Créez une nouvelle tâche ou pipeline d'extraction de données. Utilisez une étape de transformation SQL pour exécuter une requête sur la connexion Workday. Copiez et collez la requête SQL fournie dans cette étape. Cette requête est conçue pour collecter des données à partir de plusieurs objets Workday et les unir dans un format de journal d'événements unique.
Paramétrer la requête : Modifiez la clause WHERE de la requête pour inclure des paramètres pour la plage de dates, par exemple, startDate et endDate. Configurez ces paramètres dans votre tâche ETL afin de pouvoir facilement modifier la fenêtre d'extraction sans altérer le code.
Exécuter la tâche d'extraction : Exécutez 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 staging ou en mémoire.
Examiner et valider les données : Avant d'écrire la sortie finale, utilisez la fonction d'aperçu de votre outil ETL pour inspecter les résultats. Vérifiez un nombre raisonnable de lignes, assurez-vous que toutes les colonnes sont remplies comme prévu et vérifiez la présence de différentes activités.
Configurer la destination : Définissez la cible pour vos données extraites. Il s'agit généralement d'un fichier CSV à télécharger sur ProcessMind. Configurez le nom du fichier, le délimiteur (virgule) et l'encodage (UTF-8).
Finaliser et exporter : Exécutez la tâche d'extraction complète pour générer le fichier CSV final. Assurez-vous que les en-têtes de colonne du fichier de sortie correspondent aux attributs requis : JobApplicationId, (ActivityName), (EventTime), RecruiterName, HiringManager, ApplicationSource, Department et ApplicationStatus.

Configuration

Identifiants du connecteur Workday: La connexion nécessite l'URL du tenant Workday et un Utilisateur Système d'Intégration (ISU) autorisé avec un mot de passe ou des identifiants client OAuth 2.0. L'utilisateur doit disposer des autorisations de sécurité pour les domaines fonctionnels 'Recrutement' et 'Gestion du personnel'.
Activation des services web: Le connecteur peut vous demander de spécifier les services web Workday à exposer. Assurez-vous que les services liés au Recrutement, à la Gestion du personnel et aux Ressources Humaines sont activés pour accéder à tous les objets de données nécessaires.
Plage de dates: Pour gérer les performances et le volume des données, il est impératif de filtrer l'extraction par une période spécifique. Nous recommandons un chargement initial de 3 à 6 mois de données, suivi de chargements incrémentiels quotidiens ou hebdomadaires. Ceci est géré via la clause WHERE de la requête SQL.
Filtres de portée des données: Si vous avez uniquement besoin d'analyser le processus pour certaines parties de l'organisation, envisagez d'ajouter des filtres dans la clause WHERE pour des champs comme l'Entreprise, le Centre de coûts ou l'Organisation hiérarchique.
Version de l'API: Certains connecteurs vous demandent de spécifier la version de l'API Workday. Il est préférable d'utiliser une version récente et prise en charge pour garantir l'accès aux derniers objets de données et fonctionnalités.
Considérations relatives aux performances: Les extractions complètes de données depuis Workday peuvent être consommatrices de ressources. Planifiez les tâches volumineuses en dehors des heures de pointe. Pour une analyse continue, mettez en œuvre une stratégie de chargement incrémentiel basée sur un horodatage de 'dernière modificationication' afin d'extraire uniquement les enregistrements nouveaux ou mis à jour.

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]'

Votre modèle de données de recrutement et d'acquisition de talents

Votre modèle de données de recrutement et d'acquisition de talents

Attributs de Recrutement et acquisition de talents

Activités de Recrutement et acquisition de talents

Guides d'extraction

Extraction Report-as-a-Service (RaaS) Workday

Étapes

Configuration

a Exemple de requête config

Extraction API de Workday Recruiting via script Python

Étapes

Configuration

a Exemple de requête python

Extraction par outil ETL avec un connecteur Workday

Étapes

Configuration

a Exemple de requête sql

Prêt(e) à démarrer ?

Mettez fin aux points de blocage de l'embauche : optimisez votre acquisition de talents dès aujourd'hui

Votre modèle de données de recrutement et d'acquisition de talents

Votre modèle de données de recrutement et d'acquisition de talents

Attributs de Recrutement et acquisition de talents

Activités de Recrutement et acquisition de talents

Guides d'extraction

Extraction Report-as-a-Service (RaaS) Workday

Étapes

Configuration

a Exemple de requête config

Extraction API de Workday Recruiting via script Python

Étapes

Configuration

a Exemple de requête python

Extraction par outil ETL avec un connecteur Workday

Étapes

Configuration

a Exemple de requête sql

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Mettez fin aux points de blocage de l'embauche : optimisez votre acquisition de talents dès aujourd'hui