> Miglioramento continuo dei processi > Selezione e acquisizione dei talenti > Workday Recruiting > Template dei dati

Il Suo template dei dati per la selezione e l’acquisizione dei talenti

Workday Recruiting

Attributi per la selezione e l’acquisizione dei talenti(19) Attività di selezione e acquisizione dei talenti(15) Guide all’estrazione(3)

Il Suo template dei dati per la selezione e l’acquisizione dei talenti

Questo template offre indicazioni complete sulla raccolta dei dati necessari per analizzare i processi di selezione e acquisizione dei talenti. Illustra quali attributi raccogliere e quali attività monitorare, oltre a spiegare come estrarre i dati dal sistema Workday Recruiting. Utilizzi questa risorsa per semplificare la preparazione dei dati e avviare più rapidamente il percorso di Process Mining.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione dei dati da Workday Recruiting

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi per la selezione e l’acquisizione dei talenti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo la selezione e l’acquisizione dei talenti e ottenere indicazioni approfondite sul processo di assunzione.

3 Obbligatorio 5 Consigliato 11 Facoltativo

	Nome	Descrizione
	Candidatura per una posizione JobApplicationId	Identificativo univoco della candidatura di una persona, utilizzato come ID del caso principale per il processo di selezione.
Descrizione L’ID della candidatura identifica in modo univoco il percorso di una persona per una specifica richiesta di assunzione, dall’invio iniziale alla decisione finale. Ogni interazione, modifica di stato o decisione relativa alla candidatura è associata a questo identificativo. Nel Process Mining, questo attributo è fondamentale: consente di ricostruire il processo seguito da ciascun candidato dall’inizio alla fine e di analizzare i tempi di ciclo, i colli di bottiglia e i percorsi intrapresi. È l’elemento centrale che collega tutte le attività correlate in un unico caso. Perché è importante È l’ID del caso essenziale che collega tutte le attività di selezione relative a un singolo candidato e permette di analizzare l’intero percorso di assunzione. Dove reperirli Questo identificativo è un elemento fondamentale di Workday Recruiting ed è in genere disponibile nei report e nelle origini dei dati relativi alle candidature. Esempi APP-2023-001234APP-2023-005678APP-2024-009101
	Data e ora dell’evento EventTime	La data e l’ora che indicano quando si è verificata l’attività o l’evento.
Descrizione Questo attributo registra la data e l’ora esatte in cui si è svolta una specifica attività di selezione. Le date e le ore costituiscono la base del Process Mining, perché definiscono l’ordine cronologico degli eventi. Nell’analisi, vengono utilizzate per calcolare la durata tra le attività, misurare i tempi di ciclo complessivi, come il tempo di assunzione, e individuare i colli di bottiglia che causano ritardi nel processo. Sono indispensabili per qualsiasi analisi temporale del processo di selezione. Perché è importante Le date e le ore sono essenziali per calcolare tutti i KPI temporali, comprendere la durata del processo e individuare i colli di bottiglia. Dove reperirli Corrisponde alla data di completamento o alla data della transazione di una fase del processo aziendale in Workday Recruiting. Esempi 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	Nome dell’attività ActivityName	Il nome dell’evento o dell’attività specifica che si è verificata in un determinato momento del processo di selezione.
Descrizione Il nome dell’attività descrive un singolo passaggio o una tappa del percorso di assunzione, ad esempio «Candidatura esaminata», «Colloquio pianificato» o «Offerta presentata». Queste attività compongono la sequenza di eventi che costituisce il processo. Questo attributo è fondamentale per visualizzare la mappa del processo, individuare i diversi percorsi delle candidature e analizzare la frequenza e l’ordine degli eventi. È la base per capire che cosa accade nel processo. Perché è importante Questo attributo definisce i passaggi del processo di selezione e ne consente la visualizzazione e l’analisi. Dove reperirli Ricavato dai nomi delle fasi dei processi aziendali o dalle modifiche di stato nei dati delle candidature di Workday Recruiting. Esempi Candidatura esaminataColloquio completatoOfferta accettataCandidato non selezionato
	Fonte della candidatura ApplicationSource	Il canale o la fonte da cui è pervenuta la candidatura.
Descrizione Questo attributo indica come il candidato ha scoperto la posizione e ha inviato la candidatura, ad esempio tramite la pagina delle opportunità di lavoro dell’azienda, LinkedIn, una segnalazione di un dipendente o un’agenzia di selezione. Conoscere la fonte è fondamentale per ottimizzare la strategia e il budget di selezione. Questo dato alimenta la Dashboard «Efficacia dei canali di ricerca dei candidati» e il KPI «Tasso di accettazione delle offerte per fonte», aiutando a capire quali canali generano il maggior numero di candidati e quelli più qualificati. Perché è importante Aiuta a valutare l’efficacia dei diversi canali di ricerca dei candidati e a decidere, sulla base dei dati, dove investire le risorse dedicate alla selezione. Dove reperirli Consultare la documentazione di Workday Recruiting. È un campo standard della candidatura. Esempi LinkedInSegnalazione di un dipendenteSito aziendale dedicato alle opportunità di lavoroIndeed
	Nome del selezionatore RecruiterName	Il nome del selezionatore responsabile della gestione della candidatura.
