> Kontinuierliche Prozessverbesserung > Recruiting und Talentgewinnung > Workday Recruiting > Daten Template

Ihr Daten-Template für Recruiting und Talentgewinnung

Workday Recruiting

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Recruiting und Talentgewinnung (19) Aktivitäten im Recruiting und in der Talentgewinnung (15) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für Recruiting und Talentgewinnung

Dieses Template zeigt Ihnen, welche Daten Sie für die Analyse Ihrer Recruiting- und Talentgewinnungsprozesse erfassen sollten. Es enthält wichtige Attribute und Aktivitäten sowie Hinweise dazu, wie Sie die Daten aus Ihrem Workday-Recruiting-System extrahieren. Damit bereiten Sie Ihre Daten effizient vor und können schneller mit Process Mining beginnen.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Analyse
Hinweise zur Datenextraktion aus Workday Recruiting

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Recruiting und Talentgewinnung

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Recruiting und Talentgewinnung umfassend zu analysieren und detaillierte Erkenntnisse zu Ihrem Einstellungsprozess zu gewinnen.

3 Erforderlich 5 Empfohlen 11 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des konkreten Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Recruiting-Prozess stattgefunden hat.
Beschreibung Der Aktivitätsname bezeichnet einen einzelnen Schritt oder Meilenstein im Einstellungsverlauf, etwa „Bewerbung vorausgewählt“, „Interview geplant“ oder „Angebot unterbreitet“. Diese Aktivitäten bilden die Ereignisfolge des Prozesses. Das Attribut ist entscheidend, um den Prozessablauf zu visualisieren, unterschiedliche Bewerbungswege zu erkennen und Häufigkeit sowie Reihenfolge der Ereignisse zu analysieren. Es bildet die Grundlage dafür, zu verstehen, was im Prozess geschieht. Warum das wichtig ist Dieses Attribut legt die Schritte des Recruiting-Prozesses fest und ermöglicht die Visualisierung und Analyse des Prozessablaufs. Woher beziehen Abgeleitet aus den Namen der Geschäftsprozessschritte oder Statusänderungen in den Bewerbungsdaten von Workday Recruiting. Beispiele Bewerbung vorausgewähltInterview abgeschlossenAngebot angenommenBewerbende Person abgelehnt
	Ereigniszeit EventTime	Der Timestamp, der angibt, wann die Aktivität oder das Ereignis stattgefunden hat.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit einer Recruiting-Aktivität genau. Timestamps bilden die Grundlage des Process Mining, da sie die chronologische Reihenfolge der Ereignisse festhalten. In der Analyse dienen Timestamps dazu, Zeitspannen zwischen Aktivitäten zu berechnen, die Gesamtdurchlaufzeit wie die „Time-to-Hire“ zu messen und Engpässe durch Verzögerungen im Prozess zu erkennen. Sie sind für jede zeitbezogene Analyse des Recruiting-Prozesses unerlässlich. Warum das wichtig ist Timestamps sind entscheidend, um zeitbezogene KPIs zu berechnen, die Prozessdauer zu verstehen und Engpässe aufzudecken. Woher beziehen Entspricht dem Abschluss- oder Transaktionsdatum eines Geschäftsprozessschritts in Workday Recruiting. Beispiele 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	Stellenbewerbung JobApplicationId	Die eindeutige Kennung der Stellenbewerbung einer Person. Sie dient als zentrale Case-ID für den Recruiting-Prozess.
Beschreibung Die ID der Stellenbewerbung erfasst den gesamten Bewerbungsverlauf einer Person für eine bestimmte Stellenausschreibung eindeutig, von der ersten Einreichung bis zur endgültigen Entscheidung. Jede Interaktion, Statusänderung und jeder Entscheidungspunkt im Zusammenhang mit der Bewerbung ist mit dieser Kennung verknüpft. Im Process Mining ist dieses Attribut grundlegend. Es ermöglicht, den Prozessablauf für jede bewerbende Person von Anfang bis Ende zu rekonstruieren und Durchlaufzeiten, Engpässe sowie die durchlaufenen Pfade zu analysieren. Als zentrales Element verbindet es alle zugehörigen Aktivitäten zu einem zusammenhängenden Case. Warum das wichtig ist Diese zentrale Case-ID verknüpft alle Recruiting-Aktivitäten für eine einzelne bewerbende Person und ermöglicht so die Analyse des gesamten Einstellungsverlaufs. Woher beziehen Diese Kennung ist ein zentrales Element in Workday Recruiting und in der Regel in Berichten und Datenquellen zu Stellenbewerbungen verfügbar. Beispiele APP-2023-001234APP-2023-005678APP-2024-009101
	Abteilung Department	Die Abteilung oder Geschäftseinheit, der die Stellenausschreibung zugeordnet ist.
Beschreibung Dieses Attribut gibt die Organisationseinheit an, für die die Person eingestellt wird, etwa „Technik“, „Marketing“ oder „Finanzen“. Es wird aus der Aufsichtsorganisation abgeleitet, die der Stellenausschreibung zugeordnet ist. In der Analyse ermöglicht eine Filterung nach Abteilung den Vergleich der Einstellungsprozesse in verschiedenen Unternehmensbereichen. Das Dashboard „Effizienz der Bewerbungsvorauswahl“ zeigt damit, ob die Vorauswahl in bestimmten Abteilungen länger dauert, was auf unterschiedliche Vorgehensweisen oder Ressourcenbedarfe hindeuten kann. Warum das wichtig ist Ermöglicht den Vergleich von Leistung und Effizienz der Recruiting-Prozesse in verschiedenen Geschäftseinheiten und Abteilungen. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Dieses Attribut wird aus der Aufsichtsorganisation abgeleitet, die der Stellenausschreibung zugeordnet ist. Beispiele EntwicklungVertriebPersonalwesenFinanzen
	Bewerbungsquelle ApplicationSource	Der Kanal oder die Quelle, über den beziehungsweise die die Bewerbung eingegangen ist.
Beschreibung Dieses Attribut gibt an, wie eine Person auf die Stelle aufmerksam wurde und sich beworben hat, etwa über die Karriereseite des Unternehmens, LinkedIn, eine Empfehlung durch Mitarbeitende oder eine Personalvermittlung. Die Kenntnis der Quelle ist wichtig, um Recruiting-Strategie und Budget gezielt auszurichten. Sie bildet die Grundlage für das Dashboard „Wirksamkeit der Recruiting-Kanäle“ und die KPI „Annahmequote von Angeboten nach Quelle“. So lässt sich ermitteln, welche Kanäle die meisten und am besten geeigneten Bewerbenden liefern. Warum das wichtig ist Hilft, die Wirksamkeit verschiedener Recruiting-Kanäle zu bewerten und datengetrieben zu entscheiden, wo Ressourcen eingesetzt werden sollen. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Dies ist ein Standardfeld in der Stellenbewerbung. Beispiele LinkedInEmpfehlung durch MitarbeitendeKarriereseite des UnternehmensIndeed
	Bewerbungsstatus ApplicationStatus	Das endgültige Ergebnis oder der aktuelle Status der Bewerbung.
