> Kontinuierliche Prozessoptimierung > Rekrutierung & Talent Acquisition > Workday Recruiting > Datenvorlage

Ihre Datenvorlage für Rekrutierung & Talentakquisition

Workday Recruiting

Rekrutierungs- & Talent Acquisition-Attribute (20) Rekrutierungs- & Talent Acquisition-Aktivitäten (15) Extraktionsleitfäden (3)

Ihre Datenvorlage für Rekrutierung & Talentakquisition

Diese Vorlage bietet einen umfassenden Leitfaden zur Erfassung der notwendigen Daten für die Analyse Ihrer Rekrutierungs- und Talent Acquisition-Prozesse. Sie skizziert wesentliche Attribute, die gesammelt werden müssen, wichtige Aktivitäten, die verfolgt werden sollten, und gibt Anleitungen, wie diese Daten aus Ihrem Workday Recruiting-System extrahiert werden können. Nutzen Sie diese Ressource, um Ihre Datenaufbereitung zu optimieren und Ihre Process Mining-Reise zu beschleunigen.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsleitfaden für Workday Recruiting

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Rekrutierungs- & Talent Acquisition-Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihren Event Log für eine umfassende Analyse der Rekrutierung und Talentakquise aufnehmen sollten, um tiefe Einblicke in Ihren Einstellungsprozess zu ermöglichen.

3 Erforderlich 5 Empfohlen 12 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Events oder der Aufgabe, die zu einem bestimmten Zeitpunkt innerhalb des Rekrutierungsprozesses stattfand.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt oder Meilenstein im Einstellungsprozess, wie „Bewerbung gescreent“, „Interview geplant“ oder „Angebot unterbreitet“. Diese Aktivitäten bilden die Abfolge der Events, die den Prozess ausmachen. Dieses Attribut ist entscheidend für die Visualisierung der Prozesslandkarte, die Identifizierung der verschiedenen Wege, die Bewerbungen nehmen, und die Analyse der Häufigkeit und Reihenfolge der Events. Es ist die Grundlage für das Verständnis dessen, was im Prozess geschieht. Bedeutung Dieses Attribut definiert die Schritte des Rekrutierungsprozesses und ermöglicht die Visualisierung und Analyse des Prozessflusses. Datenquelle Dies wird aus den Namen der Geschäftsprozessschritte oder Statusänderungen innerhalb der Stellenbewerbungsdaten von Workday Recruiting abgeleitet. Beispiele Antrag geprüftInterview abgeschlossenAngebot angenommenKandidat abgelehnt
	Ereigniszeit EventTime	Der Timestamp, der angibt, wann die Aktivität oder das Event stattgefunden hat.
Beschreibung Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu der eine spezifische Rekrutierungsaktivität stattfand. Timestamps sind das Rückgrat von Process Mining, da sie die chronologische Reihenfolge der Events liefern. In der Analyse werden Timestamps verwendet, um Dauern zwischen Aktivitäten zu berechnen, die gesamten Zykluszeiten wie die „Time to Hire“ zu messen und Engpässe zu identifizieren, an denen der Prozess verzögert wird. Sie sind essenziell für jede zeitbasierte Analyse des Rekrutierungs-Funnels. Bedeutung Timestamps sind entscheidend für die Berechnung aller zeitbasierten KPIs, das Verständnis der Prozessdauer und die Entdeckung von Engpässen. Datenquelle Dies entspricht dem Abschlussdatum 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 für die Stellenbewerbung eines Kandidaten, die als zentrale Case ID für den Rekrutierungsprozess dient.
Beschreibung Die Job Application ID verfolgt eindeutig die Reise eines einzelnen Kandidaten für eine spezifische Stellenausschreibung von der ersten Einreichung bis zur endgültigen Entscheidung. Jede Interaktion, Statusänderung oder Entscheidungspunkt im Zusammenhang mit dieser Bewerbung ist mit diesem Identifikator verknüpft. Im Process Mining ist dieses Attribut fundamental. Es ermöglicht die Rekonstruktion des End-to-End-Prozessflusses jedes Kandidaten und somit die Analyse von Zykluszeiten, Engpässen und beschrittenen Pfaden. Es ist das Kernelement, das alle verwandten Aktivitäten zu einem kohärenten Case verbindet. Bedeutung Dies ist die essenzielle Case ID, die alle Rekrutierungsaktivitäten für einen einzelnen Kandidaten verbindet und somit die Analyse der gesamten Einstellungsprozessreise ermöglicht. Datenquelle Dieser Identifikator ist ein Kernelement in Workday Recruiting und typischerweise in Berichten und Datenquellen im Zusammenhang mit Stellenbewerbungen verfügbar. Beispiele APP-2023-001234APP-2023-005678APP-2024-009101
	Abteilung Department	Die Abteilung oder Geschäftseinheit, die der Stellenanforderung zugeordnet ist.
Beschreibung Dieses Attribut gibt die Organisationseinheit an, z. B. „Engineering“, „Marketing“ oder „Finance“, für die der Kandidat eingestellt wird. Es wird von der der Stellenausschreibung zugeordneten Führungsorganisation abgeleitet. In der Analyse ermöglicht das Filtern nach Abteilung den Vergleich von Einstellungsprozessen in verschiedenen Geschäftsbereichen. Es wird im Dashboard „Effizienz des Bewerbungs-Screenings“ verwendet, um festzustellen, ob bestimmte Abteilungen längere Screening-Zeiten haben, was potenziell auf unterschiedliche Praktiken oder Ressourcenbedarfe hindeuten könnte. Bedeutung Ermöglicht den Vergleich der Leistung und Effizienz von Rekrutierungsprozessen über verschiedene Geschäftsbereiche oder Abteilungen hinweg. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies leitet sich von der übergeordneten Organisation ab, die mit der Stellenanforderung verknüpft ist. Beispiele EngineeringVertriebPersonalwesenFinanzen
	Antragsstatus ApplicationStatus	Das Endergebnis oder der aktuelle Status der Stellenbewerbung.
Beschreibung Dieses Attribut erfasst den endgültigen Status einer Stellenbewerbung, wie „Eingestellt“, „Vom Unternehmen abgelehnt“, „Angebot abgelehnt“ oder „Vom Kandidaten zurückgezogen“. Es repräsentiert den Endzustand des Prozesses für eine gegebene Bewerbung. Dieser Status ist entscheidend für die Ergebnis-Analyse. Er wird verwendet, um Konversionsraten, Angebotsannahmequoten und Kandidaten-Drop-off-Raten in verschiedenen Phasen zu berechnen. Das Verständnis, warum und wo Bewerbungen enden, ist der Schlüssel zur Verbesserung der gesamten Prozesseffektivität. Bedeutung Definiert das Ergebnis jedes Falles, was entscheidend ist für die Berechnung von Konversionsraten, Abbruchquoten und den Gesamterfolg des Prozesses. Datenquelle Dies ist typischerweise das Feld für den endgültigen Status oder Ablehnungsgrund im Job Application-Objekt in Workday Recruiting. Beispiele EingestelltAbgelehntAngebot abgelehntAntrag zurückgezogen
	Anwendungsquelle ApplicationSource	Der Kanal oder die Quelle, über die die Bewerbung des Kandidaten eingegangen ist.