Descrizione Questo attributo identifica il referente principale per l’acquisizione dei talenti o il selezionatore assegnato alla candidatura e alla richiesta di assunzione. In genere, questa persona accompagna il candidato durante il processo. Analizzare il processo per selezionatore è fondamentale per comprendere il carico di lavoro e i risultati del team. Consente di creare la Dashboard «Risultati e volume di attività dei selezionatori» e calcolare KPI come «Scostamento dei tempi per formulare un’offerta per selezionatore», confrontando l’efficienza e individuando le prassi più efficaci. Perché è importante Consente di analizzare i risultati per selezionatore, individuando chi ottiene i risultati migliori, le esigenze di formazione e gli squilibri nel carico di lavoro. Dove reperirli Consultare la documentazione di Workday Recruiting. In genere, questo dato è collegato agli oggetti Job Requisition o Job Application. Esempi John SmithEmily JonesMaria Garcia
	Reparto Department	Il reparto o l’unità aziendale associati alla richiesta di assunzione.
Descrizione Questo attributo specifica l’unità organizzativa, ad esempio «Ingegneria», «Marketing» o «Finanza», per la quale si sta assumendo il candidato. Il dato deriva dall’organizzazione gerarchica associata alla richiesta di assunzione. Nell’analisi, filtrare per reparto consente di confrontare i processi di selezione nelle diverse aree aziendali. La Dashboard «Efficienza della selezione iniziale delle candidature» utilizza questo dato per verificare se alcuni reparti impiegano più tempo nella selezione iniziale, un possibile segnale di prassi diverse o di esigenze specifiche in termini di risorse. Perché è importante Consente di confrontare i risultati e l’efficienza dei processi di selezione tra diverse unità aziendali o reparti. Dove reperirli Consultare la documentazione di Workday Recruiting. Il dato deriva dall’organizzazione gerarchica associata alla richiesta di assunzione. Esempi IngegneriaVenditeRisorse umaneFinanza
	Responsabile delle assunzioni HiringManager	Il nome del responsabile delle assunzioni per la posizione a cui il candidato si è presentato.
Descrizione Questo attributo identifica il responsabile del team o del reparto con una posizione aperta. Il responsabile delle assunzioni è una figura chiave nel processo decisionale, soprattutto durante i colloqui e l’invio dei riscontri. Questi dati sono essenziali per la Dashboard «Tempestività dei riscontri dei responsabili delle assunzioni». Analizzando per ciascun responsabile il tempo tra «Colloquio completato» e «Riscontro inviato», le organizzazioni possono individuare i ritardi e collaborare con le persone interessate per accelerare il processo di selezione. Perché è importante È fondamentale per analizzare il coinvolgimento dei responsabili delle assunzioni e individuare i ritardi nell’invio dei riscontri, che incidono direttamente sull’esperienza dei candidati. Dove reperirli Consultare la documentazione di Workday Recruiting. In genere, questo dato fa parte dei dettagli dell’organizzazione gerarchica o della richiesta di assunzione. Esempi Susan AdamsDavid ChenAngela Rodriguez
	Stato della candidatura ApplicationStatus	Esito finale o stato corrente della candidatura.
Descrizione Questo attributo registra l’esito finale di una candidatura, per esempio «Assunto», «Rifiutato dall’azienda», «Offerta rifiutata» o «Ritirata dal candidato». Rappresenta lo stato conclusivo del processo per una determinata candidatura. Questo stato è fondamentale per l’analisi degli esiti. Viene utilizzato per calcolare i tassi di conversione e di accettazione delle offerte, nonché i tassi di abbandono dei candidati nelle diverse fasi. Capire perché e in quale fase si concludono le candidature è essenziale per migliorare l’efficacia complessiva del processo. Perché è importante Definisce l’esito di ogni caso, un dato essenziale per calcolare i tassi di conversione e di abbandono e valutare il successo complessivo del processo. Dove reperirli In genere corrisponde al campo relativo all’esito finale o al motivo dello stato dell’oggetto Job Application in Workday Recruiting. Esempi AssuntoRifiutatoOfferta rifiutataCandidatura ritirata
	È automatizzata IsAutomated	Indicatore che segnala se l’attività è stata eseguita automaticamente dal sistema.
Descrizione Questo attributo booleano indica se una fase è stata eseguita da un utente o da un processo automatizzato del sistema. Per esempio, l’e-mail di conferma iniziale «Candidatura ricevuta» potrebbe essere un’attività automatizzata. Sapere quali fasi sono automatizzate è importante per individuare opportunità di miglioramento dell’efficienza. Consente di valutare l’impatto dell’automazione sui tempi di ciclo e sull’allocazione delle risorse. Perché è importante Distingue le attività manuali da quelle eseguite dal sistema, un dato essenziale per individuare opportunità di automazione e misurarne l’impatto. Dove reperirli Per ricavare questa informazione, occorre identificare gli account di sistema o i tipi di evento specifici che in Workday sono noti come automatizzati. Esempi truefalse
	È stata ritirata IsWithdrawn	Indicatore che segnala se la candidatura è stata ritirata dal candidato.
Descrizione È un attributo booleano calcolato, impostato su vero quando lo stato finale della candidatura è «Ritirata dal candidato» o uno stato equivalente. Aiuta a isolare i casi in cui il candidato ha abbandonato il processo. Questo indicatore semplifica l’analisi per la Dashboard «Punti critici di abbandono dei candidati» e per il KPI «Tasso di abbandono dei candidati». Consente di filtrare e aggregare facilmente i dati per capire in quali fasi i candidati tendono a ritirarsi. Perché è importante Consente di analizzare in modo specifico gli abbandoni decisi dai candidati, fornendo indicazioni sulla loro esperienza e sui punti di attrito del processo. Dove reperirli Si calcola a partire dall’attributo «ApplicationStatus» durante la trasformazione dei dati. Esempi truefalse
	ID candidato CandidateId	Identificativo univoco del candidato.