Beschreibung Dieses Attribut erfasst den endgültigen Status einer Bewerbung, zum Beispiel „Eingestellt“, „Vom Unternehmen abgelehnt“, „Angebot abgelehnt“ oder „Vom Kandidaten zurückgezogen“. Es bildet den Endzustand des Prozesses für eine bestimmte Bewerbung ab. Dieser Status ist für die Ergebnisanalyse entscheidend. Er dient zur Berechnung von Konversionsraten, Annahmequoten für Angebote und Abbruchquoten in den verschiedenen Phasen. Um die Wirksamkeit des Gesamtprozesses zu verbessern, müssen Sie verstehen, warum und an welcher Stelle Bewerbungen enden. Warum das wichtig ist Definiert das Ergebnis jedes Cases. Diese Information ist entscheidend für die Berechnung von Konversions- und Abbruchquoten sowie für die Bewertung des Gesamterfolgs des Prozesses. Woher beziehen In Workday Recruiting ist dies üblicherweise das Feld für den endgültigen Status oder den Statusgrund des Objekts „Bewerbung“. Beispiele EingestelltAbgelehntAngebot abgelehntBewerbung zurückgezogen
	Einstellende Führungskraft HiringManager	Der Name der einstellenden Führungskraft für die Stelle, auf die sich die Person beworben hat.
Beschreibung Dieses Attribut gibt die Führungskraft des Teams oder der Abteilung mit der offenen Stelle an. Die einstellende Führungskraft ist eine wichtige beteiligte Person im Entscheidungsprozess, insbesondere während der Interviews und der Feedbackphasen. Diese Daten sind für das Dashboard „Fristgerechtes Feedback einstellender Führungskräfte“ unerlässlich. Wenn Unternehmen für jede Führungskraft die Zeit zwischen „Interview abgeschlossen“ und „Feedback übermittelt“ analysieren, können sie Verzögerungen erkennen und gezielt mit den betreffenden Führungskräften daran arbeiten, den Einstellungsprozess zu beschleunigen. Warum das wichtig ist Wichtig, um die Beteiligung einstellender Führungskräfte zu analysieren und Verzögerungen bei der Feedbackabgabe zu erkennen, die sich direkt auf die Erfahrung der Bewerbenden auswirken. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Dieses Attribut ist in der Regel Teil der Angaben zur Aufsichtsorganisation oder zur Stellenausschreibung. Beispiele Susan AdamsDavid ChenAngela Rodriguez
	Name der Recruiterin oder des Recruiters RecruiterName	Der Name der Recruiterin oder des Recruiters, die beziehungsweise der für die Stellenbewerbung zuständig ist.
Beschreibung Dieses Attribut gibt die für die Stellenbewerbung und Stellenausschreibung zuständige Person aus dem Talent Acquisition Team oder dem Recruiting an. Sie begleitet die bewerbende Person in der Regel durch den Prozess. Die Analyse nach Recruiterin oder Recruiter hilft, Teamleistung und Arbeitsbelastung zu verstehen. Sie bildet die Grundlage für das Dashboard „Leistung und Durchsatz im Recruiting“ und für KPIs wie „Abweichung der Time-to-Offer nach Recruiterin oder Recruiter“. So lassen sich Effizienz vergleichen und bewährte Vorgehensweisen erkennen. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Recruiterin oder Recruiter. So lassen sich besonders leistungsstarke Mitarbeitende, Schulungsbedarf und eine ungleichmäßige Arbeitsverteilung erkennen. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Dieses Attribut ist in der Regel mit den Objekten „Job Requisition“ oder „Job Application“ verknüpft. Beispiele John SmithEmily JonesMaria Garcia
	Ablehnungsgrund RejectionReason	Der Grund für die Ablehnung einer Bewerbung.
Beschreibung Wird eine Bewerbung auf den Status „Abgelehnt“ gesetzt, liefert dieses Attribut den Kontext für die Entscheidung. Mögliche Gründe sind „Passt nicht zur Unternehmenskultur“, „Erforderliche Fähigkeiten fehlen“ oder „Stelle mit einem anderen Kandidaten besetzt“. Die Analyse der Ablehnungsgründe hilft dabei, Muster im Einstellungsprozess zu erkennen. Eine hohe Zahl von Ablehnungen wegen „Erforderliche Fähigkeiten fehlen“ in einer späten Phase kann beispielsweise auf eine unzureichend formulierte Stellenbeschreibung hindeuten. Diese Daten sind wichtig für das Dashboard „Schwerpunkte bei Bewerbungsabbrüchen“, denn sie zeigen, warum Bewerbungen abgebrochen werden. Warum das wichtig ist Liefert qualitative Erkenntnisse dazu, warum Kandidaten im Prozess nicht weiterkommen. So lassen sich Stellenbeschreibungen und Auswahlkriterien verbessern. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Häufig handelt es sich um einen Unterstatus oder einen Grundcode, der dem Ablehnungsschritt zugeordnet ist. Beispiele Nicht qualifiziertErfahrung passt nichtGeeignetere Kandidaten gefundenStelle geschlossen
	Angebotssumme OfferAmount	Das Gehalt, das dem Kandidaten angeboten wird.
Beschreibung Dieses Attribut enthält den Wert des Grundgehalts, das einem Kandidaten im Stellenangebot vorgeschlagen wird. Es ist eine wichtige Information in der letzten Phase des Recruiting-Prozesses. Die Analyse der Angebotssummen zeigt Vergütungstrends und die Wettbewerbsfähigkeit der Angebote. In Verbindung mit dem Status „Angebot angenommen“ lässt sich feststellen, ob die Vergütung ein Grund für die Ablehnung von Angeboten ist. Das Attribut ist ein wichtiger Bestandteil des Dashboards „Angebotsverwaltung und Annahmequoten“. Warum das wichtig ist Unterstützt die Analyse der Vergütungsstrategie und ihrer Auswirkungen auf die Annahmequote von Angeboten. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Diese Information ist Teil der Daten zum Geschäftsprozess „Angebot“. Beispiele 8500012000065000
	Arbeitsort JobLocation	Der geografische Standort oder das Land der Stelle.
Beschreibung Dieses Attribut gibt die Stadt, das Bundesland oder das Land an, in dem sich die Stelle befindet. Bei Remote-Stellen kann es eine Region angeben oder den Wert „Remote“ enthalten. Der Standort ist eine wichtige Analysedimension. Sie können damit die „Zeit bis zur Einstellung“ und weitere KPIs für verschiedene Regionen vergleichen. So werden Unterschiede sichtbar, die auf lokale Marktbedingungen, die Verfügbarkeit von Talenten oder regionale Prozessabweichungen zurückzuführen sein können. Warum das wichtig ist Ermöglicht die geografische Analyse des Recruiting-Prozesses und macht regionale Unterschiede bei Zykluszeiten und Effizienz sichtbar. Woher beziehen Diese Information ist Teil der Details zur Stellenausschreibung in Workday. Beispiele New York, NYLondon, Vereinigtes KönigreichRemote (USA)Berlin, Deutschland
	Automatisiert IsAutomated	Kennzeichnet, ob das System die Aktivität automatisch ausgeführt hat.
Beschreibung Dieses boolesche Attribut gibt an, ob ein Benutzer oder ein automatisierter Systemprozess einen Schritt ausgeführt hat. Eine automatisch versendete Bestätigung über den Eingang einer Bewerbung ist beispielsweise eine automatisierte Aktivität. Für die Ermittlung von Effizienzpotenzialen ist es wichtig zu wissen, welche Schritte automatisiert ablaufen. So können Sie die Auswirkungen der Automatisierung auf Zykluszeiten und Ressourceneinsatz bewerten. Warum das wichtig ist Unterscheidet manuelle Aktivitäten von systemgesteuerten Aktivitäten. Das ist wichtig, um Automatisierungspotenziale zu erkennen und deren Auswirkungen zu messen. Woher beziehen Diese Information muss abgeleitet werden, indem Sie Systembenutzerkonten oder bestimmte Ereignistypen identifizieren, die in Workday bekanntermaßen automatisiert ablaufen. Beispiele truefalse
	Kandidaten-ID CandidateId	Die eindeutige Kennung des Kandidaten.
