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

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

Greenhouse

Attributs liés au recrutement et à l’acquisition de talents (21) Activités liées au recrutement et à l’acquisition de talents (14) 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 votre processus de recrutement et d’acquisition de talents. Il présente les attributs essentiels à suivre, les principales activités à enregistrer et explique comment extraire ces informations de Greenhouse. En le suivant, vous disposerez des données nécessaires à une analyse approfondie de vos processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction

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 liés au recrutement et à l’acquisition de talents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de recrutement et d’acquisition de talents dans Greenhouse.

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Candidature à un poste JobApplicationId	Identifiant unique de la candidature d’une personne à un poste donné.
Description L’identifiant de la candidature à un poste est la clé de l’analyse du processus de recrutement : il sert d’identifiant de cas unique. Il relie toutes les activités associées, depuis l’envoi initial et la présélection jusqu’aux entretiens, aux offres et à la décision finale d’embauche. Vous pouvez ainsi suivre le parcours complet de chaque personne candidate. En Process Mining, cet attribut sert à reconstituer le chemin exact suivi par chaque personne dans le processus de recrutement. Il permet d’analyser les variantes du processus, les temps de cycle par candidature et les étapes auxquelles les candidatures sont abandonnées. Vous obtenez ainsi une vue claire de l’ensemble du parcours de recrutement de chaque personne. Pourquoi est-ce important ? Cet identifiant de cas essentiel relie tous les événements de recrutement associés à une même personne candidate et permet d’analyser son parcours d’embauche du début à la fin. Où trouver ces données Il s’agit généralement de la clé primaire de l’objet candidature. Consultez la documentation de l’API Greenhouse pour le point de terminaison « Applications », souvent désigné par « id » ou « application_id ». Exemples 987654321098765432119876543212
	Horodatage de l’activité ActivityTimestamp	Date et heure exactes de l’activité de recrutement.
Description L’horodatage de l’activité indique le moment précis où un événement s’est produit dans le processus de recrutement. Il constitue la base temporelle de toutes les analyses de performance et de durée, et permet d’ordonner chronologiquement les activités de chaque candidature. Cet horodatage est indispensable au calcul des indicateurs liés au temps, comme le délai de recrutement, le temps de cycle de planification des entretiens et le délai de transmission des retours d’entretien. En analysant le temps écoulé entre les activités, les organisations peuvent mesurer l’efficacité, repérer les retards et vérifier le respect des accords de niveau de service. Ces analyses alimentent directement les Dashboards consacrés à la performance et aux goulots d’étranglement. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements, calculer les temps de cycle et analyser la performance du processus de recrutement. Où trouver ces données Cet horodatage figure dans différents objets Greenhouse, par exemple « applied_at » dans l’objet Application, « created_at » dans les objets Offer, ou dans les flux d’activité et les journaux d’audit. Exemples 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	Nom de l’activité ActivityName	Nom de l’activité ou de l’étape de recrutement concernée.
Description Cet attribut indique le nom de chaque événement du processus de recrutement, par exemple « Candidature reçue », « Entretien planifié » ou « Offre acceptée ». Il constitue la séquence d’événements qui forme la cartographie du processus. L’analyse de l’ordre et de la fréquence de ces activités est fondamentale en Process Mining. Elle permet de visualiser le parcours de recrutement, de repérer les chemins les plus fréquents, de détecter les écarts par rapport au flux de travail standard et de localiser les goulots d’étranglement. Vous pouvez, par exemple, suivre le nombre de candidatures qui passent de « Candidature examinée » à « Présélection par le recruteur réalisée ». Pourquoi est-ce important ? Cet attribut définit les étapes du processus de recrutement. Il permet de visualiser le flux du processus et de repérer les goulots d’étranglement et les écarts. Où trouver ces données Cet attribut est souvent établi à partir des changements de statut des candidatures, des statuts d’entretien, des événements liés aux offres ou d’autres actions traçables dans Greenhouse. Une logique de transformation des événements système en noms d’activité normalisés peut être nécessaire. Exemples Candidature examinéeEntretien réaliséOffre acceptéeCandidature rejetée
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation ou extraction des données de cet événement.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis le système source. Ce champ de métadonnées renseigne sur l’actualité des données dans le modèle de Process Mining. Il aide les utilisateurs à comprendre si l’analyse est à jour. Il permet de tenir compte du délai de mise à disposition des données et de vérifier que le pipeline de données s’exécute comme prévu. Par exemple, si la « Dernière mise à jour des données » remonte à plusieurs jours, les utilisateurs savent que les Dashboards ne reflètent pas les activités de recrutement les plus récentes. Pourquoi est-ce important ? Indique si les données sont à jour et aide les utilisateurs à déterminer si l’analyse reflète l’état le plus récent du processus. Où trouver ces données Cet horodatage est généré et ajouté au jeu de données lors du processus d’extraction, de transformation et de chargement (ETL). Exemples 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	Système source SourceSystem	Indique le système de référence depuis lequel les données ont été extraites.
Description Cet attribut précise l’origine des données de recrutement. Pour ce processus, sa valeur sera toujours « Greenhouse ». Même si cette valeur semble fixe, le suivi explicite du système source est important pour la gouvernance des données, le diagnostic des problèmes et les situations où les données sont enrichies à partir d’autres systèmes, comme un SIRH. Il clarifie la provenance des données et contribue à préserver leur intégrité dans l’ensemble de l’environnement de données de l’organisation. Pourquoi est-ce important ? Cet attribut garantit une provenance claire des données, essentielle à leur gouvernance et à leur validation, ainsi qu’à la gestion de données provenant de plusieurs sources. Où trouver ces données Cette valeur fixe doit être ajoutée lors de l’extraction et de la transformation des données afin d’en indiquer l’origine. Exemples Greenhouse
	Intitulé du poste JobTitle	Intitulé du poste auquel la personne candidate a postulé.
Description Cet attribut contient l’intitulé officiel du poste, par exemple « Ingénieur logiciel senior » ou « Responsable marketing produit ». Il précise le contexte du poste à pourvoir. L’analyse des processus de recrutement par intitulé de poste est essentielle pour comprendre les difficultés propres à chaque rôle. Par exemple, le Dashboard « Performance du délai de recrutement » utilise cet attribut pour montrer si les postes de niveau senior ou très spécialisés sont plus longs à pourvoir. Il permet aussi d’analyser les taux d’acceptation des offres selon le poste et d’évaluer la compétitivité de la rémunération ou l’attrait du rôle. Pourquoi est-ce important ? Permet de filtrer et de comparer les indicateurs de recrutement pour des postes précis, afin de comprendre comment la complexité ou le type de poste influe sur la performance du processus. Où trouver ces données Il s’agit d’un champ principal de l’objet Job dans Greenhouse, souvent accessible sous le nom « name » lors d’une requête au point de terminaison « jobs » via l’API. Exemples Ingénieur logiciel seniorResponsable de comptesDesigner UX/UI
	Nom du recruteur RecruiterName	Nom du recruteur chargé de gérer la candidature.
Description Cet attribut identifie le recruteur affecté à une candidature ou à une demande de recrutement. Cette personne est généralement chargée de la présélection, de la coordination des entretiens et du suivi de la candidature tout au long du processus. L’analyse du processus par recruteur permet de comprendre les performances individuelles et la répartition de la charge de travail. Le Dashboard « Charge de travail et efficacité des recruteurs » s’appuie sur cet attribut pour calculer des indicateurs comme le volume traité et les temps de cycle par recruteur. Il aide à repérer les personnes les plus performantes, à identifier celles qui pourraient avoir besoin d’assistance supplémentaire et à équilibrer la charge de travail au sein de l’équipe de recrutement. Pourquoi est-ce important ? Associe les activités du processus à un recruteur donné et permet d’analyser ses performances, sa charge de travail et son efficacité. Où trouver ces données Disponible dans l’objet Job de Greenhouse, généralement dans la section « hiring_team », qui précise les rôles tels que « Recruiter ». Exemples Alice JohnsonRobert DavisMaria Garcia
	Service du poste JobDepartment	Service ou unité opérationnelle auquel appartient le poste à pourvoir.