Descrizione L’ID candidato identifica in modo univoco una persona nel sistema di selezione, indipendentemente dal numero di posizioni per cui ha presentato domanda. Consente di ricostruire la storia del candidato in azienda attraverso più candidature. Questo attributo è utile per analizzare nel tempo l’esperienza dei candidati. Per esempio, aiuta a individuare chi si ricandida dopo essere stato escluso e a confrontarne i percorsi, oppure a capire se una persona viene valutata contemporaneamente per più ruoli. Perché è importante Consente di analizzare il processo dal punto di vista del candidato, seguendo una persona attraverso più candidature e nel tempo. Dove reperirli È l’identificativo principale dell’oggetto Candidate in Workday Recruiting. Esempi CAND-98765CAND-11223CAND-54321
	ID della richiesta di assunzione JobRequisitionId	Identificativo univoco della posizione aperta per cui il candidato ha presentato domanda.
Descrizione L’ID della richiesta di assunzione identifica la posizione aperta approvata. A una singola richiesta possono essere associate numerose candidature. Questo attributo consente di analizzare i dati a livello di richiesta. Per esempio, è possibile calcolare per quanto tempo è rimasta aperta, quanti candidati sono stati individuati oppure confrontare i percorsi di selezione per diverse tipologie di posizione, come quelle in ambito ingegneristico e commerciale. Perché è importante Collega più candidature a una singola posizione aperta, consentendo di analizzare le metriche relative alla richiesta e i percorsi di selezione. Dove reperirli È l’identificativo principale dell’oggetto Job Requisition in Workday Recruiting ed è collegato a ogni candidatura. Esempi REQ-2023-105REQ-2024-012REQ-2024-345
	Importo dell’offerta OfferAmount	Importo della retribuzione offerta al candidato.
Descrizione Questo attributo contiene l’importo della retribuzione base proposta al candidato nell’offerta di lavoro. È un dato fondamentale nelle fasi finali del processo di selezione. L’analisi degli importi delle offerte può fornire indicazioni sulle tendenze retributive e sulla competitività. Se incrociato con lo stato «Offerta accettata», il dato aiuta a capire se la retribuzione influisce sui rifiuti delle offerte. È un elemento chiave della Dashboard «Gestione delle offerte e tassi di accettazione». Perché è importante Aiuta ad analizzare la strategia retributiva e il suo impatto sui tassi di accettazione delle offerte. Dove reperirli Consultare la documentazione di Workday Recruiting. Questo dato rientra nelle informazioni del processo aziendale «Offer». Esempi 8500012000065000
	Motivo del rifiuto RejectionReason	Motivo indicato quando la candidatura di un candidato viene rifiutata.
Descrizione Quando una candidatura passa allo stato «Rifiutato», questo attributo fornisce il contesto della decisione. Tra i motivi possibili figurano «Non in linea con la cultura aziendale», «Competenze richieste mancanti» o «Posizione assegnata a un altro candidato». L’analisi dei motivi di rifiuto aiuta a individuare schemi ricorrenti nel processo di selezione. Per esempio, molti rifiuti per «Competenze richieste mancanti» in una fase avanzata potrebbero indicare che la descrizione della posizione non è formulata in modo adeguato. Questi dati sono fondamentali per la Dashboard «Punti critici di abbandono dei candidati», che aiuta a capire le cause degli abbandoni. Perché è importante Fornisce indicazioni qualitative sui motivi per cui i candidati non proseguono, aiutando a migliorare le descrizioni delle posizioni e i criteri di selezione. Dove reperirli Consultare la documentazione di Workday Recruiting. Spesso si tratta di uno stato secondario o di un codice motivo associato alla fase di rifiuto. Esempi Non qualificatoEsperienza non adeguataIndividuati candidati più idoneiPosizione chiusa
	Sede di lavoro JobLocation	Area geografica o paese in cui si trova la posizione.
Descrizione Questo attributo indica la città, lo stato o il paese in cui si trova la posizione. Per le posizioni da remoto, può indicare un’area geografica oppure riportare «Da remoto». La sede è una dimensione utile per l’analisi. Consente di confrontare il tempo necessario per l’assunzione e altri KPI tra diverse aree geografiche, mettendo in luce eventuali differenze dovute alle condizioni del mercato locale, alla disponibilità di talenti o alle specificità regionali del processo. Perché è importante Consente di analizzare il processo di selezione su base geografica, evidenziando le differenze regionali nei tempi di ciclo e nell’efficienza. Dove reperirli Questa informazione è inclusa nei dettagli della richiesta di assunzione in Workday. Esempi New York, NYLondra, Regno UnitoDa remoto (Stati Uniti)Berlino, Germania
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati.
Descrizione Questo attributo identifica l’origine dei dati, in questo caso Workday Recruiting. È utile per la governance dei dati e la risoluzione dei problemi, soprattutto quando si combinano dati provenienti da più sistemi. Anche se in un’analisi basata su un solo sistema può sembrare superfluo, è buona prassi includerlo sempre. Conferma la provenienza dei dati e diventa fondamentale quando vengono integrati altri sistemi HR. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la governance e la convalida dei dati e per la gestione di dati provenienti da più fonti. Dove reperirli È un valore statico («Workday Recruiting») aggiunto durante l’estrazione e la trasformazione dei dati. Esempi Workday Recruiting
	Tempo necessario per l’assunzione TimeToHire	Tempo totale che intercorre tra la ricezione della candidatura e l’assunzione del candidato.
Descrizione È un calcolo a livello di caso che misura la durata complessiva del processo di selezione per i candidati assunti. Si calcola come differenza tra l’evento «Candidatura ricevuta» e l’evento «Candidato assunto». È uno dei KPI più importanti nel processo di selezione, noto come «tempo medio necessario per l’assunzione». Fornisce una misura complessiva dell’efficienza del processo. Monitorare questa metrica nel tempo e tra i diversi reparti aiuta a individuare miglioramenti o peggioramenti sistemici. Perché è importante Un KPI fondamentale e di alto livello che misura l’efficienza complessiva del percorso di selezione, dall’inizio alla fine. Dove reperirli Si calcola a partire dai dati dell’Event Log, dopo averli estratti da Workday. Esempi 259200043200003456000
	Tipo di candidato CandidateType	Indica se il candidato è un dipendente interno o un candidato esterno.