Beschreibung Die Kandidaten-ID identifiziert eine Person im Recruiting-System eindeutig, unabhängig davon, auf wie viele Stellen sie sich beworben hat. So lässt sich der Verlauf der Bewerbungen einer Person im Unternehmen nachvollziehen. Dieses Attribut eignet sich, um die Candidate Experience im Zeitverlauf zu analysieren. Damit können Sie beispielsweise feststellen, ob zuvor abgelehnte Kandidaten sich erneut bewerben und wie sich ihre Bewerbungsverläufe unterscheiden. Außerdem lässt sich erkennen, ob ein Kandidat gleichzeitig für mehrere Rollen berücksichtigt wird. Warum das wichtig ist Ermöglicht eine kandidatenbezogene Sicht auf den Prozess und verfolgt einzelne Personen über mehrere Bewerbungen und längere Zeiträume hinweg. Woher beziehen Dies ist die primäre Kennung des Objekts „Kandidat“ in Workday Recruiting. Beispiele CAND-98765CAND-11223CAND-54321
	Kandidatentyp CandidateType	Gibt an, ob es sich um einen internen Mitarbeitenden oder einen externen Bewerber handelt.
Beschreibung Dieses Attribut ordnet Kandidaten Kategorien wie „Intern“ oder „Extern“ zu. Einstellungsprozess, Zeitrahmen und Richtlinien können sich zwischen diesen beiden Gruppen deutlich unterscheiden. Für ein vollständiges Bild sollten Sie den Prozess für interne und externe Kandidaten getrennt analysieren. So kann die Organisation die Effizienz ihrer internen Mobilitätsprogramme mit den Ergebnissen der externen Personalgewinnung vergleichen und beide Prozesse gezielt verbessern. Warum das wichtig ist Ermöglicht die getrennte Analyse interner und externer Einstellungsprozesse, die sich häufig bei Schritten, SLAs und Zielen unterscheiden. Woher beziehen Lesen Sie die Dokumentation zu Workday Recruiting. Dies ist ein Standardfeld im Kandidatenprofil oder in der Bewerbung. Beispiele InternExtern
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten zuletzt aus dem Quellsystem aktualisiert oder extrahiert wurden.
Beschreibung Dieses Attribut zeigt, wie aktuell die analysierten Daten sind. Es gibt Datum und Uhrzeit des letzten Datenabrufs aus Workday Recruiting an. So können Benutzer den Aktualitätsstand der Analyse einschätzen und die Erkenntnisse richtig einordnen. Sie sehen, ob die Daten in Echtzeit vorliegen oder einen bestimmten Zeitpunkt abbilden. Warum das wichtig ist Gibt Auskunft über die Aktualität der Daten, damit Benutzer den Stand der Prozessanalyse richtig einschätzen können. Woher beziehen Dieser Timestamp wird während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und hinzugefügt. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Daten an, in diesem Fall Workday Recruiting. Es unterstützt die Data Governance und die Fehlerbehebung, insbesondere wenn Daten aus mehreren Systemen zusammengeführt werden. Bei einer Analyse mit nur einem System mag das nebensächlich erscheinen. Es empfiehlt sich dennoch, das Attribut immer aufzunehmen. So bleibt die Datenherkunft nachvollziehbar, was besonders wichtig wird, wenn später weitere HR-Systeme angebunden werden. Warum das wichtig ist Gibt die Datenherkunft an. Das ist wichtig für Data Governance, Validierung und den Umgang mit Daten aus mehreren Quellen. Woher beziehen Dies ist ein statischer Wert („Workday Recruiting“), der bei der Datenextraktion und -transformation hinzugefügt wird. Beispiele Workday Recruiting
	Stellenausschreibungs-ID JobRequisitionId	Die eindeutige Kennung der offenen Stelle, auf die sich die Person beworben hat.
Beschreibung Die Stellenausschreibungs-ID ist die Kennung der freigegebenen offenen Stelle. Einer einzelnen Stellenausschreibung können mehrere Bewerbungen zugeordnet sein. Mit diesem Attribut können Sie die Daten auf Ebene der Stellenausschreibung analysieren. So lässt sich beispielsweise ermitteln, wie lange eine Stelle ausgeschrieben war, wie viele Kandidaten angesprochen wurden oder wie sich die Recruiting-Trichter verschiedener Stellenarten unterscheiden, etwa bei Stellen in der Entwicklung und im Vertrieb. Warum das wichtig ist Verknüpft mehrere Bewerbungen mit einer offenen Stelle und ermöglicht so die Analyse von Kennzahlen und Recruiting-Trichtern auf Ebene der Stellenausschreibung. Woher beziehen Dies ist die primäre Kennung des Objekts „Stellenausschreibung“ in Workday Recruiting und ist mit jeder Bewerbung verknüpft. Beispiele REQ-2023-105REQ-2024-012REQ-2024-345
	Zeit bis zur Einstellung TimeToHire	Die Gesamtzeit vom Eingang einer Bewerbung bis zur Einstellung des Kandidaten.
Beschreibung Diese Berechnung auf Case-Ebene misst die Gesamtdauer des Recruiting-Prozesses für erfolgreiche Kandidaten. Sie ergibt sich aus der Zeit zwischen den Ereignissen „Bewerbung eingegangen“ und „Kandidat eingestellt“. Die durchschnittliche Zeit bis zur Einstellung zählt zu den wichtigsten KPIs im Recruiting. Sie gibt einen Überblick über die Effizienz des gesamten Einstellungsprozesses. Wenn Sie diese Kennzahl im Zeitverlauf und über verschiedene Abteilungen hinweg verfolgen, erkennen Sie systematische Verbesserungen oder Verschlechterungen. Warum das wichtig ist Eine zentrale KPI auf hoher Ebene, die die Effizienz des gesamten Recruiting-Trichters vom Anfang bis zum Ende misst. Woher beziehen Diese Kennzahl wird anhand der Event-Log-Daten berechnet, nachdem sie aus Workday extrahiert wurden. Beispiele 259200043200003456000
	Zurückgezogen IsWithdrawn	Kennzeichnet, ob der Kandidat die Bewerbung zurückgezogen hat.
Beschreibung Dieses berechnete boolesche Attribut ist wahr, wenn der endgültige Bewerbungsstatus „Vom Kandidaten zurückgezogen“ oder ein ähnlicher Status ist. Damit lassen sich Cases herausfiltern, in denen der Kandidat den Prozess abgebrochen hat. Das Attribut vereinfacht die Analyse im Dashboard „Schwerpunkte bei Bewerbungsabbrüchen“ und der KPI „Bewerbungsabbruchquote“. Durch einfaches Filtern und Aggregieren können Sie ermitteln, in welchen Phasen Kandidaten am häufigsten aus dem Prozess aussteigen. Warum das wichtig ist Ermöglicht die gezielte Analyse von Abbrüchen durch Kandidaten und liefert Erkenntnisse zur Candidate Experience und zu Reibungspunkten im Prozess. Woher beziehen Wird bei der Datentransformation anhand des Attributs „ApplicationStatus“ berechnet. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten im Recruiting und in der Talentgewinnung

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log. So können Sie den Prozess zuverlässig entdecken und Engpässe in Ihrem Einstellungs-Workflow erkennen.

