> Miglioramento Continuo dei Processi > Recruiting e Talent Acquisition > Workday Recruiting > Template Dati

Il Suo template per i dati di Recruitment & Talent Acquisition

Workday Recruiting

Attributi di Recruiting e Talent Acquisition (20) Attività di Recruiting e Talent Acquisition (15) Guide all'Estrazione (3)

Il Suo template per i dati di Recruitment & Talent Acquisition

Questo template è una guida completa alla raccolta dei dati necessari per l'analisi dei processi di Recruiting e Talent Acquisition. Elenca gli attributi essenziali, le attività da tracciare e offre indicazioni su come estrarre i dati da Workday Recruiting. Utilizzi questa risorsa per velocizzare la preparazione dei dati.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione per Workday Recruiting

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

Attributi di Recruiting e Talent Acquisition

Questi sono i campi dati raccomandati da includere nell'event log per un'analisi completa del recruiting e della talent acquisition, che permettono insight profondi sul processo.

3 Obbligatorio 5 Consigliato 12 Facoltativo

	Nome	Descrizione
	Candidatura JobApplicationId	L'identificatore univoco per la candidatura, che funge da ID del caso centrale per il processo di selezione.
Descrizione L'ID Candidatura traccia in modo univoco il percorso di un singolo candidato per una specifica requisizione, dall'invio alla decisione finale. Ogni interazione o cambio di stato è collegato a questo identificatore. Nel process mining, questo attributo è fondamentale poiché permette di ricostruire il flusso end-to-end di ogni candidato, consentendo l'analisi dei tempi di ciclo, dei colli di bottiglia e dei percorsi seguiti. È l'elemento centrale che unisce tutte le attività in un unico caso. Perché è importante Questo è il Case ID essenziale che collega tutte le attività di selezione per un singolo candidato, rendendo possibile l'analisi dell'intero percorso. Dove trovare Questo identificatore è un elemento centrale in Workday Recruiting, solitamente disponibile nei report e nelle sorgenti dati relative alle candidature. Esempi APP-2023-001234APP-2023-005678APP-2024-009101
	Nome attività ActivityName	Il nome dell'evento specifico o del compito avvenuto in un determinato momento del processo di selezione.
Descrizione Il Nome dell'attività descrive un singolo passaggio o traguardo nel percorso di assunzione, come 'Candidatura esaminata', 'Colloquio pianificato' o 'Offerta inviata'. Queste attività formano la sequenza di eventi del processo. Questo attributo è fondamentale per visualizzare la mappa del processo, identificare i diversi percorsi delle candidature e analizzare la frequenza e l'ordine degli eventi. È la base per capire cosa sta succedendo nel processo. Perché è importante Questo attributo definisce i passaggi del processo di selezione, consentendo la visualizzazione e l'analisi del flusso. Dove trovare Derivato dai nomi dei passaggi dei processi aziendali o dai cambi di stato nei dati delle candidature di Workday Recruiting. Esempi Domanda VagliataColloquio completatoOfferta AccettataCandidato rifiutato
	Timestamp Evento EventTime	Il timestamp che indica quando si è verificata l'attività o l'evento.
Descrizione Questo attributo registra data e ora esatte in cui è avvenuta un'attività. I timestamp sono la spina dorsale del process mining e forniscono l'ordine cronologico degli eventi. Nell'analisi, i timestamp servono a calcolare le durate tra le attività, misurare i tempi di ciclo come il 'Time-to-Hire' e identificare i colli di bottiglia. Sono essenziali per ogni analisi temporale del funnel di selezione. Perché è importante I timestamp sono critici per calcolare tutti i KPI temporali, comprendere la durata dei processi e scoprire i colli di bottiglia. Dove trovare Corrisponde alla data di completamento o alla data di transazione di un passaggio del processo aziendale in Workday Recruiting. Esempi 2023-10-26T10:00:00Z2023-11-05T14:30:00Z2024-01-15T09:15:00Z
	Dipartimento Department	Il dipartimento o l'unità aziendale associata alla requisizione di lavoro.
Descrizione Questo attributo specifica l'unità organizzativa (es. 'Engineering', 'Marketing') per cui si assume. È derivato dall'organizzazione associata alla requisizione. Filtrare per dipartimento permette di confrontare i processi tra le diverse aree aziendali. Viene usato nella dashboard sull'efficienza dello screening per vedere se certi reparti hanno tempi più lunghi, indicando possibili differenze nelle pratiche o nelle risorse. Perché è importante Consente il confronto delle prestazioni e dell'efficienza del processo di selezione tra diverse unità aziendali o reparti. Dove trovare Consulti la documentazione di Workday Recruiting. Questo dato deriva dall'Organizzazione di supervisione legata alla Job Requisition. Esempi IngegneriaVenditeRisorse UmaneFinanza
	Fonte dell'Applicazione ApplicationSource	Il canale o la fonte attraverso cui è stata ricevuta la candidatura.
Descrizione Questo attributo indica come un candidato ha scoperto la posizione, ad esempio tramite il sito aziendale, LinkedIn, segnalazioni interne o agenzie. Capire la sorgente è vitale per ottimizzare la strategia e il budget di selezione. Alimenta la dashboard sull'efficacia dei canali di sourcing e il KPI sul tasso di accettazione per fonte, aiutando a stabilire quali canali portano i candidati migliori. Perché è importante Aiuta a valutare l'efficacia dei diversi canali di sourcing, consentendo decisioni basate sui dati su dove investire le risorse di recruiting. Dove trovare Consulti la documentazione di Workday Recruiting. Si tratta di un campo standard sulla candidatura. Esempi `LinkedIn`Segnalazione DipendenteSito carriere aziendaleIndeed
	Nome Recruiter RecruiterName	Il nome del recruiter responsabile della gestione della candidatura.