Descrizione Questo attributo suddivide i candidati in categorie come «Interno» ed «Esterno». Il processo di selezione, le tempistiche e le politiche possono variare notevolmente tra le due categorie. Analizzare separatamente i processi per i candidati interni ed esterni è fondamentale per ottenere una visione completa. L’organizzazione può così misurare l’efficacia dei programmi di mobilità interna rispetto alle attività di selezione esterna e verificare che entrambi i processi siano ottimizzati. Perché è importante Consente di analizzare separatamente i processi di selezione interni ed esterni, che spesso prevedono fasi, SLA e obiettivi diversi. Dove reperirli Consultare la documentazione di Workday Recruiting. È un campo standard del profilo del candidato o della candidatura. Esempi InternoEsterno
	Ultimo aggiornamento dei dati LastDataUpdate	La data e l’ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo indica quanto sono aggiornati i dati analizzati e riporta la data e l’ora dell’ultima estrazione da Workday Recruiting. È importante che gli utenti sappiano quanto è aggiornata l’analisi, così da interpretare correttamente i risultati e capire se si basano su dati in tempo reale o su un’istantanea acquisita in un momento specifico. Perché è importante Fornisce informazioni sull’aggiornamento dei dati, aiutando gli utenti a capire quanto è recente l’analisi del processo. Dove reperirli Questa data e ora vengono generate e aggiunte durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z

Obbligatorio Consigliato Facoltativo

Attività di selezione e acquisizione dei talenti

Queste sono le fasi e le tappe principali da registrare nell’Event Log per individuare con precisione il processo e i colli di bottiglia nel flusso di lavoro delle assunzioni.

7 Consigliato 8 Facoltativo

	Attività	Descrizione
	Candidato ammesso al colloquio	Indica che il candidato ha superato la selezione iniziale ed è stato ammesso al colloquio. L’evento viene registrato quando un selezionatore sposta il candidato alla fase «Interview» del processo di assunzione.
Perché è importante Questa tappa segna il passaggio dalla selezione iniziale alla valutazione attiva. È un momento importante per analizzare i tassi di conversione e l’efficienza delle prime fasi del processo di selezione. Dove reperirli Deducibile dalla data e ora in cui la fase del candidato nel processo di selezione viene modificata in «Interview» o in una fase equivalente nella cronologia della candidatura. Acquisizione Individuato dal passaggio allo stato «Interview» nel percorso del candidato. Tipo di evento inferred
	Candidato assunto	La conclusione positiva del processo di selezione, in cui il candidato viene assunto formalmente come dipendente. Viene registrata quando il processo aziendale «Hire» viene completato correttamente in Workday e viene creato il record del dipendente.
Perché è importante È l’evento finale che segna il successo del processo. La data e ora sono essenziali per calcolare il tempo di assunzione e misurare l’efficienza complessiva e il tasso di successo del processo. Dove reperirli È un evento esplicito e importante registrato dal processo aziendale «Hire» in Workday HCM. La data e ora di completamento vengono salvate nella cronologia del processo. Acquisizione Registrato a partire dalla data e ora di completamento del processo aziendale «Hire» per il candidato. Tipo di evento explicit
	Candidato non selezionato	Segna la conclusione senza esito positivo del processo, quando l’azienda decide di non proseguire con un candidato. Si deduce quando un selezionatore assegna al candidato lo stato «Rejected» o «Not Hired».
Perché è importante È un evento finale importante per analizzare i punti del processo in cui si concentrano gli abbandoni e i tassi di rifiuto nelle diverse fasi. Aiuta a individuare problemi nella selezione iniziale o nei colloqui. Dove reperirli Deducibile dalla data e ora in cui lo stato della candidatura passa a «Rejected» nella cronologia. Spesso viene registrato anche il motivo del rifiuto. Acquisizione Ricavato dalla data e ora effettive del passaggio allo stato «Rejected». Tipo di evento inferred
	Candidato passato alla fase dell’offerta	Una tappa importante che indica la decisione di presentare un’offerta di lavoro al candidato. Viene registrata quando la candidatura passa alla fase «Offer» del processo di selezione.
Perché è importante Questa attività è un passaggio decisivo del processo e segna il completamento di tutte le fasi di valutazione. Precede la formulazione ufficiale dell’offerta ed è un momento importante per l’analisi delle coorti. Dove reperirli Deducibile dalla traccia di audit della candidatura, in particolare dalla data e ora in cui lo stato del candidato passa a «Offer». Acquisizione Individuato dal passaggio allo stato «Offer» nel percorso del candidato. Tipo di evento inferred
	Candidatura ricevuta	Segna l’inizio del processo di selezione per la candidatura di una persona. L’evento viene registrato quando il candidato invia correttamente la candidatura per una specifica richiesta di assunzione tramite il portale Workday o un sito di selezione integrato.
Perché è importante È l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questa attività e le tappe successive è fondamentale per misurare il tempo complessivo di assunzione e l’efficacia dei canali di ricerca dei candidati. Dove reperirli Workday registra questo evento in modo esplicito quando il processo aziendale «Apply for Job» viene completato correttamente per un candidato. La data e l’ora dell’evento sono disponibili nella cronologia della candidatura. Acquisizione Registrato a partire dalla data e ora di invio della candidatura, riportate nel profilo del candidato. Tipo di evento explicit
	Offerta accettata	Indica l’accettazione formale dell’offerta di lavoro da parte del candidato. L’evento viene registrato quando il candidato completa l’attività «Accept Offer» nel portale Workday oppure quando un selezionatore aggiorna manualmente lo stato.