7 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Angebot angenommen	Bezeichnet die formelle Annahme des Stellenangebots durch die bewerbende Person. Das Ereignis wird erfasst, wenn die Person die Aufgabe „Accept Offer“ im Workday-Portal abschließt oder eine Recruiterin beziehungsweise ein Recruiter den Status manuell aktualisiert.
Warum das wichtig ist Diese Aktivität ist entscheidend, um die Annahmequote von Angeboten nach Quelle, Abteilung oder Recruiterin beziehungsweise Recruiter zu berechnen. Sie löst außerdem nachfolgende Aktivitäten vor dem Arbeitsbeginn aus, etwa Background Checks. Woher beziehen Wird ausdrücklich protokolliert, wenn eine bewerbende Person das Angebot über ihr Bewerbungsportal annimmt. Die Aktion wird mit einem Timestamp im Verlauf des Geschäftsprozesses für die Bewerbung erfasst. Erfassung Erfasst anhand des Abschluss-Timestamps der Aufgabe „Accept Offer“. Ereignistyp explicit
	Angebot unterbreitet	Kennzeichnet die formelle Unterbreitung eines Stellenangebots. Dieses einzelne Ereignis wird erfasst, sobald der Geschäftsprozess „Create Offer“ oder „Propose Compensation“ für die Bewerbung in Workday erfolgreich abgeschlossen wurde.
Warum das wichtig ist Dieser wichtige Meilenstein dient zur Berechnung der Time-to-Offer und zur Analyse der Konformität des Angebotsprozesses. Ab hier wird die Annahmequote der Angebote gemessen. Woher beziehen Dieses Ereignis wird ausdrücklich im Verlauf des Geschäftsprozesses für die Bewerbung protokolliert. Der Abschluss-Timestamp des Schritts zur Angebotserstellung gibt den Zeitpunkt der Aktivität an. Erfassung Erfasst anhand des Abschluss-Timestamps des Geschäftsprozesses „Create Offer“. Ereignistyp explicit
	Bewerbende Person abgelehnt	Kennzeichnet das erfolglose Ende des Prozesses, wenn das Unternehmen beschließt, die Bewerbung nicht weiterzuverfolgen. Abgeleitet wird dies, wenn eine Recruiterin oder ein Recruiter den Status der bewerbenden Person auf „Rejected“ oder „Not Hired“ setzt.
Warum das wichtig ist Dieses wichtige End-Event hilft, Stellen mit besonders vielen Bewerbungsabbrüchen und Ablehnungsquoten in den einzelnen Phasen zu analysieren. So lassen sich Probleme im Interview- oder Vorauswahlprozess erkennen. Woher beziehen Abgeleitet aus dem Timestamp, zu dem der Status der bewerbenden Person im Bewerbungsverlauf auf „Rejected“ gesetzt wird. Häufig wird auch ein Ablehnungsgrund erfasst. Erfassung Abgeleitet aus dem Gültigkeits-Timestamp des Wechsels zum Status „Rejected“. Ereignistyp inferred
	Bewerbende Person eingestellt	Der erfolgreiche Abschluss des Recruiting-Prozesses: Die bewerbende Person wird offiziell als Mitarbeiterin oder Mitarbeiter eingestellt. Erfasst wird dies, wenn der Geschäftsprozess „Hire“ in Workday erfolgreich abgeschlossen und ein Mitarbeiterdatensatz angelegt wurde.
Warum das wichtig ist Dies ist das zentrale erfolgreiche End-Event. Der Timestamp ist unerlässlich, um die Time-to-Hire sowie die Effizienz und Erfolgsquote des gesamten Prozesses zu berechnen. Woher beziehen Der Geschäftsprozess „Hire“ in Workday HCM protokolliert dieses wichtige Ereignis ausdrücklich. Der Abschluss-Timestamp wird im Prozessverlauf erfasst. Erfassung Erfasst anhand des Abschluss-Timestamps des Geschäftsprozesses „Hire“ für die bewerbende Person. Ereignistyp explicit
	Bewerbende Person in Angebotsphase verschoben	Ein wichtiger Meilenstein, der anzeigt, dass die Entscheidung für ein Stellenangebot gefallen ist. Er wird erfasst, wenn die Bewerbung im Recruiting-Prozess in die Phase „Offer“ verschoben wird.
Warum das wichtig ist Diese Aktivität ist ein entscheidender Kontrollpunkt im Prozess und markiert den erfolgreichen Abschluss aller Beurteilungsphasen. Sie geht dem formellen Angebot voraus und ist ein wichtiger Ansatzpunkt für Kohortenanalysen. Woher beziehen Abgeleitet aus dem Audit-Trail der Bewerbung, insbesondere aus dem Timestamp der Statusänderung zu „Offer“. Erfassung Erkennbar an der Statusänderung zur Phase „Offer“ im Bewerbungsverlauf. Ereignistyp inferred
	Bewerbende Person zum Interview eingeladen	Zeigt an, dass die bewerbende Person die erste Vorauswahl bestanden hat und zu einem Interview eingeladen werden kann. Das Ereignis wird erfasst, wenn eine Recruiterin oder ein Recruiter die Person im Einstellungsprozess in die Phase „Interview“ verschiebt.
Warum das wichtig ist Dieser Meilenstein markiert den Übergang von der Vorauswahl zur aktiven Beurteilung. Er ist ein wichtiger Ansatzpunkt, um Konversionsraten und die Effizienz am Anfang des Recruiting-Prozesses zu analysieren. Woher beziehen Abgeleitet aus dem Timestamp, zu dem die Recruiting-Phase der bewerbenden Person im Verlauf der Bewerbung auf „Interview“ oder eine ähnliche Bezeichnung gesetzt wird. Erfassung Erkennbar an der Statusänderung zur Phase „Interview“ im Bewerbungsverlauf. Ereignistyp inferred
	Bewerbung eingegangen	Kennzeichnet den Beginn des Recruiting-Prozesses für die Bewerbung einer Person. Dieses Ereignis wird erfasst, sobald die Person ihre Bewerbung für eine bestimmte Stellenausschreibung über das Workday-Portal oder eine angebundene Karriereseite erfolgreich eingereicht hat.
Warum das wichtig ist Dies ist das zentrale Start-Event des Prozesses. Die Zeitspanne von dieser Aktivität bis zu den folgenden Meilensteinen ist eine wichtige Grundlage, um die Time-to-Hire insgesamt und die Wirksamkeit der Recruiting-Kanäle zu messen. Woher beziehen Workday protokolliert dieses Ereignis ausdrücklich, sobald der Geschäftsprozess „Apply for Job“ für eine Person erfolgreich abgeschlossen wurde. Der Timestamp des Ereignisses ist im Bewerbungsverlauf verfügbar. Erfassung Erfasst anhand des Timestamps der Bewerbungseinreichung im Profil der bewerbenden Person. Ereignistyp explicit
	Background Check bestanden	Kennzeichnet den erfolgreichen Abschluss des Background Checks. Das Ereignis wird abgeleitet, wenn der Status der bewerbenden Person anzeigt, dass die erforderlichen Prüfungen bestanden wurden und einer Einstellung nichts mehr im Wege steht.
Warum das wichtig ist Dies ist der letzte Kontrollpunkt vor dem Abschluss des Einstellungsprozesses. Verzögerungen beim Eingang und bei der Erfassung der Freigabe können den Arbeitsbeginn der bewerbenden Person hinauszögern. Woher beziehen Abgeleitet aus einer Statusänderung in der Bewerbung, etwa dem Wechsel in die Phase „Ready for Hire“ oder „Background Check Complete“. Erfassung Abgeleitet aus der Statusänderung, die den erfolgreichen Abschluss des Background Checks anzeigt. Ereignistyp inferred
	Background Check eingeleitet	Zeigt den Beginn des Background Checks für eine Person an, die ein Angebot angenommen hat. In der Regel lässt sich dies daran erkennen, dass die Person in die Phase „Background Check“ wechselt. Häufig wird dadurch eine Integration mit einem Drittanbieter ausgelöst.