Descrizione Questo attributo identifica il recruiter assegnato alla candidatura e alla requisizione, responsabile di guidare il candidato nel processo. Analizzare il processo per recruiter è fondamentale per capire le performance del team e il carico di lavoro. Aiuta a costruire la dashboard sulle prestazioni e a calcolare KPI come la varianza del tempo per l'offerta, permettendo confronti e l'identificazione delle best practice. Perché è importante Consente l'analisi delle prestazioni per recruiter, aiutando a identificare i top performer, le esigenze di formazione e gli squilibri nel carico di lavoro. Dove trovare Consulti la documentazione di Workday Recruiting. In genere è collegato agli oggetti Job Requisition o Job Application. Esempi John SmithEmily JonesMaria Garcia
	Responsabile delle Assunzioni HiringManager	Il nome dell'hiring manager per la posizione per cui il candidato si è proposto.
Descrizione Questo attributo identifica il responsabile del team o del dipartimento con la posizione aperta. L'hiring manager è un attore chiave, specialmente durante i colloqui e i feedback. Questo dato è essenziale per la dashboard sulla tempestività dei feedback. Analizzando il tempo tra 'Colloquio completato' e 'Feedback inviato' per ogni manager, l'azienda può individuare i ritardi e collaborare con i responsabili per accelerare le assunzioni. Perché è importante Fondamentale per analizzare l'impegno dei hiring manager e identificare i ritardi nell'invio dei feedback, che influiscono direttamente sull'esperienza del candidato. Dove trovare Consulti la documentazione di Workday Recruiting. Fa solitamente parte dell'organizzazione di supervisione o dei dettagli della job requisition. Esempi Susan AdamsDavid ChenAngela Rodriguez
	Stato Domanda ApplicationStatus	L'esito finale o lo stato attuale della candidatura.
Descrizione Questo attributo registra l'esito finale di una candidatura, come 'Assunto', 'Rifiutato dall'azienda', 'Offerta declinata' o 'Ritirato dal candidato'. Rappresenta lo stato terminale del processo. Questo stato è critico per l'analisi dei risultati. Serve a calcolare i tassi di conversione, di accettazione e di abbandono nelle varie fasi. Capire perché e dove finiscono le candidature è la chiave per migliorare l'efficacia globale. Perché è importante Definisce l'esito di ogni caso, il che è essenziale per calcolare i tassi di conversione, i tassi di abbandono e il successo complessivo del processo. Dove trovare Solitamente è il campo dell'esito finale o del motivo dello stato nell'oggetto Candidatura di Workday Recruiting. Esempi `Assunto`RifiutatoOfferta declinataDomanda Ritirata
	È Automatizzato IsAutomated	Un flag che indica se l'attività è stata eseguita automaticamente dal sistema.
Descrizione Questo attributo booleano identifica se un passaggio è stato eseguito da un utente o da un sistema automatico. Ad esempio, l'invio della conferma di ricezione della candidatura potrebbe essere un'attività automatizzata. Capire quali passaggi sono automatici è importante per individuare opportunità di efficienza e valutare l'impatto dell'automazione sui tempi di ciclo e sull'allocazione delle risorse. Perché è importante Distingue tra attività manuali e guidate dal sistema, il che è fondamentale per identificare le opportunità di automazione e misurarne l'impatto. Dove trovare Queste informazioni devono essere ricavate identificando gli account utente di sistema o specifici tipi di eventi noti per essere automatizzati in Workday. Esempi truefalse
	È ritirato IsWithdrawn	Un indicatore che segnala se la candidatura è stata ritirata dal candidato.
Descrizione Attributo calcolato (true/false) che indica se lo stato finale della candidatura è 'Ritirato dal candidato'. Aiuta a isolare i casi di abbandono spontaneo. Questo flag semplifica l'analisi per la dashboard sui punti critici di abbandono e per il KPI relativo, permettendo di filtrare facilmente i dati per capire in quali fasi i candidati si ritirano più spesso. Perché è importante Aiuta ad analizzare specificamente gli abbandoni guidati dai candidati, fornendo informazioni sull'esperienza del candidato e sui punti di attrito del processo. Dove trovare Viene calcolato in base all'attributo 'ApplicationStatus' durante la trasformazione dei dati. Esempi truefalse
	ID Candidato CandidateId	L'identificatore univoco del candidato.
Descrizione L'ID Candidato identifica in modo univoco una persona nel sistema, indipendentemente dal numero di posizioni per cui si candida. Ciò consente di tracciarne la storia in azienda attraverso diverse candidature. Questo attributo è utile per analizzare la candidate experience nel tempo. Ad esempio, può aiutare a capire se candidati precedentemente rifiutati si stanno ricandidando o se un singolo profilo è valutato per più ruoli contemporaneamente. Perché è importante Consente una visione del processo incentrata sul candidato, monitorando un individuo attraverso più candidature e nel tempo. Dove trovare È l'identificativo principale per l'oggetto Candidato in Workday Recruiting. Esempi CAND-98765CAND-11223CAND-54321
	ID Richiesta di Assunzione JobRequisitionId	L'identificatore univoco della posizione aperta per la quale il candidato ha fatto domanda.
