> Ciągłe doskonalenie procesów > Rekrutacja i pozyskiwanie talentów > Workday Recruiting > Szablon danych

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Workday Recruiting

← Wróć do przewodnika ulepszania procesów

Atrybuty rekrutacji i pozyskiwania talentów(19) Czynności związane z rekrutacją i pozyskiwaniem talentów(15) Instrukcje wyodrębniania danych(3)

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Ten szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do analizy rekrutacji i pozyskiwania talentów. Opisuje najważniejsze atrybuty i czynności do śledzenia oraz wyjaśnia, jak wyodrębnić te dane z Workday Recruiting. Dzięki niemu można uporządkować przygotowanie danych i szybciej rozpocząć process mining.

Zalecane atrybuty do zebrania
Najważniejsze czynności do śledzenia
Wskazówki dotyczące wyodrębniania danych z Workday Recruiting

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty rekrutacji i pozyskiwania talentów

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować rekrutację i pozyskiwanie talentów oraz lepiej zrozumieć proces zatrudniania.

3 Wymagane 5 Zalecane 11 Opcjonalne

	Nazwa	Opis
	Aplikacja na stanowisko JobApplicationId	Unikalny identyfikator aplikacji kandydata na stanowisko, pełniący funkcję głównego identyfikatora case w procesie rekrutacji.
Opis Identyfikator aplikacji na stanowisko pozwala śledzić przebieg rekrutacji jednego kandydata na konkretne stanowisko, od przesłania aplikacji po ostateczną decyzję. Każda interakcja, zmiana statusu i decyzja dotycząca aplikacji jest powiązana z tym identyfikatorem. W process mining ten atrybut ma podstawowe znaczenie. Umożliwia odtworzenie pełnego przebiegu procesu dla każdego kandydata oraz analizę czasu trwania, wąskich gardeł i wybranych ścieżek. Łączy wszystkie powiązane czynności w jeden spójny case. Dlaczego to ważne To podstawowy identyfikator case, który łączy wszystkie czynności rekrutacyjne dotyczące jednego kandydata i umożliwia analizę całego procesu zatrudnienia. Skąd pobrać Ten identyfikator jest podstawowym elementem Workday Recruiting. Zwykle można go znaleźć w raportach i źródłach danych dotyczących aplikacji na stanowiska. Przykłady APP-2023-001234APP-2023-005678APP-2024-009101
	Czas zdarzenia EventTime	Znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie.
Opis Ten atrybut zapisuje dokładną datę i godzinę wykonania konkretnej czynności rekrutacyjnej. Znaczniki czasu stanowią podstawę process mining, ponieważ określają chronologiczną kolejność zdarzeń. W analizie służą do obliczania czasu między czynnościami, mierzenia całkowitego czasu trwania procesu, na przykład czasu rekrutacji, oraz wykrywania opóźnień i wąskich gardeł. Są niezbędne w każdej analizie czasowej lejka rekrutacyjnego. Dlaczego to ważne Znaczniki czasu są niezbędne do obliczania wszystkich KPI związanych z czasem, określania długości procesu i wykrywania wąskich gardeł. Skąd pobrać Odpowiada dacie zakończenia lub dacie transakcji etapu procesu biznesowego w Workday Recruiting. Przykłady 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	Nazwa czynności ActivityName	Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w danym momencie procesu rekrutacji.
Opis Nazwa czynności opisuje pojedynczy krok lub etap rekrutacji, na przykład „Wstępnie oceniono aplikację”, „Zaplanowano rozmowę” lub „Przedstawiono ofertę”. Czynności te tworzą sekwencję zdarzeń składających się na proces. Ten atrybut jest niezbędny do wizualizacji mapy procesu, identyfikowania różnych ścieżek aplikacji oraz analizy częstotliwości i kolejności zdarzeń. Pozwala zrozumieć, co dzieje się w procesie. Dlaczego to ważne Ten atrybut określa kroki procesu rekrutacji i umożliwia wizualizację oraz analizę jego przebiegu. Skąd pobrać Dane pochodzą z nazw etapów procesów biznesowych lub zmian statusu aplikacji na stanowisko w Workday Recruiting. Przykłady Wstępnie oceniono aplikacjęPrzeprowadzono rozmowęPrzyjęto ofertęOdrzucono kandydata
	Dział Department	Dział lub jednostka biznesowa powiązana z zapotrzebowaniem na pracownika.
Opis Ten atrybut określa jednostkę organizacyjną, na przykład dział inżynieryjny, marketing lub finanse, dla której prowadzona jest rekrutacja. Dane pochodzą z powiązanej z zapotrzebowaniem na pracownika organizacji przełożonych. Filtrowanie według działu pozwala porównywać procesy rekrutacyjne w różnych częściach firmy. W dashboardzie „Sprawność wstępnej selekcji aplikacji” można sprawdzić, czy w niektórych działach selekcja trwa dłużej, co może wskazywać na odmienne praktyki lub zapotrzebowanie na zasoby. Dlaczego to ważne Umożliwia porównanie wyników i sprawności procesu rekrutacji w różnych jednostkach biznesowych i działach. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. Dane pochodzą z organizacji przełożonych powiązanej z zapotrzebowaniem na pracownika. Przykłady InżynieriaSprzedażZasoby ludzkieFinanse
	Imię i nazwisko rekrutera RecruiterName	Imię i nazwisko rekrutera odpowiedzialnego za obsługę aplikacji na stanowisko.
Opis Ten atrybut wskazuje głównego specjalistę ds. pozyskiwania talentów lub rekrutera przypisanego do aplikacji i zapotrzebowania na pracownika. Zazwyczaj odpowiada on za przeprowadzenie kandydata przez proces. Analiza procesu według rekrutera pomaga ocenić wyniki zespołu i obciążenie pracą. Umożliwia utworzenie dashboardu „Wyniki i przepustowość pracy rekruterów” oraz obliczanie KPI, takich jak „Różnica czasu od rozpoczęcia pracy rekrutera do przedstawienia oferty”. Ułatwia to porównywanie sprawności i identyfikowanie dobrych praktyk. Dlaczego to ważne Umożliwia analizę wyników pracy poszczególnych rekruterów, identyfikację osób osiągających dobre wyniki, potrzeb szkoleniowych i nierównomiernego obciążenia pracą. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. Dane te są zwykle powiązane z obiektami Job Requisition lub Job Application. Przykłady Jan KowalskiAnna NowakMaria Garcia
	Menedżer rekrutujący HiringManager	Imię i nazwisko menedżera rekrutującego na stanowisko, o które ubiega się kandydat.