Warum das wichtig ist Diese Aktivität ist wichtig, um die Compliance zu überwachen und Verzögerungen zwischen der Angebotsannahme und dem Beginn der Prüfungen vor der Einstellung zu analysieren. So lässt sich der Übergang zum Onboarding reibungsloser gestalten. Woher beziehen Abgeleitet aus dem Timestamp, zu dem die Person im Recruiting-Prozess in die Phase „Background Check“ wechselt. Der Audit-Trail der Bewerbung zeigt diese Statusänderung. Erfassung Abgeleitet aus dem Gültigkeits-Timestamp des Wechsels in die Phase „Background Check“. Ereignistyp inferred
	Bewerbung vorausgewählt	Bezeichnet den Abschluss der ersten Prüfung einer Bewerbung durch eine Recruiterin, einen Recruiter oder ein Vorauswahlteam. In der Regel lässt sich dies daran erkennen, dass der Status von „Applied“ oder „New“ zu „Screening“ oder „Under Review“ wechselt.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Analyse der Effizienz der ersten Vorauswahl. Durch die Erfassung von Durchsatz und Dauer lassen sich Engpässe früh im Recruiting-Prozess erkennen. Woher beziehen Abgeleitet aus dem Gültigkeitsdatum der Statusänderung zu einem Schritt für Vorauswahl oder Prüfung im Audit-Trail des Geschäftsprozesses „Recruiting“. Erfassung Abgeleitet aus dem Timestamp, zu dem die Phase der bewerbenden Person auf „Screen“ gesetzt wird. Ereignistyp inferred
	Bewerbung zurückgezogen	Ein End-Event, bei dem die bewerbende Person ihre Bewerbung freiwillig zurückzieht. Erfasst wird dies, wenn die Person selbst oder eine Recruiterin beziehungsweise ein Recruiter den Status auf „Withdrawn“ setzt.
Warum das wichtig ist Wann und warum Bewerbende ihre Bewerbung zurückziehen, ist wichtig, um Probleme mit der Candidate Experience, der Prozessdauer oder der Attraktivität von Angeboten zu verstehen. Diese Kennzahl ist zentral für die Analyse von Bewerbungsabbrüchen. Woher beziehen Abgeleitet aus dem Timestamp, zu dem der Status der bewerbenden Person auf „Withdrawn“ gesetzt wird. Dies kann die Person selbst im Portal oder eine Recruiterin beziehungsweise ein Recruiter tun. Erfassung Abgeleitet aus dem Gültigkeits-Timestamp des Wechsels zum Status „Withdrawn“. Ereignistyp inferred
	Feedback übermittelt	Bezeichnet den Zeitpunkt, zu dem eine interviewende Person ihre Bewertung der bewerbenden Person nach dem Interview offiziell übermittelt. Workday bietet dafür eine eigene Funktion, mit der das Feedback direkt im Profil der bewerbenden Person eingetragen werden kann.
Warum das wichtig ist Diese Aktivität ist für die Analyse der fristgerechten Rückmeldung durch einstellende Führungskräfte unerlässlich. Verzögerungen sind hier ein häufiger Engpass. Die Erfassung hilft, Service-Level-Vereinbarungen einzuhalten. Woher beziehen Dieses Ereignis wird ausdrücklich erfasst, wenn das Feedback über die Aufgabe „Provide Interview Feedback“ übermittelt wird. Der Timestamp der Übermittlung wird im Interviewdatensatz protokolliert. Erfassung Abgeleitet aus dem Abschluss-Timestamp des Ereignisses „Provide Interview Feedback“. Ereignistyp explicit
	Interview abgeschlossen	Kennzeichnet den Abschluss eines geplanten Interviews mit einer bewerbenden Person. In der Regel lässt sich dies daran erkennen, dass eine interviewende Person oder eine Recruiterin beziehungsweise ein Recruiter den Interviewstatus von „Scheduled“ auf „Completed“ oder „Conducted“ setzt.
Warum das wichtig ist Diese Aktivität markiert den Beginn des Zeitfensters für die Feedbackabgabe. Die Zeitspanne bis zur Übermittlung des Feedbacks ist ein wichtiger Indikator für die Reaktionszeit der einstellenden Führungskräfte. Woher beziehen Abgeleitet aus einer Statusänderung des geplanten Interviewtermins oder einer manuellen Änderung der Phase der bewerbenden Person in Workday Recruiting nach dem Interview. Erfassung Abgeleitet aus dem Timestamp der Statusänderung des Interviews oder der Phasenänderung nach dem Interview. Ereignistyp inferred
	Interview geplant	Bezeichnet die verbindliche Planung eines Interviews mit der bewerbenden Person. Erfasst wird dies in der Regel, wenn ein Interviewtermin für die jeweilige Bewerbung in der Planungsfunktion von Workday angelegt und bestätigt wird.
Warum das wichtig ist Die Zeitspanne zwischen dieser und den vorherigen Aktivitäten zeigt Verzögerungen bei der Koordination. Ihre Analyse ist wichtig, um die Erfahrung der Bewerbenden zu verbessern und den Interviewprozess zu beschleunigen. Woher beziehen Die Interviewplanungsfunktion von Workday erstellt Ereignisse mit Timestamps. Diese Aktivität lässt sich anhand des Erstellungsdatums des geplanten Interviews erfassen, das mit der Bewerbung verknüpft ist. Erfassung Erfasst anhand des Ereignisses zur Erstellung eines Interviewdatensatzes im Recruiting-Modul. Ereignistyp explicit
	Onboarding eingeleitet	Bezeichnet den Beginn des Onboarding-Prozesses für neue Mitarbeitende in Workday. In der Regel wird dieses Ereignis ausdrücklich als Teil des zentralen Geschäftsprozesses „Hire“ erfasst oder unmittelbar danach ausgelöst.
Warum das wichtig ist Die Zeitspanne von „Offer Accepted“ bis zu dieser Aktivität zeigt, wie sich die Erfahrung nach der Angebotsannahme verbessern lässt. So bleiben neue Mitarbeitende eingebunden und sind auf ihren ersten Arbeitstag vorbereitet. Woher beziehen Der Geschäftsprozess „Onboarding“ in Workday hat einen eindeutigen Start-Timestamp. Dieser lässt sich aus dem Audit-Trail des Datensatzes der neuen Mitarbeiterin oder des neuen Mitarbeiters auslesen. Erfassung Erfasst anhand des Start-Timestamps des Geschäftsprozesses „Onboarding“. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Workday Recruiting

Schritte