Beschreibung Dieses Attribut gibt an, wie ein Kandidat die Stelle entdeckt und sich beworben hat, zum Beispiel über die Unternehmenskarriereseite, LinkedIn, eine Mitarbeiterempfehlung oder eine Personalvermittlungsagentur. Das Verständnis der Quelle ist entscheidend für die Optimierung der Rekrutierungsstrategie und des Budgets. Es speist das Dashboard „Effektivität der Sourcing-Kanäle“ und den KPI „Annahmequote nach Quelle“, wodurch ermittelt werden kann, welche Kanäle die meisten und qualitativ besten Kandidaten liefern. Bedeutung Hilft, die Effektivität verschiedener Sourcing-Kanäle zu bewerten, was datengesteuerte Entscheidungen ermöglicht, wo Rekrutierungsressourcen investiert werden sollen. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies ist ein Standardfeld in der Bewerbung. Beispiele LinkedInMitarbeiterempfehlungUnternehmens-KarriereseiteIndeed
	Name des Recruiters RecruiterName	Der Name des Recruiters, der für die Verwaltung der Stellenbewerbung zuständig ist.
Beschreibung Dieses Attribut identifiziert den primären Talent Acquisition Partner oder Recruiter, der der Stellenbewerbung und der Stellenausschreibung zugeordnet ist. Er ist typischerweise dafür verantwortlich, den Kandidaten durch den Prozess zu führen. Die Analyse des Prozesses nach Recruiter ist entscheidend für das Verständnis der Teamleistung und Arbeitslast. Sie hilft beim Aufbau des Dashboards „Recruiter Performance und Durchsatz“ und bei der Berechnung von KPIs wie „Recruiter Time-to-Offer Varianz“, was Vergleiche der Effizienz und die Identifizierung von Best Practices ermöglicht. Bedeutung Ermöglicht die Leistungsanalyse nach Recruiter, um Hochleistungsträger, Schulungsbedarfe und Arbeitslastungleichgewichte zu identifizieren. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies ist typischerweise mit den Objekten Stellenanforderung oder Bewerbung verknüpft. Beispiele John SmithEmily JonesMaria Garcia
	Personalverantwortlicher HiringManager	Der Name des Hiring Managers für die Position, auf die sich der Kandidat beworben hat.
Beschreibung Dieses Attribut identifiziert den Manager des Teams oder der Abteilung mit der offenen Position. Der Hiring Manager ist ein wichtiger Stakeholder im Entscheidungsprozess, insbesondere während der Interview- und Feedback-Phasen. Diese Daten sind essenziell für das Dashboard „Hiring Manager Feedback Timeliness“. Durch die Analyse der Zeit zwischen „Interview abgeschlossen“ und „Feedback eingereicht“ pro Hiring Manager können Organisationen Verzögerungen aufdecken und mit spezifischen Managern zusammenarbeiten, um den Einstellungsprozess zu beschleunigen. Bedeutung Entscheidend für die Analyse des Engagements von einstellenden Führungskräften und die Identifizierung von Verzögerungen bei der Rückmeldungsübermittlung, die sich direkt auf die Candidate Experience auswirken. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies ist typischerweise Teil der übergeordneten Organisation oder der Details zur Stellenanforderung. Beispiele Susan AdamsDavid ChenAngela Rodriguez
	Ablehnungsgrund RejectionReason	Der Grund, der angegeben wird, wenn die Bewerbung eines Kandidaten abgelehnt wird.
Beschreibung Wenn eine Bewerbung in den Status „Abgelehnt“ verschoben wird, liefert dieses Attribut Kontext für die Entscheidung. Gründe könnten sein: „Passt nicht zur Unternehmenskultur“, „Fehlende erforderliche Fähigkeiten“ oder „Position durch einen anderen Kandidaten besetzt“. Die Analyse der Ablehnungsgründe hilft, Muster im Einstellungsprozess zu erkennen. Zum Beispiel könnte eine hohe Anzahl von Ablehnungen wegen „fehlender erforderlicher Fähigkeiten“ in einer späten Phase auf eine schlecht formulierte Stellenbeschreibung hindeuten. Diese Daten sind entscheidend für das Dashboard „Kandidaten-Drop-Off Hotspots“, um das „Warum“ hinter den Abbrüchen zu verstehen. Bedeutung Bietet qualitative Einblicke, warum Kandidaten nicht weiterkommen, und hilft, Stellenbeschreibungen und Screening-Kriterien zu verbessern. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies ist oft ein Unterstatus oder ein Grundcode, der mit dem Ablehnungsschritt verbunden ist. Beispiele Nicht qualifiziertErfahrungs-FehlübereinstimmungBessere Kandidaten identifiziertPosition geschlossen
	Angebotsbetrag OfferAmount	Der dem Kandidaten angebotene Gehaltsbetrag.
Beschreibung Dieses Attribut enthält den Wert des Grundgehalts, das einem Kandidaten im Stellenangebot vorgeschlagen wurde. Es ist ein kritischer Datensatz in den letzten Phasen des Rekrutierungsprozesses. Die Analyse der Angebotsbeträge kann Einblicke in Vergütungstrends und Wettbewerbsfähigkeit geben. In Kombination mit dem Status „Angebot angenommen“ kann es helfen zu bestimmen, ob die Vergütung ein Faktor für die Ablehnung von Angeboten ist. Es ist ein Schlüsselelement für das Dashboard „Angebotsmanagement und Annahmequoten“. Bedeutung Hilft bei der Analyse der Vergütungsstrategie und deren Auswirkungen auf die Angebotsannahmequoten. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies wäre Teil der Geschäftsdaten des 'Angebots'-Prozesses. Beispiele 8500012000065000
	Bearbeitungszeit ProcessingTime	Die Dauer der aktiven Bearbeitung einer Aktivität.