Opis Ten atrybut wskazuje menedżera zespołu lub działu, w którym jest wolne stanowisko. Menedżer rekrutujący uczestniczy w podejmowaniu decyzji, zwłaszcza podczas rozmów i przekazywania opinii. Dane te są niezbędne do utworzenia dashboardu „Terminowość opinii menedżerów rekrutujących”. Analizując czas między zakończeniem rozmowy a przesłaniem opinii dla poszczególnych menedżerów, można wykryć opóźnienia i współpracować z konkretnymi osobami, aby przyspieszyć rekrutację. Dlaczego to ważne Pomaga analizować zaangażowanie menedżerów rekrutujących i wykrywać opóźnienia w przekazywaniu opinii, które bezpośrednio wpływają na doświadczenia kandydatów. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. Dane te są zwykle częścią informacji o organizacji przełożonych lub zapotrzebowaniu na pracownika. Przykłady Katarzyna AdamskaDavid ChenAngela Rodriguez
	Status aplikacji ApplicationStatus	Końcowy wynik lub bieżący stan aplikacji na stanowisko.
Opis Ten atrybut określa końcowy wynik aplikacji, na przykład „Zatrudniony”, „Odrzucony przez firmę”, „Odrzucił ofertę” lub „Wycofał aplikację”. Oznacza stan końcowy procesu dla danej aplikacji. Status ten ma zasadnicze znaczenie przy analizie wyników. Służy do obliczania współczynników konwersji, akceptacji ofert i rezygnacji kandydatów na poszczególnych etapach. Zrozumienie, dlaczego i na jakim etapie kończą się aplikacje, pomaga poprawić skuteczność całego procesu. Dlaczego to ważne Określa wynik każdej sprawy, co pozwala obliczać współczynniki konwersji, rezygnacji i ogólną skuteczność procesu. Skąd pobrać Zwykle jest to pole określające końcowy wynik lub przyczynę statusu w obiekcie Job Application w Workday Recruiting. Przykłady ZatrudnionoOdrzuconyOferta odrzuconaWycofano aplikację
	Źródło aplikacji ApplicationSource	Kanał lub źródło, z którego wpłynęła aplikacja kandydata.
Opis Ten atrybut wskazuje, w jaki sposób kandydat dowiedział się o stanowisku i złożył aplikację, na przykład przez stronę kariery firmy, LinkedIn, polecenie pracownika lub agencję rekrutacyjną. Znajomość źródła jest niezbędna do optymalizacji strategii rekrutacyjnej i budżetu. Umożliwia utworzenie dashboardu „Skuteczność kanałów pozyskiwania kandydatów” i obliczanie KPI „Współczynnik przyjęcia ofert według źródła”. Dzięki temu można ustalić, które kanały dostarczają najwięcej kandydatów i kandydatów o najlepszych kwalifikacjach. Dlaczego to ważne Pomaga ocenić skuteczność różnych kanałów pozyskiwania kandydatów i podejmować decyzje oparte na danych dotyczące alokacji zasobów rekrutacyjnych. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. To standardowe pole w aplikacji na stanowisko. Przykłady LinkedInPolecenie pracownikaStrona kariery firmyIndeed
	Czas rekrutacji TimeToHire	Łączny czas od otrzymania aplikacji do zatrudnienia kandydata.
Opis To obliczenie na poziomie sprawy, które mierzy łączny czas rekrutacji zakończonej zatrudnieniem. Wynik to różnica między zdarzeniem „Otrzymano aplikację” a zdarzeniem „Zatrudniono kandydata”. Średni czas rekrutacji to jedno z najważniejszych KPI w rekrutacji. Pokazuje ogólną efektywność procesu od początku do końca. Śledzenie tego wskaźnika w czasie i w różnych działach pomaga wykrywać trwałą poprawę lub pogorszenie wyników. Dlaczego to ważne Ważny wskaźnik KPI, który pokazuje ogólną efektywność rekrutacji od początku do końca. Skąd pobrać Wartość oblicza się na podstawie danych z dziennika zdarzeń wyeksportowanych z Workday. Przykłady 259200043200003456000
	Czy aplikacja została wycofana IsWithdrawn	Flaga wskazująca, czy kandydat wycofał aplikację.
Opis To obliczany atrybut logiczny, który przyjmuje wartość prawda, jeśli końcowy status aplikacji to „Wycofał aplikację” lub podobny. Pozwala wyodrębnić sprawy, w których kandydat zrezygnował z udziału w procesie. Flaga ułatwia analizę w dashboardzie „Miejsca rezygnacji kandydatów” oraz obliczanie KPI „Współczynnik rezygnacji kandydatów”. Pozwala szybko filtrować i agregować dane, aby sprawdzić, na których etapach kandydaci najczęściej rezygnują. Dlaczego to ważne Pozwala osobno analizować rezygnacje kandydatów, co pomaga ocenić ich doświadczenia i wskazać utrudnienia w procesie. Skąd pobrać Wartość oblicza się podczas transformacji danych na podstawie atrybutu „ApplicationStatus”. Przykłady truefalse
	Czy wykonano automatycznie IsAutomated	Flaga wskazująca, czy system wykonał daną czynność automatycznie.