Bei Workday anmelden: Melden Sie sich mit einem Benutzerkonto bei Ihrem Workday-Mandanten an, das über Berechtigungen zum Erstellen benutzerdefinierter Berichte und zum Zugriff auf Recruiting-Daten verfügt.
Benutzerdefinierten Bericht erstellen: Öffnen Sie die Aufgabe „Create Custom Report“. Wählen Sie als Berichtstyp „Advanced“ und aktivieren Sie die Option „Enable as Web Service“. Verwenden Sie als Datenquelle für eine bessere Leistung eine indizierte Quelle wie „All Job Applications“.
Primäres Geschäftsobjekt festlegen: Legen Sie „Job Application“ als primäres Geschäftsobjekt fest. Dieses Objekt bildet die Grundlage des Berichts und dient als Case-ID.
Datenspalten hinzufügen: Fügen Sie die erforderlichen und empfohlenen Felder zum Spaltenraster des Berichts hinzu. Nehmen Sie „Job Application“ für JobApplicationId auf. Weitere Attribute wie „Recruiter“ und „Hiring Manager“ müssen Sie aus den zugehörigen Geschäftsobjekten hinzufügen, die mit der Bewerbung verknüpft sind.
Berechnete Felder für Aktivitäten erstellen: Dies ist der wichtigste Schritt. Erstellen Sie für jede der 15 Aktivitäten zwei berechnete Felder: eines für den Aktivitätsnamen und eines für den Ereignis-Timestamp. Die Logik für diese Felder wird im Abschnitt „Abfrage“ beschrieben. Um beispielsweise „Offer Extended“ zu erfassen, erstellen Sie ein Feld, das prüft, ob der Geschäftsprozess „Propose Compensation“ abgeschlossen wurde, und ein weiteres Feld, das den Abschluss-Timestamp dieses Prozesses ausliest.
Berechnete Felder zum Bericht hinzufügen: Fügen Sie alle neu erstellten berechneten Felder als Spalten in den Bericht ein. Insgesamt sind es 30 Felder: 15 für Aktivitätsnamen und 15 für Timestamps. Der Bericht liegt im „breiten“ Format vor: eine Zeile pro Bewerbung und zahlreiche Spalten für mögliche Aktivitäten.
Web-Service-Optionen konfigurieren: Vergewissern Sie sich auf der Registerkarte „Web Service“ der Berichtsdefinition, dass das Kontrollkästchen „Enable as Web Service“ aktiviert ist. Hier können Sie den Namespace und die URL des Berichts einsehen. Notieren Sie sich den Namespace für die spätere Verwendung.
Berechtigungen festlegen: Geben Sie den Bericht für einen Integration System User (ISU) oder eine bestimmte Sicherheitsgruppe frei, über die der RaaS-Endpunkt aufgerufen wird. Dieser Benutzer benötigt Berechtigungen für die Domäne der Datenquelle, zum Beispiel „Recruiting: Job Applications“.
Bericht ausführen und testen: Führen Sie den Bericht in der Workday-Oberfläche aus, um die Ausgabe zu prüfen. Kontrollieren Sie, ob die Zeilenanzahl plausibel ist und die berechneten Felder für einige Beispielbewerbungen korrekt gefüllt werden.
Datenextraktion planen: Rufen Sie die RaaS-URL des Berichts regelmäßig über ein externes Planungstool oder eine Middleware wie MuleSoft, Boomi oder ein eigenes Skript auf. Das Tool muss den Workday-SOAP- oder REST-API-Aufruf mit geeigneter Authentifizierung ausführen.
Daten transformieren: Die Rohdaten aus dem RaaS-Aufruf liegen als breite XML- oder CSV-Datei vor. Transformieren Sie sie mit Ihrer Middleware oder einer Skriptsprache wie Python in ein langes Format. Das Skript sollte jede Zeile, also jede Bewerbung, durchlaufen und für jedes nicht leere Aktivitäts-/Timestamp-Paar eine neue Zeile im endgültigen Event Log erstellen. Das Ergebnis enthält drei Hauptspalten: JobApplicationId, ActivityName und EventTime.

Konfiguration

Berichtstyp: Verwenden Sie immer „Advanced“, damit komplexe berechnete Felder und zugehörige Geschäftsobjekte verfügbar sind.
Datenquelle: Verwenden Sie eine indizierte Datenquelle wie „All Job Applications“, damit der Bericht effizient ausgeführt wird. Vermeiden Sie nicht indizierte Quellen bei großen Datenmengen.
Datumsbereich filtern: Filtern Sie unbedingt nach dem Feld „Application Date“ des Geschäftsobjekts „Job Application“. Beginnen Sie mit einem kleineren Zeitraum, beispielsweise den letzten drei bis sechs Monaten, um Datenvolumen und Berichtslaufzeit zu begrenzen.
Primäres Geschäftsobjekt: Als primäres Objekt muss „Job Application“ festgelegt sein, damit JobApplicationId als Case-ID dient.
Web-Service aktivieren: Aktivieren Sie in der Berichtskonfiguration die Option „Enable as Web Service“, damit der Bericht über APIs erreichbar ist.
Sicherheit und Berechtigungen: Geben Sie den Bericht für einen dedizierten Integration System User (ISU) frei. Dieser ISU benötigt Berechtigungen über Sicherheitsgruppen für die erforderlichen Datendomänen, darunter „Recruiting: Job Applications“, „Business Process Transactions“ und „Worker Data“.
Ausgabeformat: Workday bietet verschiedene Ausgabeformate wie XML, CSV und JSON. XML, insbesondere das Format „Simple XML“, ist für die strukturierte Datenextraktion über die API häufig am zuverlässigsten.

a Beispielabfrage sql

The Workday Report Writer is configured through the user interface. The following describes the structure and calculated fields required to build the report. The final output will be a wide table that must be transformed into an event log.

**Primary Business Object:**
*   `Job Application`

**Direct Report Fields (Columns):**
| Field Name in Report | Workday Business Object | Workday Field | Notes |
| --- | --- | --- | --- |
| `JobApplicationId` | Job Application | Job Application | Serves as the Case ID. |
| `RecruiterName` | Job Application -> Recruiter | Worker | Use a Lookup Related Value field. |
| `HiringManager` | Job Application -> Job Requisition -> Hiring Manager | Worker | Use a Lookup Related Value field. |
| `ApplicationSource` | Job Application | Source | |
| `Department` | Job Application -> Job Requisition -> Organization | Supervisory Organization | |
| `ApplicationStatus` | Job Application | Status | Represents the final or current status. |

**Calculated Fields for Event Log Unpivoting:**
Create two calculated fields for each activity: one for the name (Type: Evaluate Expression) and one for the timestamp (Type: Extract Single Instance or Lookup Related Value).

1.  **Application Received**
    *   `ActivityName_AppReceived`: `"Application Received"` (This event uses the application date, so the name is constant).
    *   `EventTime_AppReceived`: Field `Application Date` from the Job Application object.
2.  **Application Screened**
    *   `ActivityName_AppScreened`: `IIF(Stage = [Your 'Screening' Stage], "Application Screened", "")`
    *   `EventTime_AppScreened`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the 'Business Process History for Worker' for the 'Move to Stage: [Screening]' event.
3.  **Candidate Moved To Interview**
    *   `ActivityName_MovedToInterview`: `IIF(Stage = [Your 'Interview' Stage], "Candidate Moved To Interview", "")`
    *   `EventTime_MovedToInterview`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Move to Stage: [Interview]' event.
4.  **Interview Scheduled**
    *   `ActivityName_InterviewScheduled`: `IIF(Interview Status = 'Scheduled', "Interview Scheduled", "")`
    *   `EventTime_InterviewScheduled`: Use a 'Lookup Related Value' field to get the 'Scheduled Start Moment' from the 'Candidate Interview Details' object.
5.  **Interview Completed**
    *   `ActivityName_InterviewCompleted`: `IIF(Interview Status = 'Completed', "Interview Completed", "")`
    *   `EventTime_InterviewCompleted`: Use a 'Lookup Related Value' field to get the 'Actual End Moment' from the 'Candidate Interview Details' object.
6.  **Feedback Submitted**
    *   `ActivityName_FeedbackSubmitted`: `IIF(Interview Feedback Status = 'Submitted', "Feedback Submitted", "")`
    *   `EventTime_FeedbackSubmitted`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Submit Interview Feedback' event.