Perché è importante Questa attività è fondamentale per calcolare i tassi di accettazione delle offerte per fonte, reparto o selezionatore. Avvia inoltre le successive attività preliminari all’assunzione, come i controlli dei precedenti. Dove reperirli Registrato esplicitamente quando il candidato accetta l’offerta tramite il portale. L’azione viene salvata con data e ora nella cronologia del processo aziendale della candidatura. Acquisizione Registrato a partire dalla data e ora di completamento dell’attività «Accept Offer». Tipo di evento explicit
	Offerta presentata	Segna la presentazione formale di un’offerta di lavoro al candidato. È un evento distinto, registrato quando il processo aziendale «Create Offer» o «Propose Compensation» viene completato correttamente per la candidatura in Workday.
Perché è importante È una tappa importante per calcolare il tempo necessario a formulare un’offerta e analizzare la conformità del processo di offerta. Costituisce il punto di partenza per misurare i tassi di accettazione. Dove reperirli L’evento viene registrato esplicitamente nella cronologia del processo aziendale della candidatura. La data e ora di completamento della fase di creazione dell’offerta forniscono il momento dell’attività. Acquisizione Registrato a partire dalla data e ora di completamento del processo aziendale «Create Offer». Tipo di evento explicit
	Candidatura esaminata	Indica il completamento della prima revisione della candidatura da parte di un selezionatore o del team addetto alla selezione iniziale. In genere, si deduce quando lo stato del candidato passa da «Applied» o «New» a una fase «Screening» o «Under Review».
Perché è importante Questa attività è fondamentale per analizzare l’efficienza della fase iniziale di selezione. Monitorarne il volume e la durata aiuta a individuare tempestivamente i colli di bottiglia nel processo di selezione. Dove reperirli Deducibile dalla data di validità del passaggio del candidato a una fase di selezione iniziale o revisione nella traccia di audit del processo aziendale «Recruiting». Acquisizione Ricavato dalla data e ora in cui la fase del candidato viene aggiornata a «Screen». Tipo di evento inferred
	Candidatura ritirata	Un evento finale che indica che il candidato ha deciso volontariamente di ritirarsi dalla selezione per la posizione. Viene registrato quando lo stato del candidato viene aggiornato a «Withdrawn», dal candidato stesso o da un selezionatore.
Perché è importante Monitorare quando e perché i candidati si ritirano è fondamentale per comprendere i problemi legati alla loro esperienza, alla durata del processo o alla competitività dell’offerta. È una metrica importante per analizzare gli abbandoni. Dove reperirli Deducibile dalla data e ora in cui lo stato della candidatura viene aggiornato a «Withdrawn». L’aggiornamento può essere effettuato dal candidato nel portale o da un selezionatore. Acquisizione Ricavato dalla data e ora effettive del passaggio allo stato «Withdrawn». Tipo di evento inferred
	Colloquio completato	Segna la conclusione di un colloquio pianificato con un candidato. In genere, si deduce quando un intervistatore o un selezionatore aggiorna lo stato del colloquio da «Scheduled» a «Completed» o «Conducted».
Perché è importante Questa attività dà avvio al periodo previsto per l’invio dei riscontri. Analizzare il tempo che intercorre da questo momento all’invio del riscontro è essenziale per misurare la tempestività dei responsabili delle assunzioni. Dove reperirli Deducibile dall’aggiornamento dello stato dell’oggetto colloquio pianificato o da una modifica manuale della fase del candidato in Workday Recruiting dopo lo svolgimento del colloquio. Acquisizione Ricavato dalla data e ora dell’aggiornamento dello stato del colloquio o della modifica della fase del candidato dopo il colloquio. Tipo di evento inferred
	Colloquio pianificato	Indica la pianificazione formale di un colloquio con il candidato. In genere, viene registrato quando l’evento del colloquio viene creato e confermato tramite la funzione di pianificazione di Workday per la specifica candidatura.
Perché è importante Misurare il tempo che intercorre tra questa attività e quelle precedenti aiuta a individuare i ritardi nel coordinamento. È fondamentale per migliorare l’esperienza dei candidati e accelerare il processo di colloquio. Dove reperirli La funzione di pianificazione dei colloqui di Workday crea eventi con data e ora. Questa attività può essere registrata utilizzando la data di creazione del colloquio pianificato associato alla candidatura. Acquisizione Registrato a partire dall’evento di creazione di un colloquio nel modulo di selezione. Tipo di evento explicit
	Controllo dei precedenti avviato	Indica l’avvio del controllo dei precedenti per un candidato che ha accettato un’offerta. In genere, si deduce quando il candidato passa alla fase «Background Check», che spesso attiva un’integrazione con un fornitore esterno.
Perché è importante Questa attività è essenziale per monitorare la conformità e analizzare i ritardi tra l’accettazione dell’offerta e l’avvio dei controlli preliminari all’assunzione. Aiuta a garantire un passaggio senza intoppi alla fase di inserimento. Dove reperirli Deducibile dalla data e ora in cui il candidato passa alla fase «Background Check» nel flusso di lavoro di selezione. La traccia di audit della candidatura mostra questa modifica di stato. Acquisizione Ricavato dalla data e ora effettive del passaggio alla fase «Background Check». Tipo di evento inferred
	Controllo dei precedenti superato	Segna il completamento con esito positivo del controllo dei precedenti. L’evento si deduce quando lo stato del candidato viene aggiornato per indicare che ha superato i controlli richiesti ed è quindi idoneo all’assunzione.