Description Cet attribut indique le service de l’organisation, par exemple « Ingénierie », « Marketing » ou « Ventes », associé à la demande de recrutement. Il permet de regrouper et de comparer les indicateurs de recrutement entre les différentes entités de l’entreprise. La segmentation par service est importante pour des Dashboards comme « Performance du délai de recrutement » et « Évolution du taux d’acceptation des offres ». Elle permet de repérer les services où les cycles de recrutement sont plus longs, les offres plus souvent refusées ou le respect du processus différent. Ces analyses permettent de cibler les mesures et les améliorations en fonction des besoins de chaque service. Pourquoi est-ce important ? Permet de comparer les performances de recrutement et les variations du processus entre les services, afin de mettre en évidence les problèmes systémiques ou les bonnes pratiques. Où trouver ces données Généralement disponible dans un champ standard ou personnalisé de l’objet Job dans Greenhouse. Vous pouvez le trouver dans la section « departments » d’un enregistrement Job via l’API. Exemples IngénierieGestion de produitVentesMarketing
	Source de la candidature ApplicationSource	Canal par lequel la candidature a été reçue.
Description Cet attribut indique l’origine d’une candidature, par exemple « LinkedIn », « Recommandation d’un employé », « Site web de l’entreprise » ou « Indeed ». Il permet d’évaluer l’efficacité des différents canaux de recrutement. Le Dashboard « Efficacité des canaux de recrutement » repose entièrement sur cet attribut. En analysant le volume de candidatures, le délai de recrutement et le taux d’embauche par source, les organisations peuvent optimiser leurs dépenses et leurs efforts de recrutement. Ces données permettent de déterminer quels canaux attirent les personnes les plus qualifiées avec le plus d’efficacité et alimentent directement l’indicateur du taux de conversion des canaux de recrutement. Pourquoi est-ce important ? Permet de mesurer l’efficacité et le retour sur investissement des différents canaux de recrutement, afin de décider sur quels canaux concentrer les efforts de recherche de candidats. Où trouver ces données Disponible dans l’objet Candidate de Greenhouse, associé à l’objet Application. Le champ « source » contient cette information. Exemples LinkedInRecommandation d’un employéPage carrières de l’entrepriseIndeed
	Statut de l’offre OfferStatus	Statut actuel de l’offre d’emploi présentée à une personne candidate.
Description Cet attribut suit l’état d’une offre d’emploi, par exemple « Créée », « Présentée », « Acceptée » ou « Refusée ». Il renseigne sur les dernières étapes du processus de recrutement. Cet attribut est essentiel au Dashboard « Évolution du taux d’acceptation des offres » et à l’indicateur associé. En suivant le passage de « Offre présentée » à « Offre acceptée » ou « Offre refusée », les entreprises peuvent mesurer leur capacité à conclure le recrutement. L’analyse par service ou par intitulé de poste peut révéler des problèmes de compétitivité de la rémunération, d’expérience candidate ou d’autres facteurs qui influencent la décision. Pourquoi est-ce important ? Suit l’issue des offres d’emploi, ce qui permet de calculer le taux d’acceptation des offres et de comprendre comment l’améliorer. Où trouver ces données Disponible dans l’objet Offer de Greenhouse, associé à un objet Application. Le champ « status » contient cette information. Exemples AcceptéeRefuséeEnvoyéeCréée
	Statut de la candidature ApplicationStatus	Résultat final ou état actuel de la candidature à un poste.
Description Cet attribut indique l’issue d’une candidature, par exemple « Embauchée », « Rejetée » ou « Active ». Il représente l’état final d’un processus terminé ou l’état actuel d’un processus en cours. Il s’agit d’une dimension importante pour analyser les résultats. Vous pouvez filtrer les cas et comparer les parcours des personnes embauchées à ceux des personnes non retenues, afin de repérer les caractéristiques des parcours réussis. Cet attribut sert également à calculer les taux de conversion dans le Dashboard « Parcours global de recrutement », qui indique le pourcentage de candidatures aboutissant à une embauche. Pourquoi est-ce important ? Définit l’issue du processus de recrutement et permet de comparer les parcours des personnes embauchées à ceux des personnes non retenues. Où trouver ces données Cette information figure dans l’objet Application de Greenhouse, dans le champ « status » de l’API. Exemples EmbauchéeRefuséeActive
	Automatisée IsAutomated	Indique si l’activité a été effectuée automatiquement par le système.
Description Cet attribut booléen indique si une activité a été effectuée par un utilisateur ou par une règle automatisée du système. Parmi les activités automatisées possibles : l’envoi de courriels de réponse automatique ou le rejet automatique des candidatures qui ne satisfont pas à une question de présélection élémentaire. L’analyse de cet attribut permet de comprendre le degré d’automatisation du processus de recrutement. Elle sert à comparer l’efficacité et les résultats des étapes automatisées et manuelles, ainsi qu’à repérer les possibilités d’automatisation supplémentaires pour accélérer le processus et le rendre plus cohérent. Pourquoi est-ce important ? Permet de distinguer les activités manuelles des activités automatisées et d’analyser l’incidence de l’automatisation sur l’efficacité et les résultats du processus. Où trouver ces données Cette information ne correspond pas à un champ standard et doit généralement être déduite. Elle peut être déterminée à partir de l’utilisateur associé à une activité, par exemple un utilisateur « System », ou de types d’événements connus pour être automatisés. Exemples truefalse
	Conforme IsCompliant	Indicateur calculé précisant si la candidature a suivi le processus de recrutement standard défini.
Description Cet attribut booléen résulte d’un contrôle de conformité qui compare la séquence réelle des activités d’une candidature au modèle de processus idéal prédéfini. Il signale les cas qui s’en écartent, par exemple lorsqu’une étape obligatoire est omise ou que les activités sont réalisées dans le désordre. Cet attribut est au cœur du Dashboard « Écarts de conformité du recrutement » et alimente les indicateurs du taux de conformité du processus et du nombre de violations de conformité. En filtrant les cas non conformes, les organisations peuvent examiner les causes des écarts : formation insuffisante, limites du système ou exceptions nécessaires. Cette analyse aide à normaliser les flux de travail et à réduire les risques liés à la conformité. Pourquoi est-ce important ? Repère les écarts du processus et permet de mesurer sa conformité, de veiller au respect des exigences et de normaliser les flux de travail de recrutement. Où trouver ces données Ce champ calculé est généré par le logiciel de Process Mining. Il compare les données du journal d’événements à un modèle cible défini ou à un ensemble de règles métier. Exemples truefalse
	Délai de transmission des retours d’entretien InterviewFeedbackTurnaroundTime	Temps écoulé entre la fin d’un entretien et l’envoi du retour par l’intervieweur.
Description Cet indicateur calculé mesure la réactivité du comité d’entretien. Les retards dans l’envoi des retours peuvent ralentir considérablement le recrutement et nuire à l’expérience candidate. Cet attribut alimente directement le Dashboard « Analyse de la boucle de retour des entretiens » et l’indicateur du délai de transmission des retours d’entretien. Il correspond au temps écoulé entre les activités « Entretien terminé » et « Retour envoyé ». Son suivi permet de repérer les goulots d’étranglement dus à des retours tardifs et d’encourager une prise de décision plus rapide. Pourquoi est-ce important ? Mesure l’efficacité de la boucle de retour après entretien, une source fréquente de retards dans le processus de recrutement. Où trouver ces données Ce champ est calculé en soustrayant l’horodatage de l’événement « Entretien terminé » de celui de l’événement « Retour envoyé ». Exemples 86400172800259200
	Étape de l’entretien InterviewStageName	Nom ou type précis de l’étape de l’entretien.
Description Cet attribut précise l’étape concernée dans le processus global d’entretien, par exemple « Présélection par le recruteur », « Entretien technique » ou « Dernier entretien ». Il apporte davantage de détails qu’une activité générique comme « Entretien terminé ». L’analyse des indicateurs à chaque étape d’entretien permet de repérer plus précisément les goulots d’étranglement. Par exemple, vous pouvez mesurer avec précision le taux d’abandon des candidatures par étape et déterminer si les personnes candidates se retirent plutôt après l’entretien technique ou après la présélection initiale. Ces détails permettent d’améliorer de façon ciblée l’expérience des entretiens. Pourquoi est-ce important ? Donne une vue plus détaillée du processus d’entretien et permet d’analyser les temps de cycle et les taux d’abandon à chaque étape. Où trouver ces données Cette information figure dans les données de planification des entretiens de Greenhouse. L’objet « interviews » d’une candidature contient des détails sur l’étape de l’entretien. Exemples Présélection par le recruteurEntretien avec le responsable du recrutementÉvaluation techniqueDernier entretien sur site
	Heure de fin de l’activité ActivityEndTime	Horodatage indiquant la fin d’une activité qui s’étend sur une certaine durée.