Descrizione L'ID Requisizione è l'identificativo della posizione aperta approvata. Una singola requisizione può avere molte candidature associate. Questo attributo permette l'analisi a livello di requisizione. Ad esempio, si può analizzare il tempo totale di apertura, il numero di candidati trovati o confrontare i funnel di selezione per diversi tipi di lavoro (es. posizioni tecniche vs vendite). Perché è importante Collega più candidature a una singola posizione aperta, consentendo l'analisi delle metriche a livello di requisizione e dei funnel di assunzione. Dove trovare Identificativo principale sull'oggetto Requisizione in Workday Recruiting, collegato a ogni candidatura. Esempi REQ-2023-105REQ-2024-012REQ-2024-345
	Importo dell'offerta OfferAmount	L'importo della RAL offerta al candidato.
Descrizione Questo attributo contiene la RAL proposta al candidato nell'offerta. È un dato critico nelle fasi finali della selezione. Analizzare gli importi delle offerte fornisce insight sui trend retributivi e sulla competitività. Se combinato con lo stato 'Offerta accettata', aiuta a capire se la retribuzione influisce sui rifiuti. È un elemento chiave per la dashboard di gestione delle offerte. Perché è importante Aiuta ad analizzare la strategia retributiva e il suo impatto sui tassi di accettazione delle offerte. Dove trovare Consulti la documentazione di Workday Recruiting. Questo farebbe parte dei dati del processo di business 'Offer'. Esempi 8500012000065000
	Motivo del Rigetto RejectionReason	Il motivo fornito quando una candidatura viene rifiutata.
Descrizione Quando una candidatura passa allo stato 'Rifiutato', questo attributo fornisce il contesto (es. 'Mancanza di competenze', 'Posizione coperta da altri'). Analizzare i motivi del rifiuto aiuta a identificare pattern critici. Ad esempio, molti rifiuti per mancanza di competenze in fase avanzata potrebbero indicare una job description scritta male. Questo dato è essenziale per la dashboard sui punti caldi di abbandono per capire il "perché" dietro le uscite dal funnel. Perché è importante Fornisce insight qualitativi sul perché i candidati non procedano nel funnel, aiutando a migliorare le job description e i criteri di screening. Dove trovare Consulti la documentazione di Workday Recruiting. Spesso si tratta di un sottostato o di un codice motivo associato alla fase di rifiuto. Esempi Non qualificatoMancata corrispondenza dell'esperienzaIdentificati candidati miglioriPosizione chiusa
	Sede di lavoro JobLocation	La sede geografica o il paese del lavoro.
Descrizione Questo attributo specifica la città o il paese della posizione. Per i ruoli da remoto, può indicare una regione o la dicitura 'Remote'. La sede è una dimensione di analisi potente. Permette di confrontare il 'Time-to-Hire' e altri KPI tra diverse regioni, rivelando variazioni dovute al mercato locale, alla disponibilità di talenti o a differenze nei processi regionali. Perché è importante Consente l'analisi geografica del processo di selezione, evidenziando le differenze regionali nei tempi di ciclo e nell'efficienza. Dove trovare Queste informazioni fanno parte dei dettagli della Requisizione di lavoro in Workday. Esempi New York, NYLondon, UKRemoto (USA)Berlino, Germania
	Sistema di Origine SourceSystem	Il sistema da cui i dati sono stati estratti.
Descrizione Questo attributo identifica l'origine dei dati, che in questo caso è Workday Recruiting. Aiuta nella data governance e nel troubleshooting, specie se si combinano dati da più sistemi. Anche se può sembrare superfluo in un'analisi su un singolo sistema, includerlo è una best practice: conferma la provenienza dei dati e diventa fondamentale se si integrano altri sistemi HR in futuro. Perché è importante Identifica l'origine dei dati, il che è fondamentale per la data governance, la convalida e la gestione di dati provenienti da più fonti. Dove trovare Si tratta di un valore statico ('Workday Recruiting') aggiunto durante il processo di estrazione e trasformazione dei dati. Esempi Workday Recruiting
	Tempo di Assunzione TimeToHire	Il tempo totale trascorso dalla ricezione della candidatura all'assunzione.
Descrizione Calcolo a livello di caso che misura la durata totale della selezione per i candidati assunti. È la differenza temporale tra 'Candidatura ricevuta' e 'Candidato assunto'. È uno dei KPI più importanti ('Tempo medio di assunzione'). Fornisce una misura macro dell'efficienza del processo. Tracciare questa metrica nel tempo e tra i vari dipartimenti aiuta a identificare miglioramenti o peggioramenti sistemici. Perché è importante Un KPI critico di alto livello che misura l'efficienza complessiva del funnel di reclutamento dall'inizio alla fine. Dove trovare Viene calcolato dai dati dell'event log dopo l'estrazione da Workday. Esempi 259200043200003456000
	Tempo di Elaborazione ProcessingTime	La durata del tempo trascorso lavorando attivamente su un'attività.
Descrizione Il Processing Time, o tempo attivo, misura la durata dell'attività svolta da una risorsa su un compito specifico. È diverso dal cycle time, che include anche i tempi di attesa. Ad esempio, è il tempo che un recruiter dedica effettivamente allo screening di una candidatura. Questa metrica è preziosa per comprendere l'efficienza delle risorse e il carico di lavoro. Se disponibile, aiuta a individuare quali attività richiedono più impegno reale, non solo quanto tempo passa tra l'inizio e la fine. Perché è importante Misura l'impegno lavorativo effettivo per un'attività, aiutando a distinguere il tempo di lavoro attivo dai tempi morti per una migliore pianificazione delle risorse. Dove trovare Spesso non è disponibile direttamente e va calcolato o stimato. Ad esempio, può essere il tempo tra l'inizio e il completamento dello screening, se tale granularità è presente. Esempi 360018007200
	Tipo di candidato CandidateType	Indica se il candidato è un dipendente interno o un richiedente esterno.