Beschreibung Die Processing Time, auch als aktive Zeit bekannt, misst die Dauer, die eine Ressource für die Bearbeitung einer bestimmten Aufgabe aufwendet. Dies unterscheidet sich von der Zykluszeit, die auch Wartezeiten beinhaltet. Zum Beispiel wäre es die Zeit, die ein Recruiter aktiv für das Screening einer Bewerbung aufwendet. Diese Metrik ist wertvoll für das Verständnis der Ressourceneffizienz und Arbeitslast. Falls verfügbar, hilft sie dabei, genau zu bestimmen, welche Aktivitäten in Bezug auf den tatsächlichen Aufwand – nicht nur die verstrichene Zeit – am zeitaufwendigsten sind. Bedeutung Misst den tatsächlichen Arbeitsaufwand für eine Aktivität und hilft, die aktive Arbeitszeit von der Leerlauf-Wartezeit für eine bessere Ressourcenplanung zu unterscheiden. Datenquelle Dies ist oft nicht direkt verfügbar und muss berechnet oder geschätzt werden. Zum Beispiel könnte es die Zeit zwischen einem „Screening gestartet“ und „Screening abgeschlossen“ Event sein, falls eine solche Granularität existiert. Beispiele 360018007200
	Ist automatisiert IsAutomated	Ein Kennzeichen, das angibt, ob die Aktivität automatisch vom System ausgeführt wurde.
Beschreibung Dieses boolesche Attribut identifiziert, ob ein Schritt von einem Benutzer oder einem automatisierten Systemprozess ausgeführt wurde. Zum Beispiel könnte eine erste Bestätigungs-E-Mail „Bewerbung erhalten“ eine automatisierte Aktivität sein. Das Verständnis, welche Schritte automatisiert sind, ist wichtig, um Möglichkeiten zur Steigerung der Effizienz zu identifizieren. Es hilft bei der Bewertung des Einflusses der Automatisierung auf Zykluszeiten und Ressourcenzuweisung. Bedeutung Unterscheidet zwischen manuellen und systemgesteuerten Aktivitäten, was entscheidend ist, um Automatisierungsmöglichkeiten zu identifizieren und deren Auswirkungen zu messen. Datenquelle Diese Informationen müssen durch Identifizierung von System-Benutzerkonten oder spezifischen Event-Typen abgeleitet werden, die in Workday als automatisiert bekannt sind. Beispiele truefalsch
	Ist zurückgezogen IsWithdrawn	Ein Flag, das anzeigt, ob die Bewerbung vom Kandidaten zurückgezogen wurde.
Beschreibung Dies ist ein berechnetes boolesches Attribut, das „true“ ist, wenn der endgültige Status der Bewerbung „Vom Kandidaten zurückgezogen“ oder ein ähnlicher Zustand ist. Es hilft, Fälle zu isolieren, in denen der Kandidat den Prozess verlassen hat. Dieses Flag vereinfacht die Analyse für das Dashboard „Kandidaten-Drop-Off Hotspots“ und den KPI „Kandidaten-Drop-Off-Rate“. Es ermöglicht eine einfache Filterung und Aggregation, um zu verstehen, in welchen Phasen Kandidaten am ehesten zurücktreten. Bedeutung Hilft, speziell kandidatengesteuerte Abbrüche zu analysieren und liefert Einblicke in die Candidate Experience und Prozessreibungspunkte. Datenquelle Dies wird basierend auf dem Attribut „ApplicationStatus“ während der Datentransformation berechnet. Beispiele truefalsch
	Kandidaten-ID CandidateId	Die eindeutige Kennung für den Kandidaten.
Beschreibung Die Kandidaten-ID identifiziert eine Person im Recruiting-System eindeutig, unabhängig davon, wie viele Stellen sie sich beworben hat. Dies ermöglicht die Verfolgung der Historie eines Kandidaten im Unternehmen über mehrere Bewerbungen hinweg. Dieses Attribut ist nützlich für die Analyse der Candidate Experience über die Zeit. Zum Beispiel kann es helfen zu identifizieren, ob zuvor abgelehnte Kandidaten sich erneut bewerben und wie sich ihre Wege unterscheiden, oder ob ein einzelner Kandidat gleichzeitig für mehrere Rollen in Betracht gezogen wird. Bedeutung Ermöglicht eine kandidatenzentrierte Sicht auf den Prozess, wobei eine Person über mehrere Bewerbungen und über die Zeit hinweg verfolgt wird. Datenquelle Dies ist der primäre Identifikator für das Kandidatenobjekt in Workday Recruiting. Beispiele CAND-98765CAND-11223CAND-54321
	Kandidatentyp CandidateType	Zeigt an, ob es sich um einen internen Mitarbeiter oder externen Bewerber handelt.
Beschreibung Dieses Attribut kategorisiert Kandidaten in Gruppen wie „Intern“ oder „Extern“. Der Einstellungsprozess, die Zeitpläne und Richtlinien können zwischen diesen beiden Typen erheblich variieren. Die separate Analyse des Prozesses für interne und externe Kandidaten ist entscheidend für ein vollständiges Bild. Sie ermöglicht es der Organisation, die Effizienz ihrer internen Mobilitätsprogramme im Vergleich zu externen Einstellungsbemühungen zu messen und sicherzustellen, dass beide Prozesse optimiert sind. Bedeutung Ermöglicht eine separate Analyse interner und externer Einstellungsprozesse, die oft unterschiedliche Schritte, SLAs und Ziele aufweisen. Datenquelle Konsultieren Sie die Workday Recruiting-Dokumentation. Dies ist ein Standardfeld im Kandidatenprofil oder in der Bewerbung. Beispiele InternExtern
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, wann die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden.
Beschreibung Dieses Attribut gibt die Aktualität der analysierten Daten an. Es zeigt das Datum und die Uhrzeit des letzten Datenabzugs aus Workday Recruiting. Dies ist wichtig, damit Benutzer verstehen, wie aktuell die Analyse ist. Es hilft ihnen, die Ergebnisse richtig zu interpretieren, da sie wissen, ob sie Echtzeitdaten oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Bedeutung Bietet Kontext zur Datenaktualität und stellt sicher, dass Nutzer verstehen, wie aktuell die Prozessanalyse ist. Datenquelle Dieser `Timestamp` wird während des `Daten`-Extraktions-, Transformations- und Ladevorgangs (`ETL-Prozess`) generiert 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 identifiziert die Herkunft der Daten, in diesem Fall Workday Recruiting. Es hilft bei der Data Governance und Fehlerbehebung, insbesondere wenn Daten aus mehreren Systemen kombiniert werden. Obwohl es in einer Einzel-System-Analyse trivial erscheinen mag, ist es eine Best Practice, es immer einzuschließen. Es bestätigt die Herkunft der Daten und wird kritisch, wenn später andere HR-Systeme integriert werden. Bedeutung Identifiziert den Ursprung der Daten, was entscheidend ist für Data Governance, Validierung und die Verwaltung von Daten aus mehreren Quellen. Datenquelle Dies ist ein statischer Wert („Workday Recruiting“), der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird. Beispiele Workday Recruiting
	Stellenanfrage-ID JobRequisitionId	Die eindeutige Kennung für die Stellenausschreibung, auf die sich der Kandidat beworben hat.