Perché è importante È l’ultimo controllo prima di poter concludere il processo di assunzione. I ritardi nella ricezione e nella registrazione dell’esito positivo possono posticipare la data di inizio del candidato. Dove reperirli Deducibile da un aggiornamento dello stato della candidatura, ad esempio il passaggio a «Ready for Hire» o «Background Check Complete». Acquisizione Ricavato dalla modifica di stato che indica il completamento del controllo dei precedenti con esito positivo. Tipo di evento inferred
	Inserimento avviato	Indica l’avvio del processo di inserimento del nuovo assunto in Workday. In genere, è un evento esplicito incluso nel processo aziendale principale «Hire» o attivato subito dopo.
Perché è importante Analizzare il tempo che intercorre tra «Offer Accepted» e questa attività aiuta a migliorare l’esperienza del candidato dopo l’offerta, assicurando che i nuovi assunti siano coinvolti e pronti per il primo giorno. Dove reperirli Il processo aziendale «Onboarding» di Workday presenta una data e ora di avvio ben definite. Queste informazioni possono essere ricavate dalla traccia di audit del record del nuovo dipendente. Acquisizione Registrato a partire dalla data e ora di avvio del processo aziendale «Onboarding». Tipo di evento explicit
	Riscontro inviato	Indica il momento in cui un intervistatore invia formalmente la propria valutazione del candidato dopo il colloquio. Workday offre agli intervistatori una funzione specifica per inserire il riscontro direttamente nel profilo del candidato.
Perché è importante È essenziale per l’analisi della tempestività dei riscontri dei responsabili delle assunzioni. I ritardi in questa fase sono un collo di bottiglia frequente; monitorarli aiuta a rispettare gli accordi sui livelli di servizio. Dove reperirli È un evento registrato esplicitamente quando il riscontro viene inviato tramite l’attività «Provide Interview Feedback». La data e l’ora dell’invio vengono registrate nel record del colloquio. Acquisizione Ricavato dalla data e ora di completamento dell’evento «Provide Interview Feedback». Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Workday Recruiting

Passaggi

Acceda a Workday: acceda al tenant Workday con un account utente autorizzato a creare report personalizzati e ad accedere ai dati di recruiting.
Crei un report personalizzato: apra l’attività «Create Custom Report». Selezioni «Advanced» come tipo di report e attivi l’opzione «Enable as Web Service». Come origine dei dati, scelga una fonte indicizzata, ad esempio «All Job Applications», per ottenere prestazioni migliori.
Definisca l’oggetto aziendale principale: imposti «Job Application» come oggetto aziendale principale. Questo oggetto costituirà la base del report e l’identificativo del caso.
Aggiunga le colonne dei dati: inserisca nella griglia delle colonne del report i campi obbligatori e quelli consigliati. Aggiunga «Job Application» per JobApplicationId. Per altri attributi, come «Recruiter» e «Hiring Manager», dovrà aggiungere i campi dagli oggetti aziendali correlati alla candidatura.
Crei campi calcolati per le attività: questo è il passaggio più importante. Per ciascuna delle 15 attività, crei due campi calcolati: uno per il nome dell’attività e uno per la data e ora dell’evento. La logica è descritta nella sezione Query. Per acquisire, ad esempio, «Offer Extended», crei un campo che verifica il completamento del processo aziendale «Propose Compensation» e un altro che ne estrae la data e ora di completamento.
Aggiunga i campi calcolati al report: inserisca come colonne tutti i campi calcolati appena creati, 30 in totale: 15 per i nomi delle attività e 15 per le date e ore. Il report avrà un formato «wide», con una riga per ogni candidatura e numerose colonne che rappresentano le possibili attività.
Configuri le opzioni del servizio Web: nella scheda «Web Service» della definizione del report, verifichi che la casella «Enable as Web Service» sia selezionata. Qui può consultare lo spazio dei nomi e l’URL del report. Annoti lo «Namespace» per utilizzarlo in seguito.
Imposti le autorizzazioni: condivida il report con un utente di sistema per le integrazioni (ISU) o con un gruppo di sicurezza specifico che verrà utilizzato per chiamare l’endpoint RaaS. L’utente deve poter accedere al dominio dell’origine dei dati, ad esempio «Recruiting: Job Applications».
Esegua e verifichi il report: esegua il report dall’interfaccia di Workday per controllarne i risultati. Verifichi che il numero di righe sia ragionevole e che i campi calcolati siano valorizzati correttamente per alcune candidature di esempio.
Pianifichi l’estrazione: utilizzi uno strumento di pianificazione esterno o un middleware, ad esempio MuleSoft, Boomi o uno script personalizzato, per chiamare regolarmente l’URL RaaS del report. Lo strumento dovrà gestire la chiamata all’API SOAP o REST di Workday con le corrette modalità di autenticazione.
Trasformi i dati: i dati grezzi restituiti dalla chiamata RaaS saranno in un file XML o CSV in formato «wide». Nel middleware o in un linguaggio di scripting, come Python, dovrà trasformarli in formato «long». Lo script deve scorrere ogni riga, corrispondente a una candidatura, e creare una nuova riga nel log degli eventi per ogni coppia attività/data e ora non vuota. Il risultato avrà tre colonne principali: JobApplicationId, ActivityName e EventTime.

Configurazione