Opis Ten atrybut logiczny wskazuje, czy krok wykonał użytkownik, czy zautomatyzowany proces systemowy. Przykładem automatycznej czynności może być e-mail z potwierdzeniem otrzymania aplikacji. Wiedza o tym, które kroki są zautomatyzowane, pomaga znaleźć możliwości zwiększenia efektywności. Ułatwia też ocenę wpływu automatyzacji na czas trwania procesu i wykorzystanie zasobów. Dlaczego to ważne Rozróżnia czynności wykonywane ręcznie od tych realizowanych przez system. Pomaga wskazać możliwości automatyzacji i zmierzyć jej wpływ. Skąd pobrać Informację tę trzeba wywnioskować, identyfikując konta użytkowników systemowych lub typy zdarzeń, które w Workday są znane jako automatyczne. Przykłady truefalse
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego.
Opis Ten atrybut informuje, jak aktualne są analizowane dane. Pokazuje datę i godzinę ostatniego pobrania danych z Workday Recruiting. Dzięki temu użytkownicy wiedzą, jak aktualna jest analiza, i mogą właściwie interpretować wyniki, rozróżniając dane bieżące od migawki z określonego momentu. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu wiadomo, na ile bieżąca jest analiza procesu. Skąd pobrać Ten znacznik czasu jest generowany i dodawany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	Identyfikator kandydata CandidateId	Unikalny identyfikator kandydata.
Opis Identyfikator kandydata pozwala jednoznacznie rozpoznać osobę w systemie rekrutacyjnym, niezależnie od liczby stanowisk, na które aplikowała. Umożliwia śledzenie historii kontaktów kandydata z firmą w ramach wielu aplikacji. Ten atrybut przydaje się do analizy doświadczeń kandydatów w czasie. Można na przykład sprawdzić, czy osoby wcześniej odrzucone ponownie aplikują i jak przebiega ich kolejny proces, a także czy jeden kandydat jest równocześnie rozpatrywany na kilka stanowisk. Dlaczego to ważne Pozwala analizować proces z perspektywy kandydata, śledząc daną osobę w wielu aplikacjach i na przestrzeni czasu. Skąd pobrać To główny identyfikator obiektu Candidate w Workday Recruiting. Przykłady CAND-98765CAND-11223CAND-54321
	Identyfikator zapotrzebowania na pracownika JobRequisitionId	Unikalny identyfikator wakatu, na który kandydat złożył aplikację.
Opis Identyfikator zapotrzebowania na pracownika oznacza zatwierdzony wakat. Do jednego zapotrzebowania może być przypisanych wiele aplikacji. Ten atrybut pozwala analizować proces na poziomie zapotrzebowania. Można na przykład sprawdzić, jak długo wakat pozostawał otwarty, ilu kandydatów pozyskano albo porównać lejki rekrutacyjne dla różnych stanowisk, na przykład w inżynierii i sprzedaży. Dlaczego to ważne Łączy wiele aplikacji z jednym wakatem, dzięki czemu można analizować wskaźniki i lejki rekrutacyjne na poziomie zapotrzebowania. Skąd pobrać To główny identyfikator obiektu Job Requisition w Workday Recruiting. Jest powiązany z każdą aplikacją na stanowisko. Przykłady REQ-2023-105REQ-2024-012REQ-2024-345
	Kwota oferty OfferAmount	Wynagrodzenie zaproponowane kandydatowi.
Opis Ten atrybut zawiera proponowaną kandydatowi kwotę wynagrodzenia zasadniczego. To ważna informacja na końcowym etapie rekrutacji. Analiza kwot ofert pozwala ocenić trendy płacowe i konkurencyjność wynagrodzeń. W połączeniu ze statusem „Oferta zaakceptowana” może pomóc ustalić, czy wysokość wynagrodzenia wpływa na odrzucanie ofert. To jeden z elementów dashboardu „Zarządzanie ofertami i współczynnik akceptacji”. Dlaczego to ważne Pomaga analizować politykę wynagrodzeń i jej wpływ na akceptację ofert. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. Dane te powinny być częścią procesu biznesowego „Offer”. Przykłady 8500012000065000
	Lokalizacja stanowiska JobLocation	Miejsce lub kraj, w którym znajduje się stanowisko.
Opis Ten atrybut określa miasto, stan lub kraj, w którym znajduje się stanowisko. W przypadku pracy zdalnej może wskazywać region albo mieć wartość „Zdalnie”. Lokalizacja to przydatny wymiar analizy. Pozwala porównywać czas rekrutacji i inne KPI w różnych regionach. Dzięki temu można wykryć różnice wynikające z lokalnych warunków rynkowych, dostępności kandydatów lub sposobu prowadzenia rekrutacji. Dlaczego to ważne Umożliwia analizę geograficzną rekrutacji i wskazuje regionalne różnice w czasie trwania procesu oraz jego efektywności. Skąd pobrać Informacje te znajdują się w szczegółach Job Requisition w Workday. Przykłady Nowy Jork, NYLondyn, Wielka BrytaniaPraca zdalna (USA)Berlin, Niemcy
	Powód odrzucenia RejectionReason	Powód podany przy odrzuceniu aplikacji kandydata.
Opis Gdy aplikacja otrzymuje status „Odrzucony”, ten atrybut wyjaśnia podjętą decyzję. Powodem może być na przykład „Niedopasowanie do kultury firmy”, „Brak wymaganych umiejętności” lub „Stanowisko obsadzono innym kandydatem”. Analiza powodów odrzucenia pomaga wykrywać powtarzające się problemy w rekrutacji. Na przykład częste odrzucenia z powodu „Braku wymaganych umiejętności” na późnym etapie mogą wskazywać, że opis stanowiska jest nieprecyzyjny. Te dane pomagają zrozumieć przyczyny rezygnacji kandydatów w dashboardzie „Miejsca rezygnacji kandydatów”. Dlaczego to ważne Pokazuje, dlaczego kandydaci nie przechodzą do kolejnych etapów, co pomaga poprawić opisy stanowisk i kryteria selekcji. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. Często jest to podstatus lub kod przyczyny powiązany z etapem odrzucenia. Przykłady Brak kwalifikacjiNiedopasowane doświadczenieZnaleziono lepszych kandydatówStanowisko zamknięte
	System źródłowy SourceSystem	System, z którego pobrano dane.