Beschreibung Die Job Requisition ID ist der Identifikator für die genehmigte Stellenausschreibung. Eine einzelne Stellenausschreibung kann viele Bewerbungen zugeordnet haben. Dieses Attribut ermöglicht die Analyse auf Stellenausschreibungs-Ebene. Zum Beispiel kann man die Gesamtzeit analysieren, in der eine Stellenausschreibung offen war, die Anzahl der gewonnenen Kandidaten oder die Rekrutierungsfunnel für verschiedene Arten von Stellen (z. B. Engineering- vs. Vertriebs-Ausschreibungen) vergleichen. Bedeutung Verknüpft mehrere Bewerbungen mit einer einzigen Stellenausschreibung, was die Analyse von Kennzahlen auf Stellenebene und Hiring Funnels ermöglicht. Datenquelle Dies ist ein primärer Identifikator für das Job Requisition Objekt in Workday Recruiting und ist mit jeder Stellenbewerbung verknüpft. Beispiele REQ-2023-105REQ-2024-012REQ-2024-345
	Stellenstandort JobLocation	Der geografische Standort oder das Land der Stelle.
Beschreibung Dieses Attribut spezifiziert die Stadt, das Bundesland oder das Land, in dem die Stelle angesiedelt ist. Für Remote-Positionen kann es eine Region angeben oder als „Remote“ gekennzeichnet sein. Der Standort ist eine leistungsstarke Dimension für die Analyse. Er ermöglicht den Vergleich von „Time to Hire“ und anderen KPIs über verschiedene Regionen hinweg, was Variationen aufgrund lokaler Marktbedingungen, Talentverfügbarkeit oder regionaler Prozessunterschiede aufzeigen kann. Bedeutung Ermöglicht eine geografische Analyse des Rekrutierungsprozesses, die regionale Unterschiede bei Zykluszeiten und Effizienz hervorhebt. Datenquelle Diese Informationen sind Teil der Job Requisition Details in Workday. Beispiele New York, NYLondon, UKRemote (US)Berlin, Germany
	Time To Hire TimeToHire	Die Gesamtzeit vom Eingang einer Bewerbung bis zur Einstellung des Kandidaten.
Beschreibung Dies ist eine Case-Level-Berechnung, die die Gesamtdauer des Rekrutierungsprozesses für erfolgreiche Kandidaten misst. Sie wird als Zeitdifferenz zwischen dem Event „Bewerbung erhalten“ und dem Event „Kandidat eingestellt“ berechnet. Dies ist einer der wichtigsten KPIs im Recruiting („Durchschnittliche Time-to-Hire“). Er bietet ein übergeordnetes Maß für die Gesamteffizienz des Einstellungsprozesses. Die Verfolgung dieser Metrik über die Zeit und über Abteilungen hinweg hilft, systemische Verbesserungen oder Rückschritte zu identifizieren. Bedeutung Ein entscheidender, übergeordneter KPI, der die Gesamteffizienz des Rekrutierungstrichters von Anfang bis Ende misst. Datenquelle Dies wird aus den Event Log-Daten berechnet, nachdem sie aus Workday extrahiert wurden. Beispiele 259200043200003456000

Erforderlich Empfohlen Optional

Rekrutierungs- & Talent Acquisition-Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine genaue Prozessentdeckung zu ermöglichen und Engpässe in Ihrem Einstellungsworkflow zu identifizieren.

7 Empfohlen 8 Optional

	Aktivität	Beschreibung
	`Kandidat` eingestellt	Der erfolgreiche Abschluss des Rekrutierungsprozesses, bei dem der Kandidat formell als Mitarbeiter eingestellt wird. Dies wird erfasst, wenn der Geschäftsprozess „Hire“ in Workday erfolgreich abgeschlossen wird und ein Mitarbeiterdatensatz erstellt wird.
Bedeutung Dies ist das primäre Erfolgs-End-Event. Der Timestamp ist essenziell für die Berechnung der Time-to-Hire und die Messung der gesamten Prozesseffizienz und Erfolgsraten. Datenquelle Dies ist ein wichtiges, explizites Event, das vom Geschäftsprozess „Hire“ in Workday HCM protokolliert wird. Der Abschluss-Timestamp wird in der Prozesshistorie erfasst. Erfassen Erfasst vom Abschluss-Zeitstempel des Geschäftsprozesses 'Einstellung' für den Kandidaten. Ereignistyp explicit
	Angebot angenommen	Repräsentiert die formelle Annahme des Stellenangebots durch den Kandidaten. Dieses Event wird erfasst, wenn der Kandidat die Aufgabe „Angebot annehmen“ in seinem Workday-Portal abschließt oder wenn ein Recruiter den Status manuell aktualisiert.
Bedeutung Diese Aktivität ist entscheidend für die Berechnung der Angebotsannahmequoten nach Quelle, Abteilung oder Recruiter. Sie löst auch nachfolgende Pre-Hire-Aktivitäten wie Background Checks aus. Datenquelle Explizit protokolliert, wenn ein Kandidat das Angebot über sein Kandidatenportal annimmt. Die Aktion wird mit einem Zeitstempel in der Geschäftsprozesshistorie der Bewerbung erfasst. Erfassen Erfasst vom Abschluss-Zeitstempel der Aufgabe 'Angebot annehmen'. Ereignistyp explicit
	Angebot unterbreitet	Markiert die formelle Unterbreitung eines Stellenangebots an einen Kandidaten. Dies ist ein diskretes Event, das erfasst wird, wenn der Geschäftsprozess „Angebot erstellen“ oder „Vergütung vorschlagen“ für die Stellenbewerbung in Workday erfolgreich abgeschlossen wird.
Bedeutung Dies ist ein wichtiger Meilenstein zur Berechnung der Time-to-Offer und zur Analyse der Angebotskonformität. Es ist der Ausgangspunkt für die Messung der Angebotsannahmequoten. Datenquelle Dieses Event wird explizit in der Geschäftsprozesshistorie der Stellenbewerbung protokolliert. Der Abschluss-Timestamp des Angebotserstellungsschritts liefert die Aktivitätszeit. Erfassen Erfasst vom Abschluss-Zeitstempel des Geschäftsprozesses 'Angebot erstellen'. Ereignistyp explicit
	Bewerbung erhalten	Markiert den Beginn des Rekrutierungsprozesses für die Stellenbewerbung eines Kandidaten. Dieses Event wird erfasst, wenn ein Kandidat seine Bewerbung für eine spezifische Stellenausschreibung erfolgreich über das Workday-Portal oder eine integrierte Karriereseite einreicht.