Description Cet attribut indique l’heure de fin des activités qui s’étendent sur une période, comme un entretien ou une vérification des antécédents. De nombreuses activités sont instantanées, mais celles dont la durée peut être mesurée gagnent à avoir une heure de début et une heure de fin. L’heure de fin est indispensable pour calculer précisément la durée ou le temps de traitement d’une activité. Elle permet de distinguer le temps d’attente entre les étapes du temps réellement consacré à une tâche. Vous pouvez, par exemple, analyser plus précisément la durée réelle des entretiens, par opposition au temps nécessaire pour les planifier. Pourquoi est-ce important ? Permet de calculer précisément le temps de traitement des activités et de distinguer le temps de travail effectif du temps d’attente dans le processus. Où trouver ces données Cette information peut figurer dans des objets comme « scheduled_interview » dans Greenhouse, qui comporte souvent une heure de début et une heure de fin. Pour les autres activités, elle peut être déduite de l’horodatage de l’activité suivante. Exemples 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	ID de la personne candidate CandidateId	Identifiant unique de la personne candidate, indépendant de toute candidature particulière.
Description L’identifiant de la personne candidate désigne une personne dans le vivier de talents, tandis que l’identifiant de la candidature à un poste correspond à une candidature précise pour un poste donné. Une même personne peut envoyer plusieurs candidatures au fil du temps. L’identifiant de la candidature à un poste sert d’identifiant de cas pour cette vue du processus. L’identifiant de la personne candidate permet, lui, d’effectuer d’autres analyses : suivre son parcours sur plusieurs candidatures, repérer les candidatures répétées et analyser sa relation globale avec le vivier de talents. Il offre une vue des données de recrutement centrée sur la personne. Pourquoi est-ce important ? Permet d’analyser plusieurs candidatures d’une même personne et d’obtenir une vue plus large de son engagement au fil du temps. Où trouver ces données Il s’agit de la clé primaire d’un enregistrement de personne candidate dans Greenhouse, accessible sous le nom « id » dans l’objet Candidate via l’API. Exemples 123456123457123458
	ID du poste JobId	Identifiant unique de la demande de recrutement ou de l’offre d’emploi.
Description Cet attribut est l’identifiant unique du poste, distinct de celui de la candidature. Plusieurs candidatures peuvent être associées au même identifiant de poste. L’utilisation de cet identifiant permet de regrouper les données au niveau de la demande de recrutement. Vous pouvez, par exemple, analyser le nombre total de candidatures reçues pour un poste précis ou le délai moyen de recrutement pour des postes similaires. Il permet de regrouper et d’analyser les efforts de recrutement associés à un même poste à pourvoir. Pourquoi est-ce important ? Permet de regrouper et d’analyser toutes les données relatives aux candidatures pour un même poste, afin d’obtenir une vue centrée sur la demande de recrutement. Où trouver ces données Il s’agit de la clé primaire d’un enregistrement de poste dans Greenhouse. Elle est disponible sous le nom « id » dans l’objet Job via l’API. Exemples 400123400124400125
	Motif du rejet RejectionReason	Motif indiqué pour le rejet de la candidature.
Description Cet attribut précise pourquoi la candidature n’a pas été retenue pour la suite du processus. Parmi les motifs possibles : « Profil ne correspondant pas à la culture de l’entreprise », « Prétentions salariales trop élevées » ou « Candidatures plus qualifiées ». L’analyse des motifs de rejet fournit des indications précieuses sur le processus de recrutement. Elle peut mettre en évidence des problèmes comme des descriptions de poste mal adaptées, une rémunération peu compétitive ou des lacunes récurrentes dans les compétences des personnes candidates. Ces informations sont particulièrement utiles pour améliorer les stratégies de recherche de candidats et l’expérience candidate, en comprenant les causes fréquentes d’échec dans le processus de recrutement. Pourquoi est-ce important ? Précise pourquoi des candidatures sont écartées et aide à améliorer les descriptions de poste, la recherche de candidats et les critères de présélection. Où trouver ces données Disponible dans l’objet Application après le rejet de la candidature. L’API fournit un objet « rejection_reason » contenant les détails. Exemples Compétences requises manquantesPrétentions salariales trop élevéesUne personne candidate plus qualifiée a été retenue
	Nom du responsable du recrutement HiringManagerName	Nom du responsable du recrutement associé à la demande de recrutement.
Description Cet attribut identifie le responsable de l’équipe qui cherche à pourvoir un poste. Le responsable du recrutement joue un rôle important dans le processus : il participe souvent à l’examen des candidatures, aux entretiens des dernières étapes et à la décision finale d’embauche. L’analyse du processus par responsable du recrutement peut révéler des tendances et des goulots d’étranglement. Par exemple, le Dashboard « Goulots d’étranglement dans la planification des entretiens » peut montrer que les retards sont souvent liés aux disponibilités de certains responsables. Cette analyse permet de repérer les besoins de formation ou d’assistance pour que les responsables participent efficacement au processus de recrutement. Pourquoi est-ce important ? Identifie une partie prenante importante et permet d’analyser les goulots d’étranglement ou les gains d’efficacité associés à certains responsables du recrutement. Où trouver ces données Disponible dans l’objet Job de Greenhouse, généralement dans la section « hiring_team », qui précise les rôles tels que « Hiring Manager ». Exemples Emily TranDavid ChenSophia Rodriguez
	Recommandation de la grille d’évaluation ScorecardOverallRecommendation	Recommandation globale à l’issue d’une grille d’évaluation d’entretien remplie.
Description Cet attribut indique la recommandation finale de l’intervieweur dans une grille d’évaluation structurée, généralement « Avis très favorable », « Avis favorable », « Avis défavorable » ou « Avis très défavorable ». Ces données sont essentielles pour évaluer la qualité et la cohérence du processus d’entretien. Elles permettent de rapprocher les retours d’entretien des résultats réels du recrutement et de répondre à des questions comme : « Les personnes candidates ayant reçu de meilleures recommandations sont-elles plus souvent embauchées ? » Elles servent également de base à l’indicateur du taux de grilles d’évaluation remplies, qui mesure l’adoption des pratiques de recrutement structurées au sein de l’organisation. Pourquoi est-ce important ? Relie les retours structurés des entretiens aux résultats du processus et aide à mesurer l’adoption de pratiques de recrutement fondées sur les données. Où trouver ces données Disponible dans l’objet Scorecard associé à un entretien terminé dans Greenhouse. L’API fournit cette information via le point de terminaison « scorecards ». Exemples Avis très défavorableAvis défavorableAvis favorableAvis très favorable

Obligatoire Recommandé Facultatif

Activités liées au recrutement et à l’acquisition de talents

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément votre processus et optimiser votre recrutement.

7 Recommandé 7 Facultatif

	Activité	Description
	Candidature reçue	Cette activité marque le début du processus de recrutement pour une candidature donnée. Elle est enregistrée lorsqu’un candidat soumet sa candidature sur un site carrière ou par un canal de recherche, ou lorsqu’une candidature est saisie manuellement dans Greenhouse.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Le temps écoulé entre cette activité et les suivantes est essentiel pour mesurer le délai de recrutement et l’efficacité des canaux de recherche de candidats. Où trouver ces données Il s’agit d’un événement explicite enregistré dans Greenhouse lors de la création d’une candidature. Le champ « Date de candidature » ou l’horodatage de création de l’objet candidature indique l’heure de l’événement. Données à recueillir Enregistré à partir de l’horodatage de création de la fiche de candidature. Type d’événement explicit
	Candidature rejetée	La candidature a été rejetée à une étape du processus. Il s’agit de l’issue négative la plus fréquente, qui peut survenir à tout moment du parcours.
Pourquoi est-ce important ? Cet événement de fin est important pour analyser les taux d’abandon à chaque étape du processus de recrutement. Comprendre quand et pourquoi les candidatures sont rejetées permet de repérer les inefficacités du processus ou les exigences de poste mal définies. Où trouver ces données Cet événement explicite est enregistré lorsqu’un utilisateur rejette la candidature dans Greenhouse. Il est souvent associé à un motif de rejet, et l’horodatage figure dans le journal d’activité. Données à recueillir Horodatage de l’action de rejet de la candidature. Type d’événement explicit
	Entretien planifié	Un entretien avec le candidat a été planifié dans le système. Greenhouse s’intègre aux calendriers ; cet événement est donc généralement enregistré explicitement lorsque l’entretien est confirmé.