Opis Ten atrybut wskazuje źródło danych, którym w tym przypadku jest Workday Recruiting. Ułatwia zarządzanie danymi i rozwiązywanie problemów, zwłaszcza gdy łączone są dane z wielu systemów. W analizie jednego systemu może wydawać się zbędny, ale warto zawsze go uwzględniać. Potwierdza pochodzenie danych i staje się niezbędny, gdy później zostaną zintegrowane inne systemy HR. Dlaczego to ważne Wskazuje pochodzenie danych, co ma znaczenie dla zarządzania nimi, ich weryfikacji i obsługi danych z wielu źródeł. Skąd pobrać To stała wartość („Workday Recruiting”) dodawana podczas ekstrakcji i przekształcania danych. Przykłady Workday Recruiting
	Typ kandydata CandidateType	Informuje, czy kandydat jest pracownikiem firmy, czy osobą z zewnątrz.
Opis Ten atrybut dzieli kandydatów na grupy, takie jak „Wewnętrzny” i „Zewnętrzny”. Proces rekrutacji, jego czas i zasady mogą się znacznie różnić w zależności od grupy. Osobna analiza kandydatów wewnętrznych i zewnętrznych pozwala uzyskać pełniejszy obraz. Umożliwia porównanie efektywności programów mobilności wewnętrznej z rekrutacją zewnętrzną oraz usprawnienie obu procesów. Dlaczego to ważne Pozwala osobno analizować rekrutację wewnętrzną i zewnętrzną, które często różnią się etapami, SLA i celami. Skąd pobrać Należy sprawdzić dokumentację Workday Recruiting. To standardowe pole w profilu kandydata lub aplikacji na stanowisko. Przykłady WewnętrznyZewnętrzny

Wymagane Zalecane Opcjonalne

Czynności związane z rekrutacją i pozyskiwaniem talentów

To najważniejsze kroki i etapy procesu, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu i wskazywać wąskie gardła w rekrutacji.

7 Zalecane 8 Opcjonalne

	Działanie	Opis
	Kandydat przeniesiony do etapu oferty	Ważny etap oznaczający decyzję o przedstawieniu kandydatowi oferty pracy. Zdarzenie jest rejestrowane, gdy aplikacja kandydata przechodzi do etapu „Offer” w procesie rekrutacji.
Dlaczego to ważne Ta czynność jest ważnym punktem kontrolnym procesu i oznacza pomyślne zakończenie wszystkich etapów oceny. Poprzedza formalne przedstawienie oferty i stanowi istotny punkt analizy kohortowej. Skąd pobrać Wnioskowane na podstawie ścieżki audytu aplikacji, a konkretnie znacznika czasu zmiany statusu kandydata na „Offer”. Rejestrowanie Rozpoznawane na podstawie zmiany statusu kandydata na etap „Offer”. Typ zdarzenia inferred
	Kandydat skierowany na rozmowę	Oznacza, że kandydat przeszedł wstępną selekcję i może wziąć udział w rozmowie. Zdarzenie jest rejestrowane, gdy rekruter przenosi kandydata do etapu „Interview” w procesie rekrutacji.
Dlaczego to ważne Ten etap oznacza przejście od selekcji wstępnej do aktywnej oceny kandydata. Jest ważnym punktem analizy współczynników konwersji i sprawności początkowych etapów lejka rekrutacyjnego. Skąd pobrać Wnioskowane na podstawie znacznika czasu zmiany etapu rekrutacji kandydata na „Interview” lub podobnie nazwany etap w historii aplikacji. Rejestrowanie Rozpoznawane na podstawie zmiany statusu kandydata na etap „Interview”. Typ zdarzenia inferred
	Odrzucono kandydata	Oznacza niepowodzenie procesu, w którym firma decyduje, że nie będzie kontynuować rekrutacji danego kandydata. Wnioskuje się o tym, gdy rekruter zmienia status kandydata na „Rejected” lub „Not Hired”.
Dlaczego to ważne To ważne zdarzenie kończące proces, które pozwala analizować etapy, na których kandydaci najczęściej rezygnują, oraz wskaźniki odrzuceń. Pomaga wykrywać problemy w selekcji lub rozmowach. Skąd pobrać Wnioskowane na podstawie znacznika czasu zmiany statusu kandydata na „Rejected” w historii aplikacji. Często zapisywany jest również powód odrzucenia. Rejestrowanie Ustalane na podstawie znacznika czasu wejścia w życie zmiany statusu na „Rejected”. Typ zdarzenia inferred
	Otrzymano aplikację	Oznacza rozpoczęcie procesu rekrutacji kandydata na dane stanowisko. Zdarzenie jest rejestrowane, gdy kandydat pomyślnie przesyła aplikację na konkretne zapotrzebowanie na pracownika przez portal Workday lub zintegrowaną stronę kariery.
Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza czasu od tej czynności do kolejnych etapów jest podstawą pomiaru całkowitego czasu rekrutacji i skuteczności kanałów pozyskiwania kandydatów. Skąd pobrać Workday rejestruje to jako jawne zdarzenie po pomyślnym zakończeniu procesu biznesowego „Apply for Job” dla kandydata. Znacznik czasu zdarzenia jest dostępny w historii aplikacji kandydata. Rejestrowanie Pobierane ze znacznika czasu przesłania aplikacji w profilu kandydata. Typ zdarzenia explicit
	Przedstawiono ofertę	Oznacza formalne przedstawienie kandydatowi oferty pracy. Jest to odrębne zdarzenie rejestrowane po pomyślnym zakończeniu procesu biznesowego „Create Offer” lub „Propose Compensation” dla aplikacji w Workday.
Dlaczego to ważne To ważny etap służący do obliczania czasu do przedstawienia oferty i analizy zgodności przebiegu procesu ofertowego. Od tego momentu mierzy się współczynnik przyjęcia ofert. Skąd pobrać To zdarzenie jest jawnie rejestrowane w historii procesu biznesowego aplikacji. Czas czynności określa znacznik czasu zakończenia etapu tworzenia oferty. Rejestrowanie Pobierane ze znacznika czasu zakończenia procesu biznesowego „Create Offer”. Typ zdarzenia explicit
	Przyjęto ofertę	Oznacza formalne przyjęcie oferty pracy przez kandydata. Zdarzenie jest rejestrowane, gdy kandydat wykonuje zadanie „Accept Offer” w portalu Workday albo gdy rekruter ręcznie aktualizuje status.