Bedeutung Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Aktivität bis zu nachfolgenden Meilensteinen ist grundlegend für die Messung der gesamten Time-to-Hire und der Effektivität des Sourcing-Kanals. Datenquelle Workday protokolliert dies als explizites Event, wenn der Geschäftsprozess „Bewerben für Job“ für einen Kandidaten erfolgreich abgeschlossen wird. Der Event Timestamp ist in der Bewerbungshistorie des Kandidaten verfügbar. Erfassen Erfasst vom Zeitstempel der Bewerbungseinreichung im Kandidatenprofil. Ereignistyp explicit
	Kandidat abgelehnt	Markiert ein erfolgloses Ende des Prozesses, bei dem das Unternehmen beschließt, nicht mit einem Kandidaten fortzufahren. Dies wird abgeleitet, wenn ein Recruiter den Kandidaten in den Status „Abgelehnt“ oder „Nicht eingestellt“ versetzt.
Bedeutung Dies ist ein kritisches End-Event zur Analyse von Kandidaten-Drop-Off-Hotspots und Ablehnungsquoten in verschiedenen Phasen. Es hilft, Probleme im Interview- oder Screening-Prozess zu identifizieren. Datenquelle Abgeleitet vom Timestamp, wenn der Status des Kandidaten in der Bewerbungshistorie auf „Abgelehnt“ geändert wird. Oft wird auch ein Ablehnungsgrund erfasst. Erfassen Abgeleitet vom effektiven Zeitstempel des Übergangs zu einer 'Abgelehnt'-Disposition. Ereignistyp inferred
	Kandidat zur Angebotsphase verschoben	Ein wichtiger Meilenstein, der die Entscheidung zur Unterbreitung eines Stellenangebots an den Kandidaten anzeigt. Dies wird erfasst, wenn die Bewerbung des Kandidaten in die Phase 'Angebot' des Rekrutierungsprozesses übergeht.
Bedeutung Diese Aktivität ist ein entscheidendes Tor im Prozess, das den erfolgreichen Abschluss aller Bewertungsphasen markiert. Sie ist ein Vorläufer des formellen Angebots und ein Schlüsselpunkt für die Kohortenanalyse. Datenquelle Abgeleitet aus dem Audit Trail der Stellenbewerbung, insbesondere dem Timestamp, wenn sich der Status des Kandidaten auf „Angebot“ ändert. Erfassen Identifiziert durch die Statusänderung zur Phase 'Angebot' im Fortschritt des Kandidaten. Ereignistyp inferred
	Kandidat zur Interviewphase verschoben	Zeigt an, dass ein Kandidat die Vorauswahl bestanden hat und nun für ein Vorstellungsgespräch infrage kommt. Dieses Ereignis wird erfasst, wenn ein Recruiter den Kandidaten in der Recruiting-Prozesskette in die Phase „Interview“ verschiebt.
Bedeutung Dieser Meilenstein markiert den Übergang vom Screening zur aktiven Bewertung. Er ist ein Schlüsselpunkt für die Analyse von Konversionsraten und der Effizienz am oberen Ende des Rekrutierungs-Funnels. Datenquelle Abgeleitet vom Timestamp, wenn die Recruiting-Phase des Kandidaten in der Historie der Stellenbewerbung auf „Interview“ oder eine ähnliche Bezeichnung geändert wird. Erfassen Identifiziert durch die Statusänderung zur Phase 'Interview' im Fortschritt des Kandidaten. Ereignistyp inferred
	`Hintergrundprüfung` bestanden	Markiert den erfolgreichen Abschluss des Background Check-Prozesses. Dieses Event wird abgeleitet, wenn der Status des Kandidaten aktualisiert wird, um widerzuspiegeln, dass die erforderlichen Überprüfungen bestanden wurden und er zur Einstellung freigegeben ist.
Bedeutung Dies ist der letzte Prüfpunkt, bevor der Einstellungsprozess abgeschlossen werden kann. Verzögerungen beim Erhalt und der Protokollierung dieser Freigabe können den Starttermin eines Kandidaten verzögern. Datenquelle Abgeleitet von einer Statusaktualisierung der Bewerbung des Kandidaten, z. B. dem Wechsel in eine Phase wie „Einstellungsbereit“ oder „Hintergrundüberprüfung abgeschlossen“. Erfassen Abgeleitet aus der Statusänderung, die eine abgeschlossene und bestandene Hintergrundprüfung anzeigt. Ereignistyp inferred
	`Hintergrundprüfung` initiiert	Zeigt den Beginn der Hintergrundüberprüfung für einen Kandidaten an, der ein Angebot angenommen hat. Dies wird in der Regel daraus abgeleitet, dass der Kandidat in die Phase „Background Check“ (Hintergrundüberprüfung) wechselt, was oft eine Integration mit einem Drittanbieter auslöst.
Bedeutung Diese Aktivität ist entscheidend für die Überwachung der Compliance und die Analyse von Verzögerungen zwischen Angebotsannahme und dem Beginn der Pre-Hire-Überprüfungen. Sie hilft, einen reibungslosen Übergang zum Onboarding zu gewährleisten. Datenquelle Abgeleitet vom Timestamp des Wechsels des Kandidaten in die Phase „Background Check“ (Hintergrundüberprüfung) in seinem Rekrutierungsprozess. Der Audit Trail für die Stellenbewerbung zeigt diese Statusänderung. Erfassen Abgeleitet vom effektiven Zeitstempel des Übergangs zur Phase 'Hintergrundprüfung'. Ereignistyp inferred
	Antrag geprüft	Repräsentiert den Abschluss der ersten Überprüfung einer Kandidatenbewerbung durch einen Recruiter oder ein Screening-Team. Dies wird typischerweise abgeleitet, wenn der Kandidat von einem Status „Beworben“ oder „Neu“ in eine „Screening“- oder „In Überprüfung“-Phase verschoben wird.
Bedeutung Diese Aktivität ist entscheidend für die Analyse der Effizienz der initialen Screening-Phase. Die Verfolgung ihres Durchsatzes und ihrer Dauer hilft, Engpässe frühzeitig im Rekrutierungs-Funnel zu identifizieren. Datenquelle Abgeleitet vom effektiven Datum der Phasenänderung des Kandidaten zu einem Screening- oder Prüfschritt im Audit Trail des Geschäftsprozesses „Recruiting“. Erfassen Abgeleitet vom Zeitstempel, wann die Phase des Kandidaten auf 'Screen' aktualisiert wird. Ereignistyp inferred
	Antrag zurückgezogen	Ein Endereignis, bei dem sich der Kandidat freiwillig von der Berücksichtigung für die Rolle zurückzieht. Dies wird erfasst, wenn der Status des Kandidaten entweder durch ihn selbst oder durch einen Recruiter auf 'Zurückgezogen' aktualisiert wird.