Pourquoi est-ce important ? Cet événement est essentiel pour analyser le processus de planification des entretiens et en repérer les goulots d’étranglement. Le temps écoulé depuis l’étape précédente est un indicateur clé de l’efficacité des recruteurs et des coordinateurs. Où trouver ces données Enregistré à partir de la fonction de planification des entretiens de Greenhouse. L’API fournit des données sur les entretiens planifiés, notamment leur horodatage de création. Données à recueillir Enregistré lorsqu’un événement d’entretien est créé et associé à la candidature. Type d’événement explicit
	Entretien réalisé	L’entretien avec le candidat a eu lieu. Cette activité est souvent déduite du passage de l’heure prévue de l’entretien ou, de manière plus fiable, de l’envoi d’un retour à son sujet.
Pourquoi est-ce important ? Cette activité marque une étape importante du parcours du candidat. Elle sert de point de départ pour mesurer le délai d’envoi des retours et le passage à l’étape suivante. Où trouver ces données Activité généralement déduite. Elle peut être déterminée à partir de l’heure de fin prévue de l’entretien ou, plus précisément, de l’horodatage du premier retour transmis pour cet entretien. Données à recueillir Déduite de l’heure de fin prévue de l’entretien ou de l’horodatage de l’envoi d’un retour ultérieur. Type d’événement inferred
	Offre acceptée	Le candidat a officiellement accepté l’offre d’emploi. Cette étape marque une réussite importante et déclenche généralement les activités préalables à l’embauche, comme les vérifications d’antécédents.
Pourquoi est-ce important ? Cette étape marque une réussite importante et entre dans le calcul de l’indicateur de taux d’acceptation des offres. Elle correspond au passage du statut de candidat à celui de futur employé. Où trouver ces données Cet événement explicite est enregistré dans Greenhouse lorsque le statut de l’offre passe à « Acceptée », soit par le recruteur, soit après acceptation électronique par la personne candidate. Données à recueillir Horodatage du changement de statut de l’offre à « Acceptée ». Type d’événement explicit
	Offre envoyée	L’offre d’emploi officielle a été envoyée au candidat. Cette étape importante marque l’aboutissement du processus d’entretien et de sélection.
Pourquoi est-ce important ? Cette activité sert de base au calcul de l’indicateur de taux d’acceptation des offres. Elle marque le début de la dernière étape de décision pour le candidat. Où trouver ces données Il s’agit d’un événement explicite enregistré dans Greenhouse lorsque le statut de l’offre passe à « Envoyée » ou « Transmise ». L’objet offre contient les horodatages de ces changements de statut. Données à recueillir Enregistré à partir de l’horodatage auquel l’offre est officiellement marquée comme envoyée. Type d’événement explicit
	Personne candidate embauchée	La personne candidate a passé avec succès toutes les vérifications préalables à l’embauche et son statut est officiellement défini comme « Embauchée ». Cet événement marque la réussite et la fin du processus de candidature.
Pourquoi est-ce important ? Il s’agit du principal résultat positif du processus. Le temps écoulé entre la « Réception de la candidature » et cet événement correspond au délai global de recrutement, un indicateur clé du recrutement. Où trouver ces données Dans Greenhouse, le recruteur effectue cette action explicite pour indiquer que la personne candidate est embauchée pour un poste donné. Son statut passe alors de candidature active à personne embauchée. Données à recueillir Horodatage de l’action « Marquer comme embauchée » dans Greenhouse. Type d’événement explicit
	Candidature examinée	Un recruteur ou un responsable du recrutement a effectué un premier examen de la candidature. Cette activité est généralement déduite du changement d’étape ou de statut de la candidature, par exemple de « Nouveau » à une étape d’examen active comme « En cours d’examen ».
Pourquoi est-ce important ? Le suivi de cette activité permet de repérer les goulots d’étranglement lors de la présélection et de mesurer le temps nécessaire pour examiner les nouvelles candidatures. Elle marque le début du calcul du temps de cycle de planification des entretiens. Où trouver ces données Déduite d’un changement du champ de statut de la candidature. Repérez le passage du statut « Nouveau » au statut « À examiner », en utilisant l’horodatage du changement. Données à recueillir Déduite de l’horodatage du passage au statut « En cours d’examen » ou à une étape similaire. Type d’événement inferred
	Intégration lancée	L’intégration de la nouvelle recrue dans l’entreprise a officiellement commencé. Le système de recrutement transmet souvent alors le dossier à un SIRH ou à une plateforme d’intégration.
Pourquoi est-ce important ? Cette mesure suit l’efficacité du transfert entre le recrutement et les ressources humaines. Un retard à cette étape peut nuire à l’expérience de la nouvelle recrue. Il est donc important de suivre le délai de transfert vers l’intégration. Où trouver ces données Il peut s’agir d’un événement explicite si Greenhouse est intégré à un système d’intégration. Sinon, il est déduit de l’horodatage du passage de la personne candidate au statut final « Embauchée », qui déclenche le transfert. Données à recueillir Déduit d’un changement de statut ou d’un journal d’intégration indiquant le transfert vers un SIRH. Type d’événement inferred
	Offre créée	Une offre d’emploi officielle a été rédigée et peut être en attente d’approbation interne. Cette activité marque la décision formelle de faire une offre au candidat.
Pourquoi est-ce important ? Cette activité distingue la décision de faire une offre de son envoi au candidat. Elle permet d’analyser les délais d’approbation interne et les goulots d’étranglement avant que l’offre ne lui parvienne. Où trouver ces données Greenhouse dispose d’un module dédié aux offres. Cet événement explicite est enregistré à partir de l’horodatage de création de l’objet offre associé à la candidature. Données à recueillir Enregistré lors de la création d’une fiche d’offre dans Greenhouse. Type d’événement explicit
	Offre refusée	La personne candidate a officiellement décliné l’offre d’emploi. Cet événement marque l’échec du processus à une étape tardive du parcours de recrutement.
Pourquoi est-ce important ? Le suivi de ce résultat est important pour analyser le taux d’acceptation des offres. Si cet événement est fréquent, cela peut révéler des problèmes liés à la rémunération, à la culture d’entreprise ou au poste lui-même. Où trouver ces données Cet événement explicite est enregistré dans Greenhouse lorsque le statut de l’offre passe à « Refusée » ou « Déclinée ». L’objet de l’offre comporte un horodatage pour ce changement de statut. Données à recueillir Horodatage du changement de statut de l’offre à « Refusée ». Type d’événement explicit
	Premier entretien téléphonique avec le recruteur réalisé	Un recruteur a terminé un premier entretien téléphonique ou un échange avec le candidat. Cette activité est souvent enregistrée lorsque le candidat passe à l’étape « Entretien téléphonique » du processus de recrutement.
Pourquoi est-ce important ? Cette étape importante de qualification indique que la candidature a passé la première sélection sur dossier. Elle permet de mesurer la charge de travail des recruteurs et l’efficacité de la présélection. Où trouver ces données Déduite de l’horodatage du passage de la candidature à l’étape « Entretien téléphonique » ou de sa sortie de cette étape dans le processus de recrutement Greenhouse. Données à recueillir Déduite de l’historique des étapes de la candidature, en particulier de son passage à l’étape « Entretien téléphonique ». Type d’événement inferred
	Retour transmis	Une personne ayant mené l’entretien a transmis sa grille d’évaluation ou son retour sur le candidat. Le processus de recrutement structuré de Greenhouse s’appuie sur ces informations pour prendre des décisions ; leur transmission constitue donc une action distincte enregistrée dans le système.
Pourquoi est-ce important ? La rapidité des retours est essentielle pour faire avancer les candidatures. Cette activité permet d’analyser l’efficacité de la boucle de retour et le taux de remplissage des grilles d’évaluation. Où trouver ces données Il s’agit d’un événement explicite enregistré lorsqu’une personne ayant mené l’entretien transmet une grille d’évaluation dans Greenhouse. L’objet API Scorecards contient un horodatage `submitted_at`. Données à recueillir Enregistré à partir de l’horodatage de transmission d’une grille d’évaluation d’entretien. Type d’événement explicit
	Vérification des antécédents lancée	La vérification des antécédents de la personne candidate a commencé, généralement après l’acceptation de l’offre. Cette étape peut être enregistrée comme un changement de statut ou déclenchée par l’intégration avec un service tiers.