7.  **Candidate Moved To Offer Stage**
    *   `ActivityName_MovedToOffer`: `IIF(Stage = [Your 'Offer' Stage], "Candidate Moved To Offer Stage", "")`
    *   `EventTime_MovedToOffer`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Move to Stage: [Offer]' event.
8.  **Offer Extended**
    *   `ActivityName_OfferExtended`: `IIF(Is Business Process 'Propose Compensation' Completed = true, "Offer Extended", "")`
    *   `EventTime_OfferExtended`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Propose Compensation' or 'Make Offer' business process.
9.  **Offer Accepted**
    *   `ActivityName_OfferAccepted`: `IIF(Disposition = 'Offer Accepted', "Offer Accepted", "")`
    *   `EventTime_OfferAccepted`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Accept Offer' event.
10. **Background Check Initiated**
    *   `ActivityName_BGCheckInitiated`: `IIF(Stage = [Your 'Background Check' Stage], "Background Check Initiated", "")`
    *   `EventTime_BGCheckInitiated`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Move to Stage: [Background Check]' event.
11. **Background Check Cleared**
    *   `ActivityName_BGCheckCleared`: `IIF(Background Check Status = 'Passed', "Background Check Cleared", "")`
    *   `EventTime_BGCheckCleared`: Use a 'Lookup Related Value' field on the Background Check business object to get the completion date.
12. **Onboarding Initiated**
    *   `ActivityName_OnboardingInitiated`: `IIF(Is Business Process 'Onboarding' Initiated = true, "Onboarding Initiated", "")`
    *   `EventTime_OnboardingInitiated`: Use an 'Extract Single Instance' field to get the 'Entry Moment' from the business process history for the 'Onboarding' business process.
13. **Candidate Hired**
    *   `ActivityName_Hired`: `IIF(Is Hired = true, "Candidate Hired", "")`
    *   `EventTime_Hired`: Use an 'Extract Single Instance' field to get the 'Completed Moment' from the business process history for the 'Hire' business process.
14. **Candidate Rejected**
    *   `ActivityName_Rejected`: `IIF(Is Inactive = true AND Disposition = [Your 'Rejected' Reason], "Candidate Rejected", "")`
    *   `EventTime_Rejected`: Use a 'Lookup Related Value' field to get the 'Inactive Date' from the Job Application object.
15. **Application Withdrawn**
    *   `ActivityName_Withdrawn`: `IIF(Disposition = 'Withdrawn', "Application Withdrawn", "")`
    *   `EventTime_Withdrawn`: Use a 'Lookup Related Value' field to get the 'Inactive Date' from the Job Application object, filtering on the inactive reason.

Schritte

Workday-Zugriff konfigurieren: Erstellen Sie in Workday einen Integration System User (ISU). Gewähren Sie diesem Benutzer Zugriff auf die erforderlichen Sicherheitsdomänen der Recruiting API. Zu den wichtigsten Domänen gehören „Worker Data: Public Worker Reports“, „Job Application“ und „Recruiting: Reports“.
API-Endpunkt ermitteln: Suchen Sie in Ihrem Workday-Mandanten den REST-API-Endpunkt für den Vorgang „Get Job Applications“. Die URL hat üblicherweise folgendes Format: https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications.
Python-Umgebung einrichten: Stellen Sie sicher, dass Python installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
Authentifizierungsskript entwickeln: Implementieren Sie in Ihrem Python-Skript die Basisauthentifizierung mit den Zugangsdaten des in Schritt 1 erstellten ISU. Benutzername und Passwort werden im Request-Header übermittelt.
Logik für API-Aufrufe implementieren: Schreiben Sie eine Funktion, die den Endpunkt „Get Job Applications“ aufruft. Verwenden Sie Request-Parameter, um die Daten zu filtern, etwa updatedSince, damit nur Bewerbungen ab einem bestimmten Datum abgerufen werden. Das ist wichtig, um das Datenvolumen zu begrenzen.
API-Paginierung verarbeiten: Die Workday API gibt pro Anfrage nur eine begrenzte Anzahl an Datensätzen zurück. Ihr Skript muss die Antwort auf einen total-Wert und einen Link zur nächsten Seite oder einen Offset-Parameter prüfen und alle Seiten nacheinander abrufen, bis der vollständige Datensatz vorliegt.
Aktivitäten zuordnen: Erstellen Sie ein Zuordnungswörterbuch oder eine Reihe bedingter Anweisungen in Ihrem Skript. Damit werden Workday-Geschäftsprozessstatus und Recruiting-Phasen, etwa „Screen“, „Interview“, „Offer“ und „Hire“, den erforderlichen Aktivitätsnamen wie „Application Screened“ und „Candidate Moved To Interview“ zugeordnet.
Bewerbungsdaten transformieren: Verarbeiten Sie für jede über die API abgerufene Bewerbung den Audit-Trail oder den Verlauf der Phasen. Dieser Verlauf enthält die Abfolge der Phasen, Entscheidungen und Geschäftsprozessereignisse mit den zugehörigen Timestamps.
Zeilen für das Event Log erstellen: Durchlaufen Sie den Verlauf jeder Bewerbung. Erstellen Sie für jedes relevante historische Ereignis, das einer Zuordnung entspricht, ein Dictionary als Zeile für das endgültige Event Log. Füllen Sie JobApplicationId, ActivityName, EventTime und weitere erforderliche Attribute aus.
Daten zusammenführen und strukturieren: Fassen Sie alle erstellten Event-Log-Zeilen aus sämtlichen Bewerbungen in einer Liste zusammen.
CSV-Datei erstellen und exportieren: Wandeln Sie die Liste der Ereignis-Dictionaries mit der pandas-Bibliothek in einen DataFrame um. Exportieren Sie diesen anschließend als CSV-Datei. Achten Sie darauf, dass die Spaltenüberschriften den Anforderungen von ProcessMind entsprechen, zum Beispiel CaseId, Aktivität und Timestamp.
Prüfen und hochladen: Öffnen Sie die fertige CSV-Datei und prüfen Sie Inhalt, Richtigkeit und Vollständigkeit, bevor Sie sie in das Process-Mining-Tool hochladen.

Konfiguration

Workday Integration System User (ISU): Erforderlich ist ein ISU mit einem sicheren, nicht ablaufenden Passwort. Für den Zugriff auf Bewerbungs- und Kandidatendaten benötigt er Berechtigungen für die Sicherheitsdomänen „Recruiting“ und „Worker Data“.
API-Endpunkt und Version: Verwenden Sie den korrekten REST-API-Endpunkt für Ihren Workday-Mandanten. Geben Sie die API-Version in der Anfrage an, damit das Verhalten konsistent bleibt.
Datumsbereich filtern: Begrenzen Sie die Abfrage im Skript mit einem Datumsfilter wie updatedSince auf einen überschaubaren Zeitraum. Für die erste Extraktion empfehlen sich drei bis sechs Monate. Bei nachfolgenden Delta-Ladevorgängen verwenden Sie den Timestamp der letzten erfolgreichen Extraktion.
Seitengröße: Beachten Sie den API-Parameter limit, der die Anzahl der Datensätze pro Seite festlegt. Ein typischer Höchstwert ist 100. Das Skript muss mehrere Anfragen für die einzelnen Seiten ausführen können.
Antwortfelder: Wenn die API dies unterstützt, können Sie mit einem Parameter wie fields festlegen, welche Felder zurückgegeben werden. Dadurch verringert sich die Größe der API-Antwort.
Konfiguration der Aktivitätszuordnung: Die zentrale Logik des Skripts ordnet Workday-Phasen den definierten Aktivitäten zu. Passen Sie diese Zuordnung gegebenenfalls an die Recruiting-Konfiguration Ihres Unternehmens an.