Bedeutung Die Verfolgung, wann und warum Kandidaten zurücktreten, ist entscheidend, um Probleme der Candidate Experience, die Prozessdauer oder die Wettbewerbsfähigkeit von Angeboten zu verstehen. Es ist eine Schlüsselmetrik für die Drop-Off-Analyse. Datenquelle Abgeleitet vom Timestamp, wenn der Status des Kandidaten auf „Zurückgezogen“ aktualisiert wird. Dies kann vom Kandidaten in seinem Portal oder von einem Recruiter erfolgen. Erfassen Abgeleitet vom effektiven Zeitstempel des Übergangs zu einer 'Zurückgezogen'-Disposition. Ereignistyp inferred
	Feedback übermittelt	Repräsentiert den Zeitpunkt, zu dem ein Interviewer seine Bewertung eines Kandidaten nach dem Interview formell einreicht. Workday bietet einen spezifischen Mechanismus für Interviewer, um Feedback direkt im Profil des Kandidaten zu geben.
Bedeutung Dies ist essenziell für die Analyse der „Hiring Manager Feedback Timeliness“. Verzögerungen hier sind ein häufiger Engpass, und deren Verfolgung hilft, Service Level Agreements durchzusetzen. Datenquelle Dies ist ein explizites Event, das erfasst wird, wenn Feedback über die Aufgabe „Interview-Feedback geben“ eingereicht wird. Der Timestamp der Einreichung wird dem Interviewdatensatz zugeordnet. Erfassen Extrahiert vom Abschluss-Zeitstempel des Ereignisses 'Interview-Feedback geben'. Ereignistyp explicit
	Interview abgeschlossen	Markiert den Abschluss eines geplanten Interviews mit einem Kandidaten. Dies wird in der Regel abgeleitet, wenn ein Interviewer oder Recruiter den Status des Interviews von „Geplant“ auf „Abgeschlossen“ oder „Durchgeführt“ aktualisiert.
Bedeutung Diese Aktivität dient als Auslöser für das Feedback-Einreichungsfenster. Die Analyse der Zeit von diesem Punkt bis zur Feedback-Einreichung ist entscheidend für die Messung der Reaktionsfähigkeit des Hiring Managers. Datenquelle Abgeleitet von einer Statusaktualisierung des geplanten Interviewobjekts oder einer manuellen Phasenänderung für den Kandidaten in Workday Recruiting, nachdem das Interview stattgefunden hat. Erfassen Abgeleitet vom Zeitstempel der Interview-Statusaktualisierung oder der Kandidatenphasenänderung nach dem Interview. Ereignistyp inferred
	Interview geplant	Repräsentiert die formelle Planung eines Interviews mit dem Kandidaten. Dies wird typischerweise erfasst, wenn ein Interview-Event innerhalb der Workday-Planungsfunktionalität für die spezifische Stellenbewerbung erstellt und bestätigt wird.
Bedeutung Die Messung der Zeit zwischen dieser und vorhergehenden Aktivitäten hilft, Verzögerungen in der Koordination zu identifizieren. Dies ist entscheidend für die Verbesserung der Candidate Experience und die Beschleunigung des Interviewprozesses. Datenquelle Workdays Interview-Planungsfunktion erstellt Events mit Timestamps. Diese Aktivität kann aus dem Erstellungsdatum des geplanten Interviews, das mit der Bewerbung verknüpft ist, erfasst werden. Erfassen Erfasst vom Erstellungsereignis eines Interviewdatensatzes im Rekrutierungsmodul. Ereignistyp explicit
	Onboarding initiiert	Repräsentiert den Start des Onboarding-Prozesses für neue Mitarbeiter innerhalb von Workday. Dies ist typischerweise ein explizites Event, das Teil des Haupt-Geschäftsprozesses „Hire“ ist oder unmittelbar danach ausgelöst wird.
Bedeutung Die Analyse der Zeit von 'Angebot angenommen' bis zu dieser Aktivität hilft, die Candidate Experience nach dem Angebot zu optimieren. Sie stellt sicher, dass neue Mitarbeiter engagiert und auf ihren ersten Arbeitstag vorbereitet sind. Datenquelle Workdays Geschäftsprozess „Onboarding“ hat einen klaren Initiierungs-Timestamp. Dieser kann aus dem Prozess-Audit-Trail für den neuen Mitarbeiterdatensatz erfasst werden. Erfassen Erfasst vom Initiierungs-Zeitstempel des Geschäftsprozesses 'Onboarding'. Ereignistyp explicit

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus Workday Recruiting

Schritte

In Workday anmelden: Melden Sie sich in Ihrem Workday-Tenant mit einem Konto an, das Berechtigungen für benutzerdefinierte Berichte und Recruiting-Daten besitzt.
Benutzerdefinierten Bericht erstellen: Rufen Sie die Aufgabe „Benutzerdefinierten Bericht erstellen“ auf. Wählen Sie „Erweitert“ als Berichtstyp und aktivieren Sie die Option „Als Webdienst aktivieren“. Nutzen Sie als Datenquelle eine indizierte Quelle wie „Alle Bewerbungen“, um die Performance zu steigern.
Primäres Business-Objekt definieren: Legen Sie „Bewerbung“ (Job Application) als primäres Objekt fest. Dies dient als Basis für den Bericht und als Case-Identifikator.
Datenspalten hinzufügen: Fügen Sie die erforderlichen Felder hinzu. Verwenden Sie „Bewerbung“ für die JobApplicationId. Weitere Attribute wie „Recruiter“ oder „Hiring Manager“ fügen Sie über die verknüpften Business-Objekte hinzu.
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 Activity-Namen und eines für den Event-Timestamp. Die Logik finden Sie im Abschnitt „Abfrage“. Um z. B. „Angebot unterbreitet“ zu erfassen, prüfen Sie den Abschluss des Prozesses „Vergütung vorschlagen“ und extrahieren den entsprechenden Timestamp.
Berechnete Felder zum Bericht hinzufügen: Fügen Sie alle 30 neuen Felder (15 für Namen, 15 für Timestamps) als Spalten hinzu. Der Bericht liegt nun im „Wide“-Format vor: eine Zeile pro Bewerbung mit vielen Spalten für die potenziellen Aktivitäten.
Webdienst-Optionen konfigurieren: Stellen Sie im Reiter „Webdienst“ sicher, dass das Kontrollkästchen „Als Webdienst aktivieren“ markiert ist. Notieren Sie sich hier den Namespace und die URL.
Berechtigungen festlegen: Geben Sie den Bericht für einen Integration System User (ISU) oder eine Sicherheitsgruppe frei, die den RaaS-Endpunkt aufruft. Der User benötigt Zugriff auf die Domäne der Datenquelle, z. B. „Recruiting: Job Applications“.
Bericht ausführen und testen: Starten Sie den Bericht in der Workday-Oberfläche. Prüfen Sie, ob die Zeilenanzahl plausibel ist und die berechneten Felder für Testfälle korrekt befüllt werden.
Extraktion planen: Nutzen Sie ein externes Tool oder eine Middleware (z. B. MuleSoft, Boomi oder ein Skript), um die RaaS-URL regelmäßig abzurufen. Das Tool muss den SOAP- oder REST-Aufruf mit korrekter Authentifizierung beherrschen.
Daten transformieren: Die Rohdaten des RaaS-Aufrufs liegen im XML- oder CSV-Format vor. Sie müssen nun einen Transformationsschritt (z. B. per Python) implementieren, um die Daten zu „unpivoten“. Das Skript erstellt für jedes ausgefüllte Aktivität/Timestamp-Paar einer Bewerbung eine eigene Zeile im finalen Event Log („Long“-Format), bestehend aus JobApplicationId, ActivityName und EventTime.