Tipo di report: utilizzi sempre «Advanced» per poter creare campi calcolati complessi e accedere agli oggetti aziendali correlati.
Origine dei dati: utilizzi un’origine indicizzata, come «All Job Applications», per garantire un’esecuzione efficiente del report. Eviti le origini non indicizzate quando lavora con grandi volumi di dati.
Filtro per intervallo di date: è essenziale applicare un filtro al campo «Application Date» dell’oggetto aziendale Job Application. Per gestire i volumi di dati e le prestazioni del report, inizi con un intervallo ridotto, ad esempio gli ultimi 3-6 mesi.
Oggetto aziendale principale: l’oggetto principale deve essere «Job Application», affinché JobApplicationId venga utilizzato come identificativo del caso.
Abilitazione del servizio Web: selezioni l’opzione «Enable as Web Service» nella configurazione del report per renderlo accessibile tramite API.
Sicurezza e autorizzazioni: il report deve essere condiviso con un utente di sistema per le integrazioni (ISU) dedicato. L’ISU deve disporre delle autorizzazioni dei gruppi di sicurezza per accedere ai domini di dati necessari, tra cui «Recruiting: Job Applications», «Business Process Transactions» e «Worker Data».
Formato di output: Workday offre diversi formati di output, tra cui XML, CSV e JSON. Per estrarre dati strutturati tramite API, XML, in particolare il formato «Simple XML», è spesso la scelta più affidabile.

Query di esempio 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.

Passaggi

Configuri l’accesso a Workday: Crei in Workday un utente di sistema per le integrazioni (Integration System User, ISU). Conceda a questo utente l’accesso ai domini di sicurezza necessari per l’API Recruiting. Tra i domini principali figurano 'Worker Data: Public Worker Reports', 'Job Application' e 'Recruiting: Reports'.
Individui l’endpoint API: Individui nel Suo tenant Workday l’endpoint REST API per l’operazione 'Get Job Applications'. L’URL segue in genere questo formato: https://[your_tenant_host]/ccx/api/v1/[your_tenant_name]/recruiting/jobApplications.
Configuri l’ambiente Python: Verifichi che Python sia installato. Installi le librerie necessarie con pip: pip install requests pandas.
Sviluppi lo script di autenticazione: Nello script Python, implementi l’autenticazione di base utilizzando le credenziali dell’ISU creato al passaggio 1. Il nome utente e la password verranno inviati nell’intestazione della richiesta.
Implementi la logica delle richieste API: Scriva la funzione che richiama l’endpoint 'Get Job Applications'. Utilizzi i parametri della richiesta per filtrare i dati, ad esempio updatedSince per recuperare le candidature modificate dopo una determinata data. Questo passaggio è fondamentale per gestire il volume dei dati.
Gestisca la paginazione dell’API: L’API Workday restituisce un numero limitato di record per richiesta. Lo script deve controllare nella risposta la presenza di un conteggio total e di un collegamento alla pagina successiva o di un parametro di offset, quindi scorrere tutte le pagine per recuperare l’intero set di dati.
Definisca la mappatura delle attività: Crei un dizionario di mappatura o una serie di istruzioni condizionali nello script. Questa logica tradurrà gli stati dei processi aziendali e le fasi di selezione di Workday, ad esempio 'Screen', 'Interview', 'Offer', 'Hire', nei nomi delle attività richiesti, ad esempio 'Application Screened' e 'Candidate Moved To Interview'.
Trasformi i dati delle candidature: Per ogni candidatura recuperata tramite l’API, analizzi la cronologia di audit o la cronologia delle fasi. Questa cronologia contiene la sequenza delle fasi, gli esiti e gli eventi dei processi aziendali, con le relative date e ore.
Generi le righe dell’Event Log: Scorra la cronologia di ogni candidatura. Per ciascun evento storico pertinente che corrisponde alla mappatura delle attività, crei un dizionario che rappresenti una riga dell’Event Log finale. Compili JobApplicationId, ActivityName, EventTime e gli altri attributi richiesti.
Raggruppi e organizzi i dati: Raccolga in un’unica lista tutte le righe dell’Event Log generate per le candidature.
Crei ed esporti il file CSV: Utilizzi la libreria pandas per convertire l’elenco dei dizionari degli eventi in un DataFrame, quindi esporti il DataFrame in un file CSV. Verifichi che le intestazioni delle colonne corrispondano ai requisiti di ProcessMind, ad esempio CaseId, Attività, Data e ora.
Riveda e carichi il file: Apra il file CSV finale e ne verifichi la correttezza e la completezza prima di caricarlo nello strumento di Process Mining.

Configurazione

Utente di sistema per le integrazioni Workday (ISU): è necessario un ISU con una password robusta e senza scadenza. Deve disporre delle autorizzazioni per i domini di sicurezza «Recruiting» e «Worker Data» per accedere ai dettagli delle candidature e dei candidati.
Endpoint e versione dell’API: deve utilizzare l’endpoint REST API corretto per il tenant Workday. È importante specificare la versione dell’API nella richiesta per garantire un comportamento coerente.
Filtro per intervallo di date: lo script dovrebbe applicare un filtro per data, ad esempio updatedSince, per limitare la query a un periodo gestibile. Per le prime estrazioni si consiglia un intervallo di 3-6 mesi. Per i successivi caricamenti incrementali, utilizzi la data e ora dell’ultima estrazione completata correttamente.
Limite di paginazione: tenga presente il parametro API limit, che determina quanti record vengono restituiti per pagina. In genere, il limite massimo è 100. Lo script deve gestire questo vincolo effettuando più richieste paginate.
Campi della risposta: per migliorare le prestazioni, se l’API lo consente può specificare quali campi restituire tramite il parametro fields o uno equivalente. In questo modo si riduce la dimensione dei dati restituiti dall’API.
Configurazione della mappatura delle attività: la logica centrale dello script consiste nel mappare le fasi di Workday alle attività definite. Potrebbe essere necessario adattare questa mappatura alla configurazione specifica del processo Workday Recruiting della Sua organizzazione.

Query di esempio 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.")

Passaggi