Pourquoi est-ce important ? Cette activité est importante pour le suivi de la conformité et des délais de vérification avant embauche. Elle permet d’analyser le temps écoulé entre l’acceptation de l’offre et la fin des vérifications nécessaires. Où trouver ces données Cet événement est probablement déduit du passage de la personne candidate à l’étape « Vérification des antécédents » dans le processus de recrutement, ou d’une activité consignée par l’intégration avec un service de vérification. Données à recueillir Déduit du passage au statut « Vérification des antécédents » ou d’un journal d’API provenant d’un service intégré. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Greenhouse

Étapes

Connectez-vous à votre compte Greenhouse Recruiting.
Accédez à la section Reports en cliquant sur l’icône des rapports, qui ressemble à un graphique à barres, dans la barre de navigation principale.
Dans le Dashboard des rapports, repérez « Essential Reports » et cliquez dessus. Le rapport principal pour cette extraction est « All Applications ». Il présente les candidatures et leurs principaux jalons.
Configurez le rapport « All Applications ». Cliquez sur le bouton « Columns », puis sélectionnez toutes les colonnes nécessaires pour recueillir les attributs requis et les horodatages des activités. Veillez à inclure : Application ID, Candidate, Job, Department, Recruiter, Status, Source, Applied On, Rejected On, Hired On, Last Stage Change On, Offer Created On, Offer Accepted On et Offer Status.
Pour enregistrer les activités liées aux entretiens, vous aurez besoin d’un rapport distinct. Retournez dans Essential Reports et sélectionnez « Interview Details ».
Configurez le rapport « Interview Details ». Dans la section « Columns », sélectionnez au minimum : Application ID, Interview Name, Scheduled Start et Scorecard Submitted At. Vous obtiendrez ainsi les horodatages de planification et d’envoi des retours.
Pour les deux rapports, définissez la période à l’aide des filtres. Vous pouvez, par exemple, régler « Applied On » sur « All Time » ou choisir une période précise, comme les six derniers mois, afin de couvrir un ensemble pertinent de candidatures.
Générez chaque rapport en cliquant sur « Update » ou « Generate ». Une fois le rapport affiché, cliquez sur « Export to Excel » pour télécharger les données au format CSV. Vous disposerez alors de deux fichiers CSV distincts.
Les fichiers exportés ne sont pas encore au format d’un journal d’événements. Vous devez transformer les données à l’aide d’un outil comme Python ou R, ou d’un tableur doté d’une fonction de dépivotage, tel que Power Query dans Microsoft Excel.
Regroupez les données des rapports « All Applications » et « Interview Details » en les reliant à l’aide de l’Application ID.
Pour chaque candidature, créez une ligne distincte pour chaque colonne de date pertinente exportée. Par exemple, la valeur de la colonne « Applied On » devient l’ActivityTimestamp de l’activité « Application Received ». La valeur de « Rejected On » correspond à l’activité « Application Rejected », et ainsi de suite pour les 14 activités requises. Utilisez la colonne « Last Stage Change On » pour déduire des activités comme « Application Reviewed » ou « Recruiter Screen Conducted » lorsque les horodatages correspondants ne sont pas disponibles.
Structurez le fichier transformé final avec les colonnes requises : JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate et les attributs recommandés. Enregistrez ce fichier dans un seul CSV à importer.

Configuration

Rapports principaux : l’extraction combine les données de plusieurs rapports de la section Essential Reports de Greenhouse, principalement « All Applications » et « Interview Details ».
Colonnes clés (All Applications) : pour recueillir toutes les données nécessaires, sélectionnez notamment Application ID, Candidate, Job, Department, Recruiter, Status, Source, Offer Status et toutes les colonnes de date pertinentes, dont Applied On, Rejected On, Hired On, Offer Created On et Offer Accepted On.
Colonnes clés (Interview Details) : pour enregistrer les événements liés aux entretiens, sélectionnez notamment Application ID, Interview Name, Scheduled Start et Scorecard Submitted At.
Filtres de période : il est recommandé de filtrer les candidatures selon la date « Applied On » sur une période de 3 à 6 mois, afin d’obtenir un jeu de données pertinent et facile à gérer. Une période plus longue peut nuire aux performances.
Prérequis : la personne qui effectue l’export doit disposer des autorisations nécessaires dans Greenhouse pour accéder à la section « Reports » et consulter les données des candidats. Il faut généralement avoir le rôle « Job Admin » ou « Site Admin ».

a Exemple de requête config

This extraction method uses the Greenhouse user interface and does not involve a query language. The configuration is performed by selecting reports and columns.

**Report 1: All Applications**
*   **Report to run**: Go to Reports > Essential Reports > All Applications
*   **Columns to select**:
    *   Application ID
    *   Candidate
    *   Job
    *   Department
    *   Current Company
    *   Current Title
    *   Recruiter
    *   Status
    *   Source
    *   Applied On
    *   Rejected On
    *   Rejection Reason
    *   Hired On
    *   Last Stage Change On
    *   Offer Created On
    *   Offer Accepted On
    *   Offer Status

**Report 2: Interview Details**
*   **Report to run**: Go to Reports > Essential Reports > Interview Details
*   **Columns to select**:
    *   Application ID
    *   Candidate
    *   Job
    *   Interview Name
    *   Interviewer
    *   Scheduled Start
    *   Scheduled End
    *   Scorecard Submitted At

**Post-Export Transformation Logic**:
Combine the reports and unpivot the date columns to create the event log. Map source columns to `ActivityName` and `ActivityTimestamp`:
*   'Applied On' -> 'Application Received'
*   'Last Stage Change On' (when moving to a review stage) -> 'Application Reviewed'
*   'Last Stage Change On' (when moving to a screen stage) -> 'Recruiter Screen Conducted'
*   'Scheduled Start' -> 'Interview Scheduled'
*   'Scheduled Start' (after the time has passed) -> 'Interview Completed'
*   'Scorecard Submitted At' -> 'Feedback Submitted'
*   'Offer Created On' -> 'Offer Created'
*   'Last Stage Change On' (when moving to offer extended stage) -> 'Offer Extended'
*   'Offer Accepted On' -> 'Offer Accepted'
*   'Last Stage Change On' (when moving to background check stage) -> 'Background Check Initiated'
*   'Last Stage Change On' (when moving to onboarding stage) -> 'Onboarding Initiated'
*   'Hired On' -> 'Candidate Hired'
*   'Last Stage Change On' (when offer status is 'Rejected') -> 'Offer Rejected'
*   'Rejected On' -> 'Application Rejected'

Étapes

Prérequis : obtenir une clé API Greenhouse
- Connectez-vous à votre compte Greenhouse avec des autorisations de développeur.
- Accédez à Configure > Dev Center > API Credential Management.
- Cliquez sur « Create New API Key ».
- Saisissez une description, par exemple « ProcessMind Extraction ».
- Sélectionnez « Harvest » comme type.
- Accordez à la clé les autorisations nécessaires. Vous devez au minimum disposer des autorisations GET pour : Applications, Candidates, Jobs, Job Stages, Offers, Scorecards et Users.
- Copiez la clé API générée et conservez-la en lieu sûr. Vous ne pourrez plus la consulter par la suite.
Configurer votre environnement Python
- Vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système.
- Installez les bibliothèques Python nécessaires en exécutant les commandes suivantes dans votre terminal : pip install requests et pip install pandas.
Préparer le script Python
- Copiez le script Python complet fourni dans la section « query » dans un nouveau fichier, par exemple extract_greenhouse_logs.py.
- Remplacez le paramètre fictif YOUR_GREENHOUSE_API_KEY par la clé obtenue à l’étape 1.
- Modifiez la variable START_DATE_ISO pour définir le début de la période d’extraction. Pour un premier chargement, il est recommandé de choisir une date située 3 à 6 mois auparavant.
Personnaliser l’association des étapes aux activités
- Examinez le dictionnaire STAGE_TO_ACTIVITY dans le script.
- Ce dictionnaire associe les noms des étapes de recrutement propres à votre entreprise dans Greenhouse aux noms d’activité normalisés requis pour le Process Mining.
- Vous DEVEZ mettre à jour cette association pour qu’elle corresponde à la configuration Greenhouse de votre organisation. Par exemple, si l’étape « Recruiter Screen » s’appelle « Initial Recruiter Chat » chez vous, modifiez le dictionnaire en conséquence.
Exécuter le script d’extraction
- Ouvrez un terminal ou une invite de commandes.
- Accédez au répertoire où vous avez enregistré extract_greenhouse_logs.py.
- Exécutez le script avec la commande : python extract_greenhouse_logs.py.
- Le script se connectera à l’API Greenhouse, récupérera et traitera les données, puis affichera l’état d’avancement dans la console.
Récupérer le journal d’événements
- Une fois l’exécution terminée, le script crée un fichier nommé greenhouse_event_log.csv dans le même répertoire.
- Ce fichier CSV constitue le journal d’événements final, avec les colonnes et les activités requises.
Gérer les chargements incrémentiels
- Lors des exécutions suivantes, vous pouvez régler la variable START_DATE_ISO sur l’horodatage de la dernière extraction réussie. Vous ne récupérerez ainsi que les enregistrements nouveaux ou mis à jour, ce qui accélérera le traitement.
Importer les données dans ProcessMind
- Le fichier greenhouse_event_log.csv généré peut être importé directement dans ProcessMind. Vérifiez que les noms de colonnes du fichier correspondent bien aux champs de votre projet ProcessMind.