Konfiguration

Berichtstyp: Verwenden Sie immer „Erweitert“ (Advanced), um komplexe berechnete Felder zu ermöglichen und auf verwandte Business-Objekte zuzugreifen.
Datenquelle: Nutzen Sie eine indizierte Datenquelle wie „Alle Bewerbungen“ (All Job Applications), um eine effiziente Berichtsausführung zu garantieren. Vermeiden Sie nicht-indizierte Quellen bei großen Datensätzen.
Filterung nach Datumsbereich: Es ist wichtig, einen Filter auf das Feld „Bewerbungsdatum“ des Business-Objekts „Bewerbung“ zu setzen. Beginnen Sie mit einem kleineren Zeitraum von 3 bis 6 Monaten, um das Datenvolumen und die Performance zu kontrollieren.
Primäres Business-Objekt: Das Hauptobjekt muss „Bewerbung“ (Job Application) sein, damit die JobApplicationId als Case-Identifikator dienen kann.
Webdienst-Aktivierung: Aktivieren Sie die Option „Als Webdienst aktivieren“ in der Berichtskonfiguration, um den Zugriff über APIs zu ermöglichen.
Sicherheit und Berechtigungen: Der Bericht muss für einen dedizierten Integration System User (ISU) freigegeben werden. Dieser ISU benötigt Sicherheitsberechtigungen für die erforderlichen Datenbereiche, darunter „Recruiting: Job Applications“, „Business Process Transactions“ und „Worker Data“.
Ausgabeformat: Workday bietet verschiedene Formate an (XML, CSV, JSON). XML (insbesondere das Format „Simple XML“) ist oft die zuverlässigste Wahl für die strukturierte Datenextraktion per API.

a Beispielabfrage config

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

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

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

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

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

Schritte

Workday-Zugriff konfigurieren: Erstellen Sie einen Integration System User (ISU) in Workday. Gewähren Sie diesem Benutzer Zugriff auf die erforderlichen Sicherheitsbereiche für die Recruiting-API, wie z. B. „Worker Data: Public Worker Reports“, „Job Application“ und „Recruiting: Reports“.
API-Endpunkt identifizieren: Suchen Sie den REST-API-Endpunkt für die Operation „Get Job Applications“ in Ihrem Workday-Tenant. Die URL folgt meist diesem 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 benötigten Bibliotheken via pip: pip install requests pandas.
Authentifizierungsskript entwickeln: Implementieren Sie in Ihrem Skript die Basic Authentication mit den ISU-Zugangsdaten aus Schritt 1. Benutzername und Passwort werden im Request-Header übertragen.
API-Anfragelogik implementieren: Erstellen Sie eine Funktion zum Aufruf des Endpunkts. Nutzen Sie Parameter wie updatedSince, um nur Bewerbungen abzurufen, die nach einem bestimmten Datum geändert wurden – dies ist entscheidend für die Datenmenge.
API-Paginierung handhaben: Die API gibt pro Anfrage nur eine begrenzte Anzahl an Datensätzen zurück. Ihr Skript muss die Antwort auf total (Gesamtzahl) sowie einen next-Link oder Offset-Parameter prüfen und alle Seiten in einer Schleife abrufen.
Activity-Mapping definieren: Erstellen Sie ein Mapping-Dictionary oder Bedingungen im Skript. Diese Logik übersetzt Workday-Status und Phasen (z. B. „Screen“, „Interview“, „Offer“, „Hire“) in die gewünschten Activity-Namen (z. B. „Bewerbung geprüft“, „Kandidat zum Interview eingeladen“).
Bewerberdaten transformieren: Parsen Sie für jede abgerufene Bewerbung den Audit-Trail oder die Phasen-Historie. Diese enthält die Abfolge von Schritten, Entscheidungen und Events mit den jeweiligen Timestamps.
Event-Log-Zeilen generieren: Gehen Sie die Historie jeder Bewerbung durch. Erstellen Sie für jedes relevante Ereignis, das Ihrem Mapping entspricht, einen Datensatz für das finale Event Log. Füllen Sie dabei JobApplicationId, ActivityName, EventTime und weitere Attribute aus.
Daten aggregieren und strukturieren: Sammeln Sie alle generierten Zeilen aus allen Bewerbungen in einer einzigen Liste.
CSV-Datei erstellen und exportieren: Nutzen Sie die pandas-Bibliothek, um die Liste in einen DataFrame umzuwandeln und diesen als CSV zu exportieren. Die Spaltenüberschriften sollten den Anforderungen von ProcessMind entsprechen (z. B. CaseId, Activity, Timestamp).
Prüfen und hochladen: Kontrollieren Sie die CSV-Datei auf Korrektheit und Vollständigkeit, bevor Sie diese in das Process-Mining-Tool hochladen.

Konfiguration