Prerequisiti e configurazione: Verifichi di disporre di una licenza per uno strumento ETL o iPaaS di terze parti, come CData, MuleSoft o una piattaforma analoga, con il relativo connettore Workday installato. Verifichi inoltre di avere le credenziali di un utente di sistema Workday per le integrazioni (Integration System User, ISU) con le autorizzazioni API necessarie per i domini Recruiting e Staffing.
Configuri la connessione a Workday: Nello strumento ETL, crei una nuova connessione a Workday. Inserisca l’URL del tenant Workday, la versione dell’API e le credenziali dell’ISU, ad esempio nome utente e password oppure token OAuth 2.0. Verifichi che la connessione funzioni correttamente.
Esplori lo schema dei dati: Utilizzi il browser dello schema o l’esploratore delle origini dati dello strumento ETL per visualizzare gli oggetti Workday disponibili tramite il connettore. In genere sono presentati come tabelle o viste, ad esempio Job_Application, Job_Requisition e Candidate_Stage_History. Prenda familiarità con i campi e le relazioni disponibili.
Individui gli oggetti dati principali: Per questa estrazione, avrà bisogno soprattutto dei dati relativi a candidature, cronologia dei candidati, colloqui, offerte e assunzioni. I nomi esatti dipendono dal connettore, ma cerchi gli oggetti che rappresentano queste entità principali.
Sviluppi la query SQL: Crei un nuovo processo o flusso di estrazione dei dati. Utilizzi un passaggio di trasformazione SQL per eseguire una query sulla connessione Workday. Copi e incolli in questo passaggio la query SQL fornita, progettata per raccogliere dati da più oggetti Workday e unirli in un unico formato Event Log.
Aggiunga parametri alla query: Modifichi la clausola WHERE della query per includere i parametri dell’intervallo di date, ad esempio startDate e endDate. Configuri questi parametri nel processo ETL per poter modificare facilmente il periodo di estrazione senza intervenire sul codice.
Esegua il processo di estrazione: Avvii il processo ETL configurato. Lo strumento si collegherà a Workday, eseguirà la query SQL tramite l’API e recupererà i dati in un’area di staging o in memoria.
Riveda e convalidi i dati: Prima di scrivere il file finale, utilizzi la funzione di anteprima dello strumento ETL per controllare i risultati. Verifichi che il numero di righe sia ragionevole, che tutte le colonne siano compilate come previsto e che siano presenti attività diverse.
Configuri la destinazione: Definisca la destinazione dei dati estratti, in genere un file CSV da caricare in ProcessMind. Configuri il nome del file, il delimitatore (virgola) e la codifica (UTF-8).
Completi ed esporti i dati: Esegua l’intero processo di estrazione per generare il file CSV finale. Verifichi che le intestazioni delle colonne nel file corrispondano agli attributi richiesti: JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Reparto e ApplicationStatus.

Configurazione

Credenziali del connettore Workday: la connessione richiede l’URL del tenant Workday e un utente di sistema per le integrazioni (ISU) autorizzato, con password o credenziali client OAuth 2.0. L’utente deve disporre delle autorizzazioni di sicurezza per le aree funzionali «Recruiting» e «Staffing».
Abilitazione dei servizi Web: il connettore potrebbe richiedere di specificare quali servizi Web Workday rendere disponibili. Verifichi che siano abilitati i servizi relativi a Recruiting, Staffing e Human Resources, così da poter accedere a tutti gli oggetti dati necessari.
Intervallo di date: per gestire le prestazioni e il volume dei dati, è essenziale limitare l’estrazione a un periodo specifico. Si consiglia un caricamento iniziale di 3-6 mesi di dati, seguito da caricamenti incrementali giornalieri o settimanali. L’intervallo si imposta nella clausola WHERE della query SQL.
Filtri sull’ambito dei dati: se desidera analizzare il processo solo per alcune aree dell’organizzazione, può aggiungere alla clausola WHERE filtri per campi come Company, Cost Center o Supervisory Organization.
Versione dell’API: alcuni connettori richiedono di specificare la versione dell’API Workday. È preferibile utilizzare una versione recente e supportata, per accedere agli oggetti dati e alle funzionalità più aggiornati.
Considerazioni sulle prestazioni: le estrazioni complete dei dati da Workday possono richiedere molte risorse. Pianifichi i processi di grandi dimensioni nelle fasce orarie di minore attività. Per le analisi continuative, implementi una strategia di caricamento incrementale basata sulla data e ora dell’ultima modifica, in modo da recuperare solo i record nuovi o aggiornati.

Query di esempio 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]'

È pronto a iniziare?

Utilizzi questo template per trasformare i dati sull’acquisizione dei talenti in indicazioni utili e migliorare l’efficienza delle assunzioni. Inizi oggi il percorso verso un processo di selezione più snello ed efficace.

Torna alla guida al miglioramento

Scarica il template

Superi i colli di bottiglia nelle assunzioni: migliori oggi l’acquisizione dei talenti

Individui le inefficienze, riduca del 30% il tempo del ciclo di assunzione e raggiunga più rapidamente gli obiettivi di acquisizione dei talenti.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Prova gratuita di 14 giorni.

Il Suo template dei dati per la selezione e l’acquisizione dei talenti

Il Suo template dei dati per la selezione e l’acquisizione dei talenti

Attributi per la selezione e l’acquisizione dei talenti

Attività di selezione e acquisizione dei talenti

Guide all’estrazione

Estrazione dei dati Workday tramite Report-as-a-Service (RaaS)

Passaggi

Configurazione

Query di esempio sql

Estrazione dei dati dall’API Workday Recruiting tramite uno script Python

Passaggi

Configurazione

Query di esempio python

Estrazione con uno strumento ETL e un connettore Workday

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Superi i colli di bottiglia nelle assunzioni: migliori oggi l’acquisizione dei talenti