Descrizione Questo attributo suddivide i candidati tra 'Interni' ed 'Esterni'. I processi, le tempistiche e le policy possono differire sensibilmente tra le due tipologie. Analizzare separatamente i candidati interni ed esterni è fondamentale per una visione completa. Permette all'azienda di misurare l'efficacia dei programmi di mobilità interna rispetto alla ricerca esterna, garantendo l'ottimizzazione di entrambi. Perché è importante Consente l'analisi separata dei processi di assunzione interni ed esterni, che spesso hanno fasi, SLA e obiettivi differenti. Dove trovare Consulti la documentazione di Workday Recruiting. Si tratta di un campo standard sul profilo del candidato o sulla candidatura. Esempi InternoEsterno
	Ultimo `Data Update` LastDataUpdate	Il timestamp di quando i dati sono stati aggiornati o estratti l'ultima volta dal sistema di origine.
Descrizione Questo attributo indica quanto siano recenti i dati analizzati, mostrando data e ora dell'ultima estrazione da Workday Recruiting. È importante affinché gli utenti capiscano il grado di aggiornamento dell'analisi e interpretino correttamente i risultati, sapendo se stanno guardando dati in tempo reale o una fotografia di un momento specifico. Perché è importante Fornisce contesto sull'aggiornamento dei dati, assicurando che gli utenti sappiano quanto sia recente l'analisi del processo. Dove trovare Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL). Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z

Obbligatorio Consigliato Facoltativo

Attività di Recruiting e Talent Acquisition

Questi sono i passaggi chiave e i traguardi da registrare nell'event log per una corretta analisi dei processi e l'identificazione dei colli di bottiglia nel workflow di assunzione.

7 Consigliato 8 Facoltativo

	Activity	Descrizione
	Candidato Assunto	La conclusione positiva del processo di selezione, in cui il candidato viene assunto formalmente. Viene registrato quando il processo aziendale 'Assumi' viene completato con successo in Workday, creando il record del dipendente.
Perché è importante È l'evento finale che indica il successo. Il timestamp è essenziale per calcolare il Time-to-Hire e misurare l'efficienza complessiva e i tassi di successo. Dove trovare Si tratta di un evento esplicito registrato dal processo 'Assumi' in Workday HCM. Il timestamp di completamento è riportato nella cronologia del processo. Acquisisci Acquisito dal timestamp di completamento del processo di business 'Hire' per il candidato. Tipo di evento explicit
	Candidato passato al colloquio	Indica che un candidato ha superato lo screening iniziale ed è ora idoneo per un colloquio. Questo evento viene registrato quando un recruiter sposta il candidato alla fase 'Colloquio' nel processo di assunzione.
Perché è importante Questo traguardo segna il passaggio dallo screening alla valutazione attiva. È un punto chiave per analizzare i tassi di conversione e l'efficienza della parte alta del funnel di selezione. Dove trovare Ricavato dal timestamp in cui la fase di selezione del candidato viene modificata in 'Colloquio' o dicitura simile nella cronologia della candidatura. Acquisisci Identificato dal cambio di stato a una fase 'Interview' nella progressione del candidato. Tipo di evento inferred
	Candidato passato alla fase di offerta	Una tappa fondamentale che indica la decisione di estendere un'offerta di lavoro al candidato. Questo evento viene registrato quando la candidatura passa alla fase 'Offer' nel processo di selezione.
Perché è importante Questa attività è un passaggio critico che segna il completamento positivo di tutte le fasi di valutazione. Precede l'offerta formale ed è un punto chiave per l'analisi delle coorti. Dove trovare Ricavato dall'audit trail della candidatura, nello specifico dal timestamp in cui lo stato del candidato passa a 'Offerta'. Acquisisci Identificato dal cambio di stato a una fase 'Offer' nella progressione del candidato. Tipo di evento inferred
	Candidato rifiutato	Indica una conclusione negativa del processo, quando l'azienda decide di non proseguire con un candidato. Si deduce quando un recruiter sposta il candidato a uno stato di esito 'Rifiutato' o 'Non assunto'.
Perché è importante Questo è un evento finale critico per analizzare i punti caldi di abbandono e i tassi di rifiuto nelle varie fasi. Aiuta a identificare problemi nel processo di colloquio o screening. Dove trovare Ricavato dal timestamp in cui l'esito del candidato viene modificato in 'Rifiutato' nella cronologia delle candidature. Spesso viene registrato anche il motivo del rifiuto. Acquisisci Derivato dal timestamp effettivo del passaggio allo stato 'Rejected'. Tipo di evento inferred
	Candidatura Ricevuta	Segna l'inizio del processo di selezione. L'evento viene registrato quando un candidato invia con successo la propria domanda per una specifica requisizione tramite il portale Workday o un sito di carriere integrato.
Perché è importante È l'evento di inizio principale del processo. Analizzare il tempo tra questa attività e i traguardi successivi è fondamentale per misurare il Time-to-Hire e l'efficacia dei canali. Dove trovare Workday registra questo evento esplicito quando il processo 'Candidati per un lavoro' si conclude con successo. Il timestamp è disponibile nella cronologia della candidatura. Acquisisci Acquisito dal timestamp di invio della candidatura nel profilo del candidato. Tipo di evento explicit
	Offerta Accettata	Rappresenta l'accettazione formale dell'offerta da parte del candidato. Questo evento viene registrato quando il candidato completa l'attività 'Accetta offerta' nel portale Workday o quando un recruiter aggiorna manualmente lo stato.