Dlaczego to ważne Ta czynność ma zasadnicze znaczenie przy obliczaniu współczynnika przyjęcia ofert według źródła, działu lub rekrutera. Uruchamia również kolejne działania przed zatrudnieniem, takie jak weryfikacja kandydata. Skąd pobrać Rejestrowane jawnie, gdy kandydat przyjmuje ofertę w portalu. Czynność wraz ze znacznikiem czasu jest zapisywana w historii procesu biznesowego aplikacji. Rejestrowanie Pobierane ze znacznika czasu zakończenia zadania „Accept Offer”. Typ zdarzenia explicit
	Zatrudniono kandydata	Pomyślne zakończenie procesu rekrutacji, w którym kandydat zostaje formalnie zatrudniony. Zdarzenie jest rejestrowane po pomyślnym zakończeniu procesu biznesowego „Hire” w Workday i utworzeniu rekordu pracownika.
Dlaczego to ważne To główne zdarzenie kończące proces sukcesem. Znacznik czasu jest niezbędny do obliczenia czasu rekrutacji oraz oceny ogólnej sprawności procesu i współczynnika powodzenia. Skąd pobrać To ważne, jawnie rejestrowane zdarzenie procesu biznesowego „Hire” w Workday HCM. Znacznik czasu zakończenia jest zapisywany w historii procesu. Rejestrowanie Pobierane ze znacznika czasu zakończenia procesu biznesowego „Hire” dla kandydata. Typ zdarzenia explicit
	Przeprowadzono rozmowę	Oznacza zakończenie zaplanowanej rozmowy z kandydatem. Zwykle wnioskuje się o tym na podstawie zmiany statusu rozmowy z „Scheduled” na „Completed” lub „Conducted” przez osobę prowadzącą rozmowę albo rekrutera.
Dlaczego to ważne Ta czynność rozpoczyna okres na przekazanie opinii. Analiza czasu od tego momentu do przesłania opinii pozwala ocenić, jak szybko menedżerowie rekrutujący przekazują informacje zwrotne. Skąd pobrać Wnioskowane na podstawie zmiany statusu zaplanowanej rozmowy lub ręcznej zmiany etapu kandydata w Workday Recruiting po odbyciu rozmowy. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany statusu rozmowy lub etapu kandydata po rozmowie. Typ zdarzenia inferred
	Przesłano opinię	Oznacza moment, w którym osoba prowadząca rozmowę formalnie przesyła ocenę kandydata po spotkaniu. Workday udostępnia funkcję pozwalającą bezpośrednio dodać opinię do profilu kandydata.
Dlaczego to ważne Ta informacja jest niezbędna do analizy terminowości opinii menedżerów rekrutujących. Opóźnienia na tym etapie często tworzą wąskie gardło. Śledzenie czasu pomaga egzekwować uzgodnione poziomy usług. Skąd pobrać To jawne zdarzenie rejestrowane po przesłaniu opinii za pomocą zadania „Provide Interview Feedback”. Znacznik czasu przesłania jest zapisywany w rekordzie rozmowy. Rejestrowanie Pobierane ze znacznika czasu zakończenia zdarzenia „Provide Interview Feedback”. Typ zdarzenia explicit
	Rozpoczęto wdrożenie nowego pracownika	Oznacza rozpoczęcie procesu wdrożenia nowego pracownika w Workday. Zwykle jest to jawne zdarzenie w ramach głównego procesu biznesowego „Hire” lub zdarzenie uruchamiane bezpośrednio po jego zakończeniu.
Dlaczego to ważne Analiza czasu od przyjęcia oferty do tej czynności pomaga usprawnić doświadczenia kandydata po otrzymaniu oferty. Pozwala zadbać o zaangażowanie nowych pracowników i ich przygotowanie do pierwszego dnia pracy. Skąd pobrać Proces biznesowy „Onboarding” w Workday ma wyraźnie określony znacznik czasu rozpoczęcia. Można go pobrać ze ścieżki audytu procesu dla rekordu nowego pracownika. Rejestrowanie Pobierane ze znacznika czasu rozpoczęcia procesu biznesowego „Onboarding”. Typ zdarzenia explicit
	Rozpoczęto weryfikację kandydata	Oznacza rozpoczęcie weryfikacji kandydata, który przyjął ofertę. Zwykle wnioskuje się o tym na podstawie przeniesienia kandydata do etapu „Background Check”, co często uruchamia integrację z zewnętrznym dostawcą usług.
Dlaczego to ważne Ta czynność jest niezbędna do monitorowania zgodności i analizy opóźnień między przyjęciem oferty a rozpoczęciem weryfikacji przed zatrudnieniem. Pomaga zapewnić płynne przejście do wdrożenia nowego pracownika. Skąd pobrać Wnioskowane na podstawie znacznika czasu przeniesienia kandydata do etapu „Background Check” w przebiegu rekrutacji. Ścieżka audytu aplikacji pokazuje tę zmianę statusu. Rejestrowanie Ustalane na podstawie znacznika czasu wejścia w życie przeniesienia do etapu „Background Check”. Typ zdarzenia inferred
	Wstępnie oceniono aplikację	Oznacza zakończenie wstępnej oceny aplikacji kandydata przez rekrutera lub zespół selekcyjny. Zwykle wnioskuje się o tym na podstawie zmiany statusu kandydata z „Applied” lub „New” na „Screening” albo „Under Review”.
Dlaczego to ważne Ta czynność ma zasadnicze znaczenie dla analizy sprawności wstępnej selekcji. Śledzenie liczby i czasu obsługi aplikacji pomaga wcześnie wykryć wąskie gardła w lejku rekrutacyjnym. Skąd pobrać Wnioskowane na podstawie daty wejścia w życie zmiany etapu kandydata na etap selekcji lub weryfikacji w ścieżce audytu procesu biznesowego „Recruiting”. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany etapu kandydata na „Screen”. Typ zdarzenia inferred
	Wycofano aplikację	Zdarzenie kończące proces, w którym kandydat dobrowolnie rezygnuje z ubiegania się o stanowisko. Jest rejestrowane, gdy kandydat lub rekruter zmienia status na „Withdrawn”.