a Beispielabfrage 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.")

Schritte

Voraussetzungen und Einrichtung: Stellen Sie sicher, dass Sie über ein lizenziertes ETL- oder iPaaS-Tool eines Drittanbieters verfügen, zum Beispiel CData, MuleSoft oder eine vergleichbare Plattform, und dass der Workday-Konnektor installiert ist. Vergewissern Sie sich, dass Sie die Anmeldedaten eines Workday Integration System User (ISU) mit den erforderlichen API-Berechtigungen für die Recruiting- und Staffing-Domänen haben.
Workday-Verbindung konfigurieren: Richten Sie in Ihrem ETL-Tool eine neue Verbindung zu Workday ein. Geben Sie die URL Ihres Workday-Mandanten, die API-Version und die ISU-Anmeldedaten an, zum Beispiel Benutzername und Passwort oder OAuth-2.0-Token. Testen Sie die Verbindung.
Datenschema untersuchen: Zeigen Sie mit dem Schema-Browser oder Datenquellen-Explorer Ihres ETL-Tools die über den Konnektor verfügbaren Workday-Objekte an. Diese werden in der Regel als Tabellen oder Ansichten dargestellt, zum Beispiel Job_Application, Job_Requisition und Candidate_Stage_History. Machen Sie sich mit den verfügbaren Feldern und Beziehungen vertraut.
Wichtige Datenobjekte ermitteln: Für diesen Export benötigen Sie vor allem Daten zu Stellenbewerbungen, Bewerbungsverläufen, Vorstellungsgesprächen, Angeboten und Einstellungen. Die genauen Namen hängen von Ihrem Konnektor ab. Suchen Sie nach Objekten, die diese zentralen Entitäten abbilden.
SQL-Abfrage erstellen: Erstellen Sie einen neuen Datenexportauftrag oder eine Pipeline. Fügen Sie einen SQL-Umwandlungsschritt hinzu, der eine Abfrage für die Workday-Verbindung ausführt. Kopieren Sie die bereitgestellte SQL-Abfrage in diesen Schritt. Sie ruft Daten aus mehreren Workday-Objekten ab und führt sie in einem Event-Log-Format zusammen.
Abfrage parametrisieren: Ergänzen Sie die WHERE-Klausel der Abfrage um Parameter für den Zeitraum, zum Beispiel startDate und endDate. Richten Sie diese Parameter im ETL-Auftrag ein, damit Sie den Exportzeitraum ändern können, ohne den Code anzupassen.
Exportauftrag ausführen: Führen Sie den konfigurierten ETL-Auftrag aus. Das Tool stellt eine Verbindung zu Workday her, führt die SQL-Abfrage über die API aus und ruft die Daten in einen Staging-Bereich oder in den Arbeitsspeicher ab.
Daten prüfen und validieren: Prüfen Sie die Ergebnisse vor dem Schreiben der endgültigen Ausgabe mit der Vorschaufunktion Ihres ETL-Tools. Kontrollieren Sie, ob die Zeilenanzahl plausibel ist, alle Spalten erwartungsgemäß befüllt sind und verschiedene Aktivitäten enthalten sind.
Ziel konfigurieren: Legen Sie das Ziel für die exportierten Daten fest. In der Regel handelt es sich um eine CSV-Datei für den Upload in ProcessMind. Konfigurieren Sie Dateinamen, Trennzeichen (Komma) und Kodierung (UTF-8).
Abschließen und exportieren: Führen Sie den vollständigen Exportauftrag aus, um die endgültige CSV-Datei zu erstellen. Achten Sie darauf, dass die Spaltenüberschriften den erforderlichen Attributen entsprechen: JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Abteilung und ApplicationStatus.

Konfiguration

Zugangsdaten für den Workday-Konnektor: Für die Verbindung benötigen Sie die URL Ihres Workday-Mandanten und einen autorisierten Integration System User (ISU) mit Passwort oder OAuth-2.0-Client-Zugangsdaten. Der Benutzer muss über Sicherheitsberechtigungen für die Funktionsbereiche „Recruiting“ und „Staffing“ verfügen.
Web-Service-Aktivierung: Möglicherweise müssen Sie im Konnektor festlegen, welche Workday-Webservices verfügbar sein sollen. Aktivieren Sie die Dienste für Recruiting, Staffing und Human Resources, damit alle erforderlichen Datenobjekte zugänglich sind.
Datumsbereich: Begrenzen Sie die Extraktion unbedingt auf einen bestimmten Zeitraum, um Leistung und Datenvolumen zu steuern. Für den ersten Ladevorgang empfehlen wir Daten aus drei bis sechs Monaten. Laden Sie anschließend täglich oder wöchentlich neue Daten inkrementell. Den Zeitraum steuern Sie über die WHERE-Klausel der SQL-Abfrage.
Filter für den Datenumfang: Wenn Sie nur bestimmte Teile der Organisation analysieren möchten, ergänzen Sie die WHERE-Klausel um Filter für Felder wie Company, Cost Center oder Supervisory Organization.
API-Version: Bei einigen Konnektoren müssen Sie die Workday-API-Version angeben. Verwenden Sie möglichst eine aktuelle, unterstützte Version, damit die neuesten Datenobjekte und Funktionen verfügbar sind.
Leistungsaspekte: Vollständige Datenextraktionen aus Workday können viele Ressourcen beanspruchen. Planen Sie umfangreiche Aufträge außerhalb der Hauptnutzungszeiten. Richten Sie für laufende Analysen eine inkrementelle Ladestrategie anhand eines Timestamps für die letzte Änderung ein, damit nur neue oder aktualisierte Datensätze abgerufen werden.

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

Möchten Sie loslegen?

Mit diesem Template verwandeln Sie Ihre Daten zur Talentgewinnung in konkrete Erkenntnisse und verbessern die Effizienz Ihres Einstellungsprozesses. Beginnen Sie noch heute damit, Ihr Recruiting effizienter und wirksamer zu gestalten.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Engpässe im Recruiting beseitigen: Optimieren Sie noch heute Ihre Personalgewinnung

Erkennen Sie Ineffizienzen, verkürzen Sie die Einstellungsdauer um 30 % und erreichen Sie Ihre Personalziele schneller.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. 14 Tage kostenlos testen.

Ihr Daten-Template für Recruiting und Talentgewinnung

Ihr Daten-Template für Recruiting und Talentgewinnung

Attribute für Recruiting und Talentgewinnung

Aktivitäten im Recruiting und in der Talentgewinnung

Anleitungen zur Datenextraktion

Datenextraktion aus Workday Report-as-a-Service (RaaS)

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion aus der Workday-Recruiting-API mit einem Python-Skript

Schritte

Konfiguration

a Beispielabfrage python

Datenextraktion mit einem ETL-Tool und Workday-Konnektor

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Engpässe im Recruiting beseitigen: Optimieren Sie noch heute Ihre Personalgewinnung

Ihr Daten-Template für Recruiting und Talentgewinnung

Ihr Daten-Template für Recruiting und Talentgewinnung

Attribute für Recruiting und Talentgewinnung

Aktivitäten im Recruiting und in der Talentgewinnung

Anleitungen zur Datenextraktion

Datenextraktion aus Workday Report-as-a-Service (RaaS)

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion aus der Workday-Recruiting-API mit einem Python-Skript

Schritte

Konfiguration

a Beispielabfrage python

Datenextraktion mit einem ETL-Tool und Workday-Konnektor

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Engpässe im Recruiting beseitigen: Optimieren Sie noch heute Ihre Personalgewinnung

Der Schutz Ihrer Daten ist uns wichtig