Perché è importante Questa attività è essenziale per calcolare i tassi di accettazione delle offerte per fonte, dipartimento o recruiter. Attiva inoltre le attività pre-assunzione come il background check. Dove trovare Registrato esplicitamente quando un candidato accetta l'offerta tramite il proprio portale. L'azione viene registrata con un timestamp nella cronologia del processo di business della candidatura. Acquisisci Acquisito dal timestamp di completamento dell'attività 'Accept Offer'. Tipo di evento explicit
	Offerta Estesa	Indica l'invio formale di un'offerta di lavoro. È un evento specifico registrato quando il processo aziendale 'Crea Offerta' o 'Proponi Compenso' viene completato con successo per la candidatura in Workday.
Perché è importante Si tratta di un traguardo fondamentale usato per calcolare il Time-to-Offer e analizzare la conformità del processo di offerta. È il punto di partenza per misurare i tassi di accettazione. Dove trovare Questo evento è registrato esplicitamente nella cronologia del processo aziendale della candidatura. Il timestamp di completamento della creazione dell'offerta fornisce il tempo dell'attività. Acquisisci Acquisito dal timestamp di completamento del processo di business 'Create Offer'. Tipo di evento explicit
	`Onboarding` Avviato	Rappresenta l'avvio del processo di onboarding del nuovo assunto in Workday. Solitamente è un evento esplicito che fa parte del processo aziendale 'Assumi' o viene attivato subito dopo.
Perché è importante L'analisi del tempo trascorso tra 'Offer Accepted' e questa attività aiuta a snellire l'esperienza post-offerta del candidato. Garantisce che i nuovi assunti siano coinvolti e pronti per il loro primo giorno. Dove trovare Il processo aziendale 'Onboarding' di Workday ha un timestamp d'inizio chiaro, recuperabile dall'audit trail del record del nuovo dipendente. Acquisisci Acquisito dal timestamp di avvio del processo di business 'Onboarding'. Tipo di evento explicit
	Colloquio completato	Segna il completamento di un colloquio pianificato. Generalmente si deduce quando un intervistatore o un recruiter aggiorna lo stato del colloquio da 'Pianificato' a 'Completato' o 'Effettuato'.
Perché è importante Questa attività attiva la finestra per l'invio del feedback. Analizzare il tempo da questo punto all'invio effettivo è fondamentale per misurare la reattività degli hiring manager. Dove trovare Ricavato dall'aggiornamento dello stato dell'oggetto del colloquio pianificato o da un cambio di fase manuale per il candidato in Workday Recruiting dopo lo svolgimento del colloquio. Acquisisci Derivato dal timestamp dell'aggiornamento dello stato del colloquio o del cambio di fase del candidato dopo il colloquio. Tipo di evento inferred
	Colloquio Programmato	Rappresenta la pianificazione formale di un colloquio. In genere viene registrato quando un evento di colloquio viene creato e confermato tramite le funzionalità di scheduling di Workday.
Perché è importante Misurare il tempo tra questa attività e le precedenti aiuta a identificare ritardi nel coordinamento. Questo è fondamentale per migliorare l'esperienza dei candidati e accelerare il processo dei colloqui. Dove trovare La funzione di scheduling dei colloqui di Workday crea eventi con timestamp. Questa attività può essere ricavata dalla data di creazione del colloquio pianificato collegato alla candidatura. Acquisisci Acquisito dall'evento di creazione di un record di colloquio nel modulo Recruiting. Tipo di evento explicit
	Controllo Precedenti Completato	Indica il completamento con successo del background check. Questo evento si deduce quando lo stato del candidato viene aggiornato per riflettere il superamento dei controlli necessari, autorizzandone l'assunzione.
Perché è importante È l'ultimo controllo prima della formalizzazione dell'assunzione. Eventuali ritardi nella ricezione o registrazione di questa conferma possono posticipare la data di inizio del candidato. Dove trovare Dedotto da un aggiornamento di stato della candidatura, come il passaggio alla fase 'Pronto per l'assunzione' o 'Background Check completato'. Acquisisci Derivato dal cambio di stato che indica un background check completato e superato. Tipo di evento inferred
	Domanda Ritirata	Un evento finale in cui il candidato si ritira volontariamente dalla selezione per il ruolo. Viene registrato quando lo stato del candidato viene aggiornato a 'Withdrawn' dal candidato stesso o da un recruiter.
Perché è importante Tracciare quando e perché i candidati si ritirano è fondamentale per capire problemi di candidate experience, eccessiva durata del processo o scarsa competitività dell'offerta. Dove trovare Dedotto dal timestamp in cui l'esito del candidato viene aggiornato a 'Ritirato'. Questa operazione può essere effettuata dal candidato tramite il portale o da un recruiter. Acquisisci Derivato dal timestamp effettivo del passaggio allo stato 'Withdrawn'. Tipo di evento inferred
	Domanda Vagliata	Rappresenta il completamento della revisione iniziale della candidatura da parte del recruiter. In genere si deduce quando il candidato passa da uno stato 'Candidato' o 'Nuovo' a una fase di 'Screening' o 'In revisione'.