Dlaczego to ważne Śledzenie tego, kiedy i dlaczego kandydaci rezygnują, pomaga zrozumieć problemy związane z ich doświadczeniami, długością procesu lub atrakcyjnością ofert. To ważny wskaźnik w analizie rezygnacji. Skąd pobrać Wnioskowane na podstawie znacznika czasu zmiany statusu kandydata na „Withdrawn”. Zmiany może dokonać kandydat w portalu lub rekruter. Rejestrowanie Ustalane na podstawie znacznika czasu wejścia w życie zmiany statusu na „Withdrawn”. Typ zdarzenia inferred
	Zakończono weryfikację kandydata	Oznacza pomyślne zakończenie weryfikacji kandydata. Zdarzenie jest wnioskowane na podstawie aktualizacji statusu potwierdzającej, że kandydat przeszedł wymagane kontrole i może zostać zatrudniony.
Dlaczego to ważne To ostatni punkt kontrolny przed zakończeniem procesu zatrudnienia. Opóźnienia w otrzymaniu i zarejestrowaniu potwierdzenia mogą przesunąć datę rozpoczęcia pracy przez kandydata. Skąd pobrać Wnioskowane na podstawie aktualizacji statusu aplikacji kandydata, na przykład przeniesienia do etapu „Ready for Hire” lub „Background Check Complete”. Rejestrowanie Ustalane na podstawie zmiany statusu potwierdzającej zakończenie weryfikacji z wynikiem pozytywnym. Typ zdarzenia inferred
	Zaplanowano rozmowę	Oznacza formalne zaplanowanie rozmowy z kandydatem. Zwykle zdarzenie jest rejestrowane po utworzeniu i potwierdzeniu spotkania w funkcji planowania Workday dla danej aplikacji.
Dlaczego to ważne Pomiar czasu między tą czynnością a poprzednimi etapami pomaga wykryć opóźnienia w koordynacji. Ma to duże znaczenie dla poprawy doświadczeń kandydatów i przyspieszenia rozmów. Skąd pobrać Funkcja planowania rozmów w Workday tworzy zdarzenia ze znacznikami czasu. Czynność można zarejestrować na podstawie daty utworzenia zaplanowanej rozmowy powiązanej z aplikacją. Rejestrowanie Pobierane ze zdarzenia utworzenia rekordu rozmowy w module rekrutacyjnym. Typ zdarzenia explicit

Zalecane Opcjonalne

Instrukcje wyodrębniania danych

Jak pobrać dane z Workday Recruiting

Kroki

Zaloguj się do Workday: Zaloguj się do swojego środowiska Workday na konto użytkownika z uprawnieniami do tworzenia raportów niestandardowych i dostępu do danych rekrutacyjnych.
Utwórz raport niestandardowy: Otwórz zadanie „Create Custom Report”. Jako typ raportu wybierz „Advanced” i zaznacz opcję „Enable as Web Service”. Jako źródło danych wybierz indeksowane źródło, na przykład „All Job Applications”, aby raport działał wydajniej.
Określ główny obiekt biznesowy: Jako główny obiekt biznesowy ustaw „Job Application”. Będzie on podstawą raportu i identyfikatorem sprawy.
Dodaj kolumny danych: Dodaj wymagane i zalecane pola do siatki kolumn raportu. Dodaj „Job Application” dla JobApplicationId. Pozostałe atrybuty, takie jak „Recruiter” i „Hiring Manager”, trzeba dodać z powiązanych obiektów biznesowych.
Utwórz pola obliczeniowe dla aktywności: To najważniejszy etap. Dla każdej z 15 aktywności utwórz dwa pola obliczeniowe: jedno dla nazwy aktywności, a drugie dla znacznika czasu zdarzenia. Logikę tych pól opisano w sekcji zapytania. Na przykład, aby zarejestrować „Offer Extended”, utwórz pole sprawdzające, czy zakończono proces biznesowy „Propose Compensation”, oraz drugie pole pobierające znacznik czasu jego zakończenia.
Dodaj pola obliczeniowe do raportu: Dodaj wszystkie utworzone pola obliczeniowe, łącznie 30: 15 nazw aktywności i 15 znaczników czasu. Raport będzie miał format szeroki: jeden wiersz na zgłoszenie i wiele kolumn odpowiadających możliwym aktywnościom.
Skonfiguruj usługę sieciową: Na karcie „Web Service” w definicji raportu zaznacz pole „Enable as Web Service”. W tym miejscu można sprawdzić przestrzeń nazw i adres URL raportu. Zapisz wartość „Namespace”, będzie potrzebna później.
Ustaw uprawnienia: Udostępnij raport użytkownikowi Integration System User (ISU) lub określonej grupie zabezpieczeń, która będzie wywoływać punkt końcowy RaaS. Konto musi mieć uprawnienia do domeny źródła danych, na przykład „Recruiting: Job Applications”.
Uruchom i przetestuj raport: Uruchom raport w interfejsie Workday i sprawdź wyniki. Upewnij się, że liczba wierszy jest odpowiednia, a pola obliczeniowe poprawnie wypełniają się dla kilku przykładowych zgłoszeń.
Zaplanuj eksport: Użyj zewnętrznego narzędzia do planowania zadań lub oprogramowania pośredniczącego, takiego jak MuleSoft, Boomi albo własny skrypt, aby regularnie wywoływać adres URL RaaS raportu. Narzędzie musi obsługiwać wywołania Workday SOAP lub REST API z odpowiednim uwierzytelnianiem.
Przekształć dane: Surowe dane zwrócone przez RaaS będą szerokim plikiem XML lub CSV. W oprogramowaniu pośredniczącym lub skrypcie, na przykład w Pythonie, trzeba przekształcić dane do formatu długiego. Skrypt powinien przejść przez każdy wiersz, czyli każde zgłoszenie, i utworzyć w dzienniku zdarzeń nowy wiersz dla każdej niepustej pary aktywność/znacznik czasu. Wynik powinien zawierać trzy główne kolumny: JobApplicationId, ActivityName i EventTime.

Konfiguracja