Configuration

Autorisations de la clé API : la clé API Harvest doit disposer d’un accès en lecture seule (GET) aux points de terminaison suivants : Applications, Candidates, Jobs, Job Stages, Offers, Scorecards et Users. Des autorisations insuffisantes entraîneront l’absence de certaines données d’activité.
Filtre de période : le script utilise le paramètre updated_after (variable START_DATE_ISO) pour filtrer les candidatures. Pour la première extraction, choisissez une période assez large, par exemple les six derniers mois. Pour les chargements incrémentiels suivants, indiquez l’horodatage de la dernière exécution réussie afin d’améliorer les performances.
Association des étapes aux activités : le dictionnaire STAGE_TO_ACTIVITY du script est essentiel. Il doit refléter précisément les étapes de recrutement propres à votre entreprise dans Greenhouse, afin d’identifier correctement des activités comme « Recruiter Screen Conducted » et « Background Check Initiated ».
Limitation du débit de l’API : le script insère un court délai fixe entre les requêtes API afin de respecter les limites de débit de Greenhouse, soit environ 20 requêtes par seconde. Pour de très gros volumes de données, vous devrez peut-être ajuster ce délai afin d’éviter les erreurs de connexion.
Granularité des données : l’extraction porte sur les événements horodatés et les changements de statut. Elle ne recueille pas les contenus détaillés, comme les notes d’entretien ou les échanges par e-mail, mais uniquement les métadonnées indiquant qu’un événement a eu lieu.

a Exemple de requête python

import requests
import pandas as pd
import time
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
API_KEY = class="hl-string">'YOUR_GREENHOUSE_API_KEY' class=class="hl-string">"hl-comment"># Replace with your Harvest API Key
START_DATE_ISO = class="hl-string">'2023-01-01T00:00:00Z' class=class="hl-string">"hl-comment"># Set the start date for the data pull (ISO 8601 format)
BASE_URL = class="hl-string">'https://harvest.greenhouse.io/v1/'

class=class="hl-string">"hl-comment"># IMPORTANT: Customize this dictionary to map your Greenhouse stage names to standard activities
STAGE_TO_ACTIVITY = {
    class="hl-string">'Application Review': class="hl-string">'Application Reviewed',
    class="hl-string">'Phone Screen': class="hl-string">'Recruiter Screen Conducted',
    class="hl-string">'Background Check': class="hl-string">'Background Check Initiated',
    class="hl-string">'Onboarding': class="hl-string">'Onboarding Initiated'
    class=class="hl-string">"hl-comment"># Add other custom stage mappings here, for example:
    class=class="hl-string">"hl-comment"># class="hl-string">'Hiring Manager Interview': class="hl-string">'Interview Completed'
}

class=class="hl-string">"hl-comment"># --- Script ---
headers = {class="hl-string">'Authorization': fclass="hl-string">'Basic {API_KEY}'}
event_log_records = []

def get_all_pages(endpoint, params=None):
    class="hl-string">"""Helper function to handle pagination for Greenhouse API requests."""
    url = fclass="hl-string">"{BASE_URL}{endpoint}"
    all_data = []
    page = 1
    while url:
        print(fclass="hl-string">"Fetching page {page} from {endpoint}...")
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data)
            class=class="hl-string">"hl-comment"># Greenhouse uses Link header for pagination
            url = response.links.get(class="hl-string">'next', {}).get(class="hl-string">'url')
            page += 1
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Respect rate limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {url}: {e}")
            break
        class=class="hl-string">"hl-comment"># Params are only needed for the first request
        params = None
    return all_data

print(class="hl-string">"Fetching initial data from Greenhouse API...")
params = {class="hl-string">'updated_after': START_DATE_ISO, class="hl-string">'per_page': 100}
applications = get_all_pages(class="hl-string">'applications', params=params)
jobs = {job[class="hl-string">'id']: job for job in get_all_pages(class="hl-string">'jobs', params={class="hl-string">'status': class="hl-string">'all'})}
candidates = {cand[class="hl-string">'id']: cand for cand in get_all_pages(class="hl-string">'candidates')}
users = {user[class="hl-string">'id']: user for user in get_all_pages(class="hl-string">'users')}

print(fclass="hl-string">"Processing {len(applications)} applications...")

for app in applications:
    job_id = app.get(class="hl-string">'job_id')
    job = jobs.get(job_id, {})
    candidate = candidates.get(app.get(class="hl-string">'candidate_id'), {})
    source_system = class="hl-string">"Greenhouse"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for all events for this application
    base_attributes = {
        class="hl-string">'JobApplicationId': app[class="hl-string">'id'],
        class="hl-string">'SourceSystem': source_system,
        class="hl-string">'LastDataUpdate': last_data_update,
        class="hl-string">'JobTitle': job.get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'JobDepartment': (job.get(class="hl-string">'departments', [{}])[0] or {}).get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'ApplicationStatus': app.get(class="hl-string">'status', class="hl-string">''),
        class="hl-string">'ApplicationSource': (app.get(class="hl-string">'source', {}) or {}).get(class="hl-string">'public_name', class="hl-string">''),
        class="hl-string">'RecruiterName': class="hl-string">''
    }
    if app.get(class="hl-string">'recruiter') and app[class="hl-string">'recruiter'].get(class="hl-string">'id') in users:
        recruiter_user = users[app[class="hl-string">'recruiter'][class="hl-string">'id']]
        base_attributes[class="hl-string">'RecruiterName'] = fclass="hl-string">"{recruiter_user.get('first_name', '')} {recruiter_user.get('last_name', '')}".strip()

    class=class="hl-string">"hl-comment"># --- Activity: Application Received ---
    if app.get(class="hl-string">'submitted_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Application Received',
            class="hl-string">'ActivityTimestamp': app[class="hl-string">'submitted_at'],
            class="hl-string">'OfferStatus': None
        })

    class=class="hl-string">"hl-comment"># --- Activities from Stage History ---
    for stage_move in app.get(class="hl-string">'stage_history', []):
        stage_name = stage_move.get(class="hl-string">'stage_name')
        if stage_name in STAGE_TO_ACTIVITY:
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': STAGE_TO_ACTIVITY[stage_name],
                class="hl-string">'ActivityTimestamp': stage_move.get(class="hl-string">'exited_on'), class=class="hl-string">"hl-comment"># Timestamp when they entered the *next* stage
                class="hl-string">'OfferStatus': None
            })

    class=class="hl-string">"hl-comment"># --- Activities: Interview Scheduled & Completed ---
    interviews = get_all_pages(fclass="hl-string">"applications/{app['id']}/scheduled_interviews")
    for interview in interviews:
        if interview.get(class="hl-string">'start'):
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Interview Scheduled',
                class="hl-string">'ActivityTimestamp': interview[class="hl-string">'start'][class="hl-string">'date'],
                class="hl-string">'OfferStatus': None
            })
        if interview.get(class="hl-string">'end'):
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Interview Completed',
                class="hl-string">'ActivityTimestamp': interview[class="hl-string">'end'][class="hl-string">'date'],
                class="hl-string">'OfferStatus': None
            })

    class=class="hl-string">"hl-comment"># --- Activity: Feedback Submitted ---
    scorecards = get_all_pages(fclass="hl-string">"scorecards", params={class="hl-string">'application_id': app[class="hl-string">'id']})
    for sc in scorecards:
        if sc.get(class="hl-string">'submitted_at'):
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Feedback Submitted',
                class="hl-string">'ActivityTimestamp': sc[class="hl-string">'submitted_at'],
                class="hl-string">'OfferStatus': None
            })

    class=class="hl-string">"hl-comment"># --- Activities: Hired or Application Rejected ---
    if app.get(class="hl-string">'status') == class="hl-string">'hired' and app.get(class="hl-string">'hired_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Candidate Hired',
            class="hl-string">'ActivityTimestamp': app[class="hl-string">'hired_at'],
            class="hl-string">'OfferStatus': None
        })
    elif app.get(class="hl-string">'status') == class="hl-string">'rejected' and app.get(class="hl-string">'rejected_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Application Rejected',
            class="hl-string">'ActivityTimestamp': app[class="hl-string">'rejected_at'],
            class="hl-string">'OfferStatus': None
        })