Perché è importante Questa attività è fondamentale per analizzare l'efficienza dello screening iniziale. Tracciare il volume e la durata aiuta a identificare subito i colli di bottiglia nel funnel. Dove trovare Dedotto dalla data effettiva del cambio di fase del candidato verso un passaggio di screening o revisione nell'audit trail del processo aziendale di 'Recruiting'. Acquisisci Derivato dal timestamp in cui la fase del candidato viene aggiornata a 'Screen'. Tipo di evento inferred
	Feedback inviato	Rappresenta il momento in cui un intervistatore invia formalmente la propria valutazione post-colloquio. Workday mette a disposizione un meccanismo specifico per inserire il feedback direttamente sul profilo del candidato.
Perché è importante Essenziale per l'analisi della tempestività dei feedback degli hiring manager. I ritardi in questa fase sono un collo di bottiglia comune; tracciarli aiuta a far rispettare gli SLA. Dove trovare Evento esplicito registrato quando viene inviato un feedback tramite l'attività 'Fornisci feedback colloquio'. Il timestamp dell'invio è loggato nel record del colloquio. Acquisisci Estratto dal timestamp di completamento dell'evento 'Provide Interview Feedback'. Tipo di evento explicit
	Verifica Antecedenti Avviata	Indica l'inizio del processo di background check per un candidato che ha accettato un'offerta. Questo evento viene solitamente dedotto dal passaggio del candidato alla fase di 'Background Check', che spesso attiva un'integrazione con un fornitore esterno.
Perché è importante Questa attività è vitale per monitorare la conformità e analizzare i ritardi tra l'accettazione dell'offerta e l'inizio dei controlli. Garantisce una transizione fluida verso l'onboarding. Dove trovare Dedotto dal timestamp del passaggio del candidato alla fase di 'Background Check' nel flusso del processo di selezione. L'audit trail della candidatura mostrerà questo cambio di stato. Acquisisci Derivato dal timestamp effettivo del passaggio alla fase 'Background Check'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i dati da Workday Recruiting

Fasi

Accesso a Workday: acceda al Suo tenant Workday con un account utente che disponga delle autorizzazioni per la creazione di report personalizzati e l'accesso ai dati di recruiting.
Creazione di un report personalizzato: vada all'attività 'Create Custom Report'. Selezioni 'Advanced' come tipo di report e abiliti l'opzione 'Enable as Web Service'. Per l'origine dati, utilizzi una fonte indicizzata come 'All Job Applications' per ottenere prestazioni migliori.
Definizione dell'oggetto di business primario: imposti l'oggetto di business primario su 'Job Application'. Questo oggetto fungerà da base per il report e come identificatore del caso.
Aggiunta delle colonne dati: aggiunga i campi obbligatori e consigliati alla griglia delle colonne del report. Inserisca 'Job Application' per JobApplicationId. Per altri attributi come 'Recruiter' e 'Hiring Manager', dovrà aggiungerli dagli oggetti di business correlati collegati a Job Application.
Creazione di campi calcolati per le attività: questo è il passaggio più critico. Per ognuna delle 15 attività, dovrà creare due campi calcolati: uno per il nome dell'attività e uno per il timestamp dell'evento. La logica di questi campi è dettagliata nella sezione Query. Ad esempio, per acquisire 'Offer Extended', creerà un campo che verifichi il completamento del processo di business 'Propose Compensation' e un altro campo per estrarre il timestamp di completamento di quel processo.
Aggiunta dei campi calcolati al report: aggiunga tutti i campi calcolati appena creati (30 in totale, 15 per i nomi delle attività e 15 per i timestamp) come colonne nel Suo report. Il report sarà in un formato 'wide', con una riga per ogni candidatura e molte colonne che rappresentano le potenziali attività.
Configurazione delle opzioni Web Service: nella scheda 'Web Service' della definizione del report, si assicuri che la casella di controllo 'Enable as Web Service' sia selezionata. Qui può visualizzare il namespace e l'URL del report. Prenda nota del 'Namespace' per un uso successivo.
Impostazione delle autorizzazioni: condivida il report con un Integration System User (ISU) o un gruppo di sicurezza specifico che verrà utilizzato per chiamare l'endpoint RaaS. Questo utente deve disporre delle autorizzazioni per il dominio dell'origine dati, ad esempio 'Recruiting: Job Applications'.
Esecuzione e test del report: esegua il report dall'interfaccia utente di Workday per verificare l'output. Controlli che il numero di righe sia ragionevole e si assicuri che i campi calcolati vengano popolati correttamente per alcune candidature di esempio.
Pianificazione dell'estrazione: utilizzi uno strumento di pianificazione esterno o un middleware (come MuleSoft, Boomi o uno script personalizzato) per chiamare l'URL RaaS del report su base regolare. Lo strumento dovrà gestire la chiamata API SOAP o REST di Workday con l'autenticazione appropriata.
Trasformazione dei dati: l'output grezzo della chiamata RaaS sarà un file XML o CSV in formato wide. È necessario implementare un passaggio di trasformazione nel middleware o in un linguaggio di scripting (come Python) per eseguire l'unpivot di questi dati. Lo script dovrà scorrere ogni riga (candidatura) e creare una nuova riga nell'event log finale per ogni coppia attività/timestamp non vuota, ottenendo un formato 'long' con tre colonne principali: JobApplicationId, ActivityName e EventTime.

Configurazione