Workday Integration System User (ISU): Ein ISU mit einem starken, nicht ablaufenden Passwort ist erforderlich. Dieser benötigt Berechtigungen für die Sicherheitsdomänen „Recruiting“ und „Worker Data“, um auf Bewerbungs- und Kandidatendetails zuzugreifen.
API-Endpunkt und Version: Sie müssen den korrekten REST-API-Endpunkt für Ihren Workday-Tenant verwenden. Geben Sie die API-Version in der Anfrage an, um ein konsistentes Verhalten zu gewährleisten.
Datumsbereichsfilter: Das Skript sollte einen Datumsfilter (z. B. updatedSince) verwenden, um die Abfrage auf einen überschaubaren Zeitraum zu begrenzen. Für die erste Extraktion werden 3–6 Monate empfohlen. Für spätere Delta-Uploads nutzen Sie den Timestamp der letzten erfolgreichen Extraktion.
Limit für Paginierung: Beachten Sie den Parameter limit in der API, der steuert, wie viele Datensätze pro Seite zurückgegeben werden. Ein typisches Maximum liegt bei 100. Das Skript muss so konzipiert sein, dass es mehrere aufeinanderfolgende Seitenanfragen verarbeitet.
Antwortfelder: Zur Performance-Steigerung können Sie über den Parameter fields (oder ähnlich) festlegen, welche Felder zurückgegeben werden sollen. Dies reduziert die Größe der API-Antwort.
Konfiguration des Activity-Mappings: Die Kernlogik des Skripts ist das Mapping von Workday-Phasen auf die definierten Aktivitäten. Dies muss eventuell an die spezifische Konfiguration Ihres Workday-Recruiting-Prozesses angepasst werden.

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 ein lizenziertes ETL- oder iPaaS-Tool wie CData oder MuleSoft mit installiertem Workday-Connector nutzen. Sie benötigen Zugangsdaten für einen Integration System User (ISU) mit API-Berechtigungen für die Bereiche Recruiting und Staffing.
Workday-Verbindung konfigurieren: Erstellen Sie in Ihrem ETL-Tool eine neue Verbindung zu Workday. Geben Sie die Tenant-URL, die API-Version und die ISU-Daten (Passwort oder OAuth 2.0-Token) ein. Testen Sie die Verbindung.
Datenschema untersuchen: Nutzen Sie den Schema-Browser Ihres Tools, um die verfügbaren Workday-Objekte zu sichten. Diese werden oft als Tabellen wie Job_Application, Job_Requisition oder Candidate_Stage_History angezeigt. Machen Sie sich mit den Feldern und Relationen vertraut.
Zentrale Datenobjekte identifizieren: Sie benötigen primär Daten zu Bewerbungen, Kandidatenhistorien, Interviews, Angeboten und Einstellungen. Die genauen Namen hängen vom Connector ab; suchen Sie nach Objekten, die diese Kerneinheiten abbilden.
SQL-Abfrage entwickeln: Erstellen Sie eine Extraktions-Pipeline. Nutzen Sie einen SQL-Transformationsschritt und fügen Sie die bereitgestellte SQL-Abfrage ein. Diese führt Daten aus verschiedenen Objekten in einem einheitlichen Event-Log-Format zusammen.
Abfrage parametrisieren: Ergänzen Sie die WHERE-Klausel um Parameter für den Zeitraum (z. B. startDate und endDate). So können Sie das Zeitfenster anpassen, ohne den Code zu ändern.
Extraktionsjob ausführen: Starten Sie den Job. Das Tool verbindet sich mit Workday, führt die SQL-Abfrage per API aus und lädt die Daten in einen Zwischenspeicher.
Daten prüfen und validieren: Nutzen Sie die Vorschaufunktion Ihres ETL-Tools. Prüfen Sie, ob die Zeilenanzahl realistisch ist, alle Spalten befüllt sind und verschiedene Aktivitäten korrekt erfasst wurden.
Ziel konfigurieren: Definieren Sie das Zielformat, üblicherweise eine CSV-Datei für den Upload in ProcessMind. Legen Sie Dateiname, Trennzeichen (Komma) und Kodierung (UTF-8) fest.
Abschließen und exportieren: Führen Sie den Job vollständig aus. Achten Sie darauf, dass die Spaltenüberschriften exakt den Anforderungen entsprechen: JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Department und ApplicationStatus.

Konfiguration

Workday-Connector-Zugangsdaten: Die Verbindung erfordert die Workday-Tenant-URL 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.
Aktivierung von Webdiensten: Der Connector erfordert möglicherweise die Angabe der freizugebenden Workday-Webservices. Stellen Sie sicher, dass Dienste für Recruiting, Staffing und Human Resources aktiviert sind, um auf alle erforderlichen Datenobjekte zuzugreifen.
Datumsbereich: Um die Leistung und das Datenvolumen zu optimieren, ist es entscheidend, die Extraktion auf einen bestimmten Zeitraum zu begrenzen. Wir empfehlen ein initiales Laden von 3 bis 6 Monaten, gefolgt von inkrementellen täglichen oder wöchentlichen Updates. Dies wird über die WHERE-Klausel in der SQL-Abfrage gesteuert.
Filter für den Datenumfang: Wenn Sie nur Prozesse für bestimmte Unternehmensteile analysieren möchten, können Sie Filter in der WHERE-Klausel für Felder wie Unternehmen, Kostenstelle oder übergeordnete Organisation hinzufügen.
API-Version: Einige Connectoren erfordern die Angabe der Workday-API-Version. Verwenden Sie am besten eine aktuelle, unterstützte Version, um Zugriff auf die neuesten Datenobjekte und Funktionen zu erhalten.
Performance-Hinweise: Vollständige Datenextraktionen aus Workday können ressourcenintensiv sein. Planen Sie umfangreiche Jobs außerhalb der Stoßzeiten ein. Für fortlaufende Analysen empfiehlt sich eine inkrementelle Ladestrategie basierend auf einem „last modified“-Timestamp, um nur neue oder geänderte Datensätze abzurufen.

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

Ihre Datenvorlage für Rekrutierung & Talentakquisition

Ihre Datenvorlage für Rekrutierung & Talentakquisition

Rekrutierungs- & Talent Acquisition-Attribute

Rekrutierungs- & Talent Acquisition-Aktivitäten

Extraktionsleitfäden

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

Schritte

Konfiguration

a Beispielabfrage config

Workday Recruiting API Extraktion via Python Script

Schritte

Konfiguration

a Beispielabfrage python

ETL Tool Extraction with a Workday Connector

Schritte

Konfiguration

a Beispielabfrage sql

Bereit, um loszulegen?

Engpässe bei der Einstellung beenden: Optimieren Sie Ihre Talentakquise noch heute

Ihre Datenvorlage für Rekrutierung & Talentakquisition

Ihre Datenvorlage für Rekrutierung & Talentakquisition

Rekrutierungs- & Talent Acquisition-Attribute

Rekrutierungs- & Talent Acquisition-Aktivitäten

Extraktionsleitfäden

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

Schritte

Konfiguration

a Beispielabfrage config

Workday Recruiting API Extraktion via Python Script

Schritte

Konfiguration

a Beispielabfrage python

ETL Tool Extraction with a Workday Connector

Schritte

Konfiguration

a Beispielabfrage sql

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Engpässe bei der Einstellung beenden: Optimieren Sie Ihre Talentakquise noch heute