class=class="hl-string">"hl-comment"># --- Activities from Offers (separate loop for efficiency) ---
print(class="hl-string">"Fetching and processing offer data...")
all_offers = get_all_pages(class="hl-string">'offers')
for offer in all_offers:
    if not offer.get(class="hl-string">'application_id'):
        continue

    app_id = offer[class="hl-string">'application_id']
    class=class="hl-string">"hl-comment"># Find the corresponding application's base attributes
    matching_app = next((item for item in applications if item[class="hl-string">'id'] == app_id), None)
    if not matching_app:
        continue
    
    job_id = matching_app.get(class="hl-string">'job_id')
    job = jobs.get(job_id, {})
    base_attributes = {
        class="hl-string">'JobApplicationId': app_id,
        class="hl-string">'SourceSystem': class="hl-string">"Greenhouse",
        class="hl-string">'LastDataUpdate': datetime.utcnow().isoformat() + class="hl-string">'Z',
        class="hl-string">'JobTitle': job.get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'JobDepartment': (job.get(class="hl-string">'departments', [{}])[0] or {}).get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'ApplicationStatus': matching_app.get(class="hl-string">'status', class="hl-string">''),
        class="hl-string">'ApplicationSource': (matching_app.get(class="hl-string">'source', {}) or {}).get(class="hl-string">'public_name', class="hl-string">''),
        class="hl-string">'RecruiterName': class="hl-string">'' class=class="hl-string">"hl-comment"># Can be enriched similarly if needed
    }

    class=class="hl-string">"hl-comment"># Offer Created
    if offer.get(class="hl-string">'created_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Offer Created',
            class="hl-string">'ActivityTimestamp': offer[class="hl-string">'created_at'],
            class="hl-string">'OfferStatus': offer.get(class="hl-string">'status')
        })
    class=class="hl-string">"hl-comment"># Offer Extended
    if offer.get(class="hl-string">'sent_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Offer Extended',
            class="hl-string">'ActivityTimestamp': offer[class="hl-string">'sent_at'],
            class="hl-string">'OfferStatus': offer.get(class="hl-string">'status')
        })
    class=class="hl-string">"hl-comment"># Offer Accepted/Rejected
    if offer.get(class="hl-string">'resolved_at'):
        if offer.get(class="hl-string">'status') == class="hl-string">'accepted':
            activity_name = class="hl-string">'Offer Accepted'
        elif offer.get(class="hl-string">'status') == class="hl-string">'deprecated': class=class="hl-string">"hl-comment"># Often used for rejected
            activity_name = class="hl-string">'Offer Rejected'
        else:
            continue
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'ActivityTimestamp': offer[class="hl-string">'resolved_at'],
            class="hl-string">'OfferStatus': offer.get(class="hl-string">'status')
        })

print(class="hl-string">"Consolidating data and exporting to CSV...")
df = pd.DataFrame(event_log_records)
df_sorted = df.sort_values(by=[class="hl-string">'JobApplicationId', class="hl-string">'ActivityTimestamp'])
df_sorted.to_csv(class="hl-string">'greenhouse_event_log.csv', index=False)

print(class="hl-string">"Extraction complete. File 'greenhouse_event_log.csv' created.")

Étapes

Vérifiez que votre plateforme ETL sous licence propose un connecteur Greenhouse et que celui-ci prend en charge les objets Greenhouse ou les jeux de données répliqués contenant les candidatures, l’historique des étapes, les entretiens, les retours d’entretien, les offres, les changements de statut des offres, les vérifications d’antécédents, les transmissions vers l’intégration et les résultats du recrutement. Les noms des objets varient selon la plateforme. Consultez donc le catalogue du connecteur et l’explorateur de schémas au lieu de supposer les noms des tables.
Créez la connexion à la source Greenhouse dans la plateforme ETL. Saisissez les identifiants Greenhouse, les informations d’autorisation, les paramètres de réplication et les filtres propres à votre entreprise qui sont nécessaires dans votre environnement. Suivez la procédure d’autorisation documentée pour le connecteur et n’accordez que les autorisations nécessaires à la lecture des données de recrutement sélectionnées.
Configurez un entrepôt de destination et activez la réplication des objets sources nécessaires à la création du journal d’événements. Sélectionnez au minimum les objets qui exposent les candidatures, l’historique des statuts ou des étapes, les entretiens, les retours d’entretien, les offres, les changements de statut des offres, les événements de vérification d’antécédents, les transmissions vers l’intégration et les résultats du recrutement. Si un objet requis n’est pas disponible, consignez cette limite et associez-lui la source prise en charge la plus proche, selon votre configuration Greenhouse.
Définissez la période de réplication initiale en fonction de la période d’analyse souhaitée, généralement les 3 à 6 derniers mois. Prévoyez une période de recherche antérieure si des candidatures créées avant la période sélectionnée ont évolué pendant celle-ci. Configurez la réplication incrémentielle et conservez les horodatages de mise à jour de la source lorsqu’ils sont disponibles.
Examinez le schéma répliqué et remplacez chaque valeur fictive de la requête par le schéma, les noms de tables et de colonnes, les champs d’horodatage, les identifiants et les valeurs de statut réellement exposés par votre connecteur dans l’entrepôt de destination. Ne supposez pas qu’un changement d’étape, un entretien, un retour, une offre, une vérification d’antécédents, une transmission vers l’intégration ou un résultat de recrutement est disponible s’il ne figure pas dans les données répliquées.
Configurez la requête de transformation sous forme d’union d’extractions d’événements explicites. Chaque extraction doit renvoyer JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource et OfferStatus. Normalisez les horodatages dans un même fuseau horaire, supprimez les enregistrements sans identifiant de candidature valide ou sans horodatage d’activité, et conservez une ligne pour chaque événement source correspondant à une activité.
Appliquez les règles d’association des événements. Utilisez les données de création ou de soumission d’une candidature pour Application Received, une étape de révision explicite ou une transition de statut pour Application Reviewed, un enregistrement d’entretien de présélection par un recruteur ou la transition d’étape configurée pour Recruiter Screen Conducted, une confirmation d’entretien ou son horodatage planifié pour Interview Scheduled, la fin d’un entretien ou l’horodatage d’envoi du retour pour Interview Completed, l’envoi du retour pour Feedback Submitted, la création d’une offre pour Offer Created, le statut d’offre envoyée ou proposée pour Offer Extended, le statut d’offre acceptée pour Offer Accepted, un événement enregistré de lancement de vérification d’antécédents pour Background Check Initiated, un événement de transmission ou de lancement de l’intégration pour Onboarding Initiated, un résultat d’embauche pour Candidate Hired, le refus d’une offre pour Offer Rejected, et un résultat de candidature rejetée ou une transition vers une étape de rejet pour Application Rejected.
Chargez le résultat transformé dans une table ou une vue de destination réservée au journal d’événements ProcessMind. Conservez les événements sources en double, sauf si une règle métier documentée les identifie comme des doublons techniques. Si une déduplication est nécessaire, limitez-la aux événements sources identiques, par exemple selon l’identifiant de candidature, le nom de l’activité, son horodatage et l’identifiant de l’enregistrement source.
Validez le résultat à l’aide des contrôles ci-dessous. Vérifiez la présence de toutes les colonnes requises, la validité des horodatages, la représentation de chaque activité requise lorsque les données sources existent et l’unicité de l’identifiant de cas pour chaque candidature. Examinez séparément les candidatures rejetées, retirées, archivées et incomplètes afin que le filtrage ne supprime pas involontairement des résultats de processus valides.
Exportez ou exposez le résultat final sous forme de fichier CSV plat ou via une connexion d’entrepôt prise en charge pour l’importation dans ProcessMind. Associez JobApplicationId à l’identifiant de cas, ActivityName à l’activité et ActivityTimestamp à l’horodatage de l’événement. Incluez SourceSystem et LastDataUpdate, conservez les attributs recommandés, utilisez un format d’horodatage cohérent, par exemple ISO 8601 avec le fuseau horaire, et ne comptez pas sur ProcessMind pour déduire des événements absents du fichier.