Tipo di report: utilizzi sempre 'Advanced' per consentire l'uso di campi calcolati complessi e l'accesso agli oggetti di business correlati.
Origine dati: utilizzi una fonte di dati indicizzata come 'All Job Applications' per garantire un'esecuzione efficiente del report. Eviti fonti non indicizzate per dataset di grandi dimensioni.
Filtro intervallo di date: è fondamentale applicare un filtro sul campo 'Application Date' dell'oggetto di business Job Application. Inizi con un intervallo ridotto, come gli ultimi 3-6 mesi, per gestire il volume dei dati e le prestazioni del report.
Oggetto di business primario: l'oggetto primario deve essere 'Job Application' per garantire che JobApplicationId funga da identificatore del caso.
Abilitazione Web Service: deve selezionare 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 Integration System User (ISU) dedicato. Tale ISU deve disporre dei permessi del gruppo di sicurezza per accedere ai domini dati richiesti, tra cui 'Recruiting: Job Applications', 'Business Process Transactions' e 'Worker Data'.
Formato di output: sebbene Workday offra diversi formati di output (XML, CSV, JSON), l'XML (nello specifico il formato 'Simple XML') è spesso il più affidabile per l'estrazione di dati strutturati tramite API.

a Query di Esempio config

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

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

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

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

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

Fasi

Configurazione dell'accesso a Workday: crei un Integration System User (ISU) in Workday. Conceda a questo utente l'accesso ai domini di sicurezza necessari per l'API di Recruiting. I domini chiave includono 'Worker Data: Public Worker Reports', 'Job Application' e 'Recruiting: Reports'.
Identificazione dell'endpoint API: individui l'endpoint della REST API per l'operazione 'Get Job Applications' nel Suo tenant Workday. L'URL segue solitamente questo formato: https://[vostro_tenant_host]/ccx/api/v1/[vostro_nome_tenant]/recruiting/jobApplications.
Configurazione dell'ambiente Python: si assicuri che Python sia installato. Installi le librerie necessarie usando pip: pip install requests pandas.
Sviluppo dello script di autenticazione: nel Suo script Python, implementi l'autenticazione di base utilizzando le credenziali dell'ISU creato al punto 1. Il nome utente e la password verranno inviati nell'intestazione della richiesta.
Implementazione della logica di richiesta API: scriva la funzione per chiamare l'endpoint 'Get Job Applications'. Utilizzi i parametri di richiesta per filtrare i dati, come updatedSince per recuperare le candidature modificate dopo una certa data. Questo è fondamentale per gestire il volume dei dati.
Gestione della paginazione API: l'API di Workday restituisce un numero limitato di record per richiesta. Il Suo script deve controllare la risposta per un conteggio total e un link alla pagina next o un parametro di offset, ed eseguire un ciclo su tutte le pagine per recuperare il dataset completo.
Definizione della mappatura delle attività: crei un dizionario di mappatura o una serie di istruzioni condizionali nel Suo script. Questa logica tradurrà gli stati dei processi aziendali e le fasi di recruiting di Workday (ad es. 'Screen', 'Interview', 'Offer', 'Hire') nei nomi delle attività richiesti (ad es. 'Application Screened', 'Candidate Moved To Interview').
Trasformazione dei dati delle candidature: per ogni candidatura recuperata dall'API, analizzi l'audit trail o i dati della cronologia delle fasi. Questa cronologia contiene la sequenza di fasi, disposizioni ed eventi dei processi aziendali con i relativi timestamp.
Generazione delle righe dell'Event Log: iteri attraverso la cronologia di ogni candidatura. Per ogni evento storico rilevante che corrisponde alla Sua mappatura delle attività, crei un dizionario che rappresenta una riga nell'event log finale. Popoli JobApplicationId, ActivityName, EventTime e gli altri attributi richiesti.
Aggregazione e strutturazione dei dati: raccolga in un'unica lista tutte le righe dell'event log generate da tutte le candidature.
Creazione ed esportazione del 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. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti di ProcessMind (ad es. CaseId, Activity, Timestamp).
Revisione e caricamento: apra il file CSV finale per verificarne la correttezza e la completezza prima di caricarlo nello strumento di Process Mining.

Configurazione

Integration System User (ISU) di Workday: è richiesto un ISU con una password complessa e senza scadenza. Sono necessarie le autorizzazioni per i domini di sicurezza 'Recruiting' e 'Worker Data' per accedere ai dettagli delle candidature e dei candidati.
Endpoint e versione dell'API: è necessario utilizzare l'endpoint corretto della REST API per il Suo tenant Workday. È importante specificare la versione dell'API nella richiesta per garantire un comportamento coerente.
Filtro per intervallo di date: lo script dovrebbe utilizzare un filtro temporale (ad es. updatedSince) per limitare la query a un arco di tempo gestibile. Per le estrazioni iniziali, si consiglia un periodo di 3-6 mesi. Per i successivi caricamenti delta, utilizzi il timestamp dell'ultima estrazione riuscita.
Limite di paginazione: presti attenzione al parametro limit nell'API, che controlla quanti record vengono restituiti per pagina. Il massimo tipico è 100. Lo script deve essere progettato per gestire questa condizione effettuando più richieste impaginate.
Campi di risposta: per migliorare le prestazioni, può specificare quali campi restituire utilizzando un parametro fields o simile, se l'API lo supporta. Ciò riduce le dimensioni del payload della risposta API.
Configurazione della mappatura delle attività: la logica centrale dello script è la mappatura dalle fasi di Workday alle attività definite. Questa potrebbe dover essere personalizzata in base alla configurazione specifica del processo di Workday Recruiting della Sua organizzazione.

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

Fasi