Typ raportu: Zawsze wybieraj „Advanced”, aby móc używać złożonych pól obliczeniowych i uzyskać dostęp do powiązanych obiektów biznesowych.
Źródło danych: Wybierz indeksowane źródło danych, na przykład „All Job Applications”, aby raport działał wydajnie. Przy dużych zbiorach unikaj źródeł bez indeksu.
Filtrowanie zakresu dat: Koniecznie ustaw filtr na polu „Application Date” obiektu biznesowego Job Application. Na początek wybierz krótszy okres, na przykład ostatnie 3–6 miesięcy, aby ograniczyć ilość danych i skrócić czas generowania raportu.
Główny obiekt biznesowy: Głównym obiektem musi być „Job Application”, aby JobApplicationId pełnił funkcję identyfikatora sprawy.
Udostępnienie jako usługi sieciowej: W konfiguracji raportu zaznacz opcję „Enable as Web Service”, aby udostępnić go przez API.
Zabezpieczenia i uprawnienia: Raport musi być udostępniony dedykowanemu użytkownikowi Integration System User (ISU). Konto ISU musi należeć do grup zabezpieczeń z dostępem do wymaganych domen danych, w tym „Recruiting: Job Applications”, „Business Process Transactions” i „Worker Data”.
Format wyjściowy: Workday oferuje kilka formatów wyjściowych, w tym XML, CSV i JSON. XML, a konkretnie format „Simple XML”, jest często najbardziej niezawodny przy pobieraniu uporządkowanych danych przez API.

Przykładowe zapytanie 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.

Kroki

Skonfiguruj dostęp do Workday: Utwórz w Workday użytkownika Integration System User (ISU). Przyznaj mu dostęp do wymaganych domen zabezpieczeń Recruiting API. Najważniejsze domeny to „Worker Data: Public Worker Reports”, „Job Application” i „Recruiting: Reports”.
Znajdź punkt końcowy API: W swoim środowisku Workday znajdź punkt końcowy REST API dla operacji „Get Job Applications”. Adres URL ma zwykle format: https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications.
Przygotuj środowisko Python: Upewnij się, że Python jest zainstalowany. Zainstaluj wymagane biblioteki za pomocą pip: pip install requests pandas.
Przygotuj skrypt uwierzytelniający: W skrypcie Python zaimplementuj uwierzytelnianie podstawowe, używając danych logowania użytkownika ISU utworzonego w kroku 1. Nazwa użytkownika i hasło będą przesyłane w nagłówku żądania.
Zaimplementuj wywołanie API: Napisz funkcję wywołującą punkt końcowy „Get Job Applications”. Użyj parametrów żądania do filtrowania danych, na przykład updatedSince, aby pobierać zgłoszenia zmodyfikowane po określonej dacie. To ważne, aby kontrolować ilość danych.
Obsłuż stronicowanie API: Workday API zwraca ograniczoną liczbę rekordów w jednym żądaniu. Skrypt musi sprawdzać, czy odpowiedź zawiera łączną liczbę rekordów total oraz odnośnik do następnej strony lub parametr przesunięcia. Następnie powinien pobrać kolejne strony, aż do uzyskania pełnego zbioru danych.
Zdefiniuj mapowanie aktywności: Utwórz słownik mapowań lub serię instrukcji warunkowych w skrypcie. Ta logika przełoży statusy procesów biznesowych i etapy rekrutacji w Workday, na przykład „Screen”, „Interview”, „Offer” i „Hire”, na wymagane nazwy aktywności, takie jak „Application Screened” i „Candidate Moved To Interview”.
Przekształć dane zgłoszeń: Dla każdego zgłoszenia pobranego przez API przeanalizuj historię audytu lub historię etapów. Zawiera ona kolejność etapów, decyzje oraz zdarzenia procesów biznesowych wraz z odpowiadającymi im znacznikami czasu.
Utwórz wiersze dziennika zdarzeń: Przejdź przez historię każdego zgłoszenia. Dla każdego istotnego zdarzenia historycznego zgodnego z mapowaniem aktywności utwórz słownik opisujący wiersz w docelowym dzienniku zdarzeń. Wypełnij pola JobApplicationId, ActivityName, EventTime i pozostałe wymagane atrybuty.
Zbierz i uporządkuj dane: Umieść wszystkie utworzone wiersze dziennika zdarzeń ze wszystkich zgłoszeń na jednej liście.
Utwórz i wyeksportuj plik CSV: Za pomocą biblioteki pandas przekształć listę słowników zdarzeń w obiekt DataFrame, a następnie wyeksportuj go do pliku CSV. Nagłówki kolumn muszą odpowiadać wymaganiom ProcessMind, na przykład CaseId, Activity i Timestamp.
Sprawdź i prześlij plik: Otwórz końcowy plik CSV i sprawdź, czy dane są poprawne i kompletne, zanim prześlesz go do narzędzia process mining.

Konfiguracja

Użytkownik Workday Integration System User (ISU): Wymagane jest konto ISU z silnym, niewygasającym hasłem. Musi mieć uprawnienia do domen zabezpieczeń „Recruiting” i „Worker Data”, aby uzyskać dostęp do danych zgłoszeń i kandydatów.
Punkt końcowy i wersja API: Należy użyć właściwego punktu końcowego REST API dla danego środowiska Workday. W żądaniu trzeba określić wersję API, aby zapewnić spójne działanie.
Filtr zakresu dat: Skrypt powinien używać filtra dat, na przykład updatedSince, aby ograniczyć zapytanie do możliwego do obsłużenia okresu. Przy pierwszym pobieraniu zaleca się zakres 3–6 miesięcy. Przy kolejnych pobraniach przyrostowych należy używać znacznika czasu ostatniego udanego pobrania.
Limit stronicowania: Należy uwzględnić parametr API limit, który określa liczbę rekordów zwracanych na stronie. Typowy limit maksymalny wynosi 100. Skrypt musi obsługiwać go przez wysyłanie kolejnych żądań dla następnych stron.
Pola odpowiedzi: Aby przyspieszyć działanie, można określić zwracane pola za pomocą parametru fields lub podobnego, jeśli API go obsługuje. Ogranicza to rozmiar odpowiedzi API.
Konfiguracja mapowania aktywności: Główna część logiki skryptu odpowiada za mapowanie etapów Workday na zdefiniowane aktywności. Może być konieczne dostosowanie go do konfiguracji procesu rekrutacji Workday w danej organizacji.