Configuration

Connecteur et destination : utilisez une plateforme ETL sous licence dotée d’un connecteur Greenhouse pris en charge et d’un entrepôt de destination accessible à la couche de transformation. Les capacités du connecteur, les noms des objets, les intervalles d’actualisation et la prise en charge de la réplication historique dépendent de la plateforme et de l’abonnement choisis.
Autorisation de la source : configurez les identifiants Greenhouse et les autorisations requises par le connecteur. Vérifiez que le compte autorisé peut lire les candidatures, l’historique des étapes ou des statuts, les entretiens, les retours, les offres ainsi que les données d’intégration ou de vérification d’antécédents utilisées dans l’association.
Objets répliqués : sélectionnez tous les objets sources nécessaires aux 14 extractions d’événements. Ne répliquez pas uniquement la table des candidatures actuelles si l’historique des changements d’étape, les actions liées aux entretiens, l’envoi des retours, les transitions des offres ou les transmissions en aval sont stockés séparément.
Période : commencez par 3 à 6 mois pour l’analyse opérationnelle. Étendez cette période pour mesurer le cycle complet des candidatures, car celles créées auparavant peuvent atteindre les étapes d’entretien, d’offre ou d’embauche plus tard.
Actualisation incrémentielle : conservez les horodatages de création, d’occurrence et de dernière mise à jour de la source lorsqu’ils sont disponibles. Configurez une actualisation récurrente adaptée au délai de mise à disposition des rapports et prévoyez une courte période de chevauchement pour les enregistrements reçus tardivement ou corrigés.
Filtres : appliquez uniquement des filtres documentés propres à l’entreprise, par exemple par organisation, département, poste, lieu ou date de candidature. N’utilisez pas de filtres génériques comme Company Code ou Document Type, sauf si ces champs figurent réellement dans le schéma Greenhouse répliqué et sont nécessaires à votre configuration.
Association des activités : consignez l’association entre le type d’événement, l’étape, le statut ou l’horodatage source et chaque ActivityName. Définissez les valeurs exactes pour les étapes de révision, les présélections téléphoniques, les rejets, les offres, les acceptations, les vérifications d’antécédents, l’intégration et les résultats d’embauche, en fonction des valeurs utilisées par votre organisation.
Gestion des valeurs nulles : autorisez les valeurs nulles pour RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource et OfferStatus lorsque la source ne les fournit pas. En revanche, les identifiants et horodatages requis doivent être rejetés ou faire l’objet d’une vérification s’ils sont manquants.
Fuseaux horaires : convertissez tous les horodatages d’activité dans un même fuseau horaire de référence, tout en conservant l’horodatage source d’origine si la traçabilité est nécessaire. Vérifiez que LastDataUpdate correspond à l’heure d’actualisation ou d’extraction, et non à l’heure de l’activité.
Performances : pour les grands jeux de données, filtrez les extractions sources selon les partitions d’horodatage répliquées, sélectionnez uniquement les colonnes requises, utilisez des chargements incrémentiels et matérialisez le journal d’événements final. Évitez de joindre à répétition l’historique complet aux enregistrements de candidature actuels sans identifiants indexés.
Conservation des données : vérifiez que la plateforme ETL et l’accès à Greenhouse conservent l’historique des étapes, des entretiens, des retours, des offres et des résultats pour la période sélectionnée. Les tables décrivant uniquement l’état actuel ne permettent pas de reconstituer fiablement les activités passées.
Association dans ProcessMind : configurez JobApplicationId comme identifiant de cas, ActivityName comme champ d’activité et ActivityTimestamp comme horodatage de l’événement. Vérifiez que le fichier exporté contient une ligne explicite par activité et ne dépend pas de transitions déduites.

a Exemple de requête config

WITH
application_received AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Application Received' AS ActivityName,
        [ApplicationReceivedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your application event table]
    WHERE [ApplicationReceivedTimestamp] IS NOT NULL
),
application_reviewed AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Application Reviewed' AS ActivityName,
        [StageChangeTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your application stage history table]
    WHERE [StageChangeTimestamp] IS NOT NULL
      AND [NewStageName] IN ('In Review')
),
recruiter_screen_conducted AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Recruiter Screen Conducted' AS ActivityName,
        [ScreenCompletedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your recruiter screen event table]
    WHERE [ScreenCompletedTimestamp] IS NOT NULL
),
interview_scheduled AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Interview Scheduled' AS ActivityName,
        [InterviewScheduledTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your interview table]
    WHERE [InterviewScheduledTimestamp] IS NOT NULL
),
interview_completed AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Interview Completed' AS ActivityName,
        [InterviewCompletedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your interview table]
    WHERE [InterviewCompletedTimestamp] IS NOT NULL
),
feedback_submitted AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Feedback Submitted' AS ActivityName,
        [FeedbackSubmittedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your interview feedback table]
    WHERE [FeedbackSubmittedTimestamp] IS NOT NULL
),
offer_created AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Created' AS ActivityName,
        [OfferCreatedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferCreatedTimestamp] IS NOT NULL
),
offer_extended AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Extended' AS ActivityName,
        [OfferExtendedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferExtendedTimestamp] IS NOT NULL
),
offer_accepted AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Accepted' AS ActivityName,
        [OfferAcceptedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferAcceptedTimestamp] IS NOT NULL
),
background_check_initiated AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Background Check Initiated' AS ActivityName,
        [BackgroundCheckInitiatedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your background check event table]
    WHERE [BackgroundCheckInitiatedTimestamp] IS NOT NULL
),
onboarding_initiated AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Onboarding Initiated' AS ActivityName,
        [OnboardingInitiatedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your onboarding handoff table]
    WHERE [OnboardingInitiatedTimestamp] IS NOT NULL
),
candidate_hired AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Candidate Hired' AS ActivityName,
        [HiredTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your hiring outcome table]
    WHERE [HiredTimestamp] IS NOT NULL
),
offer_rejected AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Rejected' AS ActivityName,
        [OfferRejectedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferRejectedTimestamp] IS NOT NULL
),
application_rejected AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Application Rejected' AS ActivityName,
        [ApplicationRejectedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your application outcome table]
    WHERE [ApplicationRejectedTimestamp] IS NOT NULL
)
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM application_received
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM application_reviewed
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM recruiter_screen_conducted
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM interview_scheduled
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM interview_completed
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM feedback_submitted
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_created
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_extended
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_accepted
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM background_check_initiated
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM onboarding_initiated
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM candidate_hired
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_rejected
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM application_rejected;

Prêt à commencer ?

Tirez le meilleur parti de vos données de recrutement. Utilisez ce modèle dès aujourd’hui pour optimiser votre processus de recrutement et prendre des décisions fondées sur les données.

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

Optimisez dès aujourd’hui votre acquisition de talents dans Greenhouse

Réduisez de 30 % le temps de cycle de recrutement et améliorez dès aujourd’hui l’expérience des candidats.

Démarrez l’essai gratuit

Aucune carte bancaire requise • Configuration en 5 minutes

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 liés au recrutement et à l’acquisition de talents

Activités liées au recrutement et à l’acquisition de talents

Guides d’extraction

Générateur de rapports Greenhouse pour les exports CSV manuels

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l’API Harvest de Greenhouse

Étapes

Configuration

a Exemple de requête python

Outil ETL automatisé avec connecteur Greenhouse

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez dès aujourd’hui votre acquisition de talents dans Greenhouse

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 liés au recrutement et à l’acquisition de talents

Activités liées au recrutement et à l’acquisition de talents

Guides d’extraction

Générateur de rapports Greenhouse pour les exports CSV manuels

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l’API Harvest de Greenhouse

Étapes

Configuration

a Exemple de requête python

Outil ETL automatisé avec connecteur Greenhouse

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez dès aujourd’hui votre acquisition de talents dans Greenhouse

Nous respectons votre vie privée

Prêt à commencer ?