Prerequisiti e configurazione: si assicuri di disporre di uno strumento ETL o iPaaS di terze parti con licenza, come CData, MuleSoft o una piattaforma simile, con il relativo connettore Workday installato. Verifichi di avere le credenziali per un Integration System User (ISU) di Workday con i permessi API necessari per i domini Recruiting e Staffing.
Configurazione della connessione Workday: nel Suo strumento ETL, crei una nuova connessione a Workday. Fornisca l'URL del tenant Workday, la versione dell'API e le credenziali ISU (ad esempio, nome utente e password o token OAuth 2.0). Testi la connessione per assicurarsi che vada a buon fine.
Esplorazione dello schema dei dati: utilizzi il browser dello schema o l'esploratore delle fonti dati nel Suo strumento ETL per visualizzare gli oggetti Workday disponibili tramite il connettore. Questi sono solitamente presentati come tabelle o viste, come Job_Application, Job_Requisition e Candidate_Stage_History. Prenda confidenza con i campi e le relazioni disponibili.
Identificazione degli oggetti dati chiave: per questa estrazione, avrà bisogno principalmente dei dati degli oggetti relativi a candidature, cronologia dei candidati, colloqui, offerte e assunzioni. I nomi esatti dipenderanno dal connettore, ma cerchi gli oggetti che rappresentano queste entità principali.
Sviluppo della query SQL: crei un nuovo job di estrazione dati o una pipeline. Utilizzi un passaggio di trasformazione SQL per eseguire una query sulla connessione Workday. Copi e incolli la query SQL fornita in questo passaggio. La query è progettata per raccogliere dati da più oggetti Workday e unirli in un unico formato di event log.
Parametrizzazione della query: modifichi la clausola WHERE della query per includere i parametri per l'intervallo di date (ad esempio, startDate e endDate). Configuri questi parametri nel Suo job ETL in modo da poter cambiare facilmente la finestra di estrazione senza modificare il codice.
Esecuzione del job di estrazione: esegua il job ETL configurato. Lo strumento si connetterà a Workday, eseguirà la query SQL tramite l'API e recupererà i dati in un'area di staging o in memoria.
Revisione e convalida dei dati: prima di scrivere l'output finale, utilizzi la funzione di anteprima dello strumento ETL per ispezionare i risultati. Verifichi che il numero di righe sia congruo, che tutte le colonne siano popolate correttamente e che siano presenti le diverse attività.
Configurazione della destinazione: definisca la destinazione per i dati estratti. Di solito si tratta di un file CSV da caricare su ProcessMind. Configuri il nome del file, il delimitatore (virgola) e la codifica (UTF-8).
Finalizzazione ed esportazione: esegua il job di estrazione completo per generare il file CSV finale. Si assicuri che le intestazioni delle colonne nel file di output corrispondano agli attributi richiesti: JobApplicationId, ActivityName, EventTime, RecruiterName, HiringManager, ApplicationSource, Department e ApplicationStatus.

Configurazione

Credenziali del connettore Workday: la connessione richiede l'URL del tenant Workday e un Integration System User (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 Web Service: il connettore potrebbe richiedere di specificare quali Workday Web Service esporre. Si assicuri che i servizi relativi a Recruiting, Staffing e Human Resources siano abilitati per accedere a tutti gli oggetti dati necessari.
Intervallo di date: per gestire le prestazioni e il volume dei dati, è fondamentale filtrare l'estrazione per un periodo di tempo specifico. Consigliamo un caricamento iniziale di dati relativi a 3-6 mesi, seguito da caricamenti incrementali giornalieri o settimanali. Questo viene gestito tramite la clausola WHERE nella query SQL.
Filtri sull'ambito dei dati: se desidera analizzare il processo solo per alcune parti dell'organizzazione, consideri l'aggiunta di filtri nella clausola WHERE per campi come Società, Centro di costo o Organizzazione di supervisione.
Versione API: alcuni connettori richiedono di specificare la versione dell'API Workday. È preferibile utilizzare una versione recente e supportata per garantire l'accesso agli oggetti dati e alle funzionalità più recenti.
Considerazioni sulle prestazioni: le estrazioni complete di dati da Workday possono richiedere molte risorse. Programmi i processi più corposi durante le ore non di punta. Per l'analisi continua, implementi una strategia di caricamento incrementale basata su un timestamp 'last modified' per estrarre solo i record nuovi o aggiornati.

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

Il Suo template per i dati di Recruitment & Talent Acquisition

Il Suo template per i dati di Recruitment & Talent Acquisition

Attributi di Recruiting e Talent Acquisition

Attività di Recruiting e Talent Acquisition

Guide all'Estrazione

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

Fasi

Configurazione

a Query di Esempio config

Estrazione tramite API di Workday Recruiting via script Python

Fasi

Configurazione

a Query di Esempio python

Estrazione tramite strumento ETL con connettore Workday

Fasi

Configurazione

a Query di Esempio sql

Pronto per iniziare?

Elimini i colli di bottiglia nelle assunzioni: ottimizzi oggi la Sua Talent Acquisition

Il Suo template per i dati di Recruitment & Talent Acquisition

Il Suo template per i dati di Recruitment & Talent Acquisition

Attributi di Recruiting e Talent Acquisition

Attività di Recruiting e Talent Acquisition

Guide all'Estrazione

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

Fasi

Configurazione

a Query di Esempio config

Estrazione tramite API di Workday Recruiting via script Python

Fasi

Configurazione

a Query di Esempio python

Estrazione tramite strumento ETL con connettore Workday

Fasi

Configurazione

a Query di Esempio sql

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Elimini i colli di bottiglia nelle assunzioni: ottimizzi oggi la Sua Talent Acquisition