Przykładowe zapytanie 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.")

Kroki

Wymagania wstępne i konfiguracja: Przygotuj licencjonowane narzędzie ETL lub iPaaS innego dostawcy, na przykład CData, MuleSoft lub podobną platformę, z zainstalowanym konektorem Workday. Upewnij się, że masz dane logowania użytkownika Workday Integration System User (ISU) z wymaganymi uprawnieniami API do domen Recruiting i Staffing.
Skonfiguruj połączenie z Workday: W narzędziu ETL utwórz nowe połączenie z Workday. Podaj adres URL środowiska Workday, wersję API i dane logowania ISU, na przykład nazwę użytkownika i hasło lub tokeny OAuth 2.0. Przetestuj połączenie.
Sprawdź schemat danych: Użyj przeglądarki schematów lub eksploratora źródeł danych w narzędziu ETL, aby sprawdzić obiekty Workday dostępne przez konektor. Zwykle są przedstawione jako tabele lub widoki, na przykład Job_Application, Job_Requisition i Candidate_Stage_History. Zapoznaj się z dostępnymi polami i relacjami.
Wskaż najważniejsze obiekty danych: Do tego eksportu potrzebne będą przede wszystkim dane dotyczące zgłoszeń, historii kandydatów, rozmów kwalifikacyjnych, ofert i zatrudnień. Dokładne nazwy zależą od konektora. Znajdź obiekty odpowiadające tym głównym elementom.
Przygotuj zapytanie SQL: Utwórz zadanie lub potok pobierania danych. Dodaj krok transformacji SQL, który uruchomi zapytanie na połączeniu z Workday. Wklej w nim podane zapytanie SQL. Zostało przygotowane tak, aby pobierać dane z wielu obiektów Workday i łączyć je w jeden dziennik zdarzeń.
Dodaj parametry do zapytania: Zmodyfikuj klauzulę WHERE, dodając parametry zakresu dat, na przykład startDate i endDate. Skonfiguruj je w zadaniu ETL, aby można było zmieniać zakres pobierania bez modyfikowania kodu.
Uruchom zadanie pobierania danych: Uruchom skonfigurowane zadanie ETL. Narzędzie połączy się z Workday, wykona zapytanie SQL przez API i pobierze dane do obszaru tymczasowego lub pamięci.
Sprawdź i zweryfikuj dane: Przed zapisaniem wyników użyj funkcji podglądu w narzędziu ETL. Sprawdź, czy liczba wierszy jest odpowiednia, wszystkie kolumny są wypełnione zgodnie z oczekiwaniami i występują różne aktywności.
Skonfiguruj miejsce docelowe: Określ miejsce zapisu pobranych danych. Zwykle będzie to plik CSV do przesłania do ProcessMind. Ustaw nazwę pliku, separator (przecinek) i kodowanie (UTF-8).
Zakończ eksport: Uruchom pełne zadanie pobierania danych, aby utworzyć końcowy plik CSV. Nagłówki kolumn muszą odpowiadać wymaganym atrybutom: JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Department i ApplicationStatus.

Konfiguracja

Dane logowania do konektora Workday: Do połączenia potrzebny jest adres URL środowiska Workday oraz autoryzowany użytkownik Integration System User (ISU) z hasłem lub danymi klienta OAuth 2.0. Konto musi mieć uprawnienia zabezpieczeń do obszarów funkcjonalnych „Recruiting” i „Staffing”.
Udostępnienie usług sieciowych: Konektor może wymagać wskazania usług Workday Web Services, które mają być udostępnione. Włącz usługi związane z Recruiting, Staffing i Human Resources, aby uzyskać dostęp do wszystkich wymaganych obiektów danych.
Zakres dat: Aby kontrolować wydajność i ilość danych, należy ograniczyć pobieranie do określonego okresu. Zalecamy początkowe pobranie danych z 3–6 miesięcy, a następnie codzienne lub cotygodniowe pobieranie przyrostowe. Zakres ustawia się w klauzuli WHERE zapytania SQL.
Filtry zakresu danych: Jeśli analiza ma obejmować tylko część organizacji, można dodać do klauzuli WHERE filtry pól takich jak Company, Cost Center lub Supervisory Organization.
Wersja API: Niektóre konektory wymagają wskazania wersji Workday API. Najlepiej użyć aktualnej, obsługiwanej wersji, aby uzyskać dostęp do najnowszych obiektów danych i funkcji.
Wydajność: Pełne pobieranie danych z Workday może wymagać dużych zasobów. Duże zadania należy planować poza godzinami szczytu. Przy regularnej analizie warto wdrożyć pobieranie przyrostowe na podstawie znacznika czasu ostatniej modyfikacji, aby pobierać tylko nowe lub zmienione rekordy.

Przykładowe zapytanie 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]'

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przekształcić dane dotyczące pozyskiwania talentów w praktyczne wnioski i usprawnić rekrutację. Już dziś rozpocznij pracę nad sprawniejszym i skuteczniejszym procesem rekrutacyjnym.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usuń wąskie gardła w rekrutacji i usprawnij pozyskiwanie talentów

Wskaż nieefektywne etapy, skróć cykl rekrutacji o 30% i szybciej realizuj cele związane z pozyskiwaniem talentów.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Okres próbny trwa 14 dni.

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Atrybuty rekrutacji i pozyskiwania talentów

Czynności związane z rekrutacją i pozyskiwaniem talentów

Instrukcje wyodrębniania danych

Eksport danych z Workday Report-as-a-Service (RaaS)

Kroki

Konfiguracja

Przykładowe zapytanie sql

Pobieranie danych z Workday Recruiting API za pomocą skryptu Python

Kroki

Konfiguracja

Przykładowe zapytanie python

Pobieranie danych za pomocą narzędzia ETL z konektorem Workday

Kroki

Konfiguracja

Przykładowe zapytanie sql

Gotowi do rozpoczęcia?

Usuń wąskie gardła w rekrutacji i usprawnij pozyskiwanie talentów