Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Connector Improvement: Recruiting Process History SCD2

Answered
Vaishnavi Senthil User

Similar to worker history, is it possible to have an SCD 2 for job application, job position, job requisition and the onboarding process? Currently we have the snapshot of status as of when the data gets refreshed but we need to preserve history (all the different stages the process went through and their start/end dates) to be able to report metrics like Time to Interview, Time taken to fill a position/requisition, time taken to clear background check etc. These metrics are key to measure and enhance our recruitment process.

Please sign in to leave a comment.

Comments

3 comments

Date Votes
  • Official comment
    Amanda Wong User

    Hi Vaishnavi,

    Thank you for sharing this suggestion regarding SCD2 support for recruiting process objects. Which connector would like to see this change on?

    Your additional context will help us evaluate the best approach to support your requirements.

    Thanks,
    Amanda

  • Vaishnavi Senthil User

    Hi Amanda,

    Sorry for the delayed response, just now seeing your reply. Workday HCM is the connector we are looking at.

    Please let me know if there are any other questions.

    Vaishnavi

  • Tom Jose Fivetranner

    Hi Vaishnavi,

    Thanks for clarifying that this is for the Workday HCM connector.

    Right now Workday’s public APIs do not expose a reliable change-history (SCD Type 2) feed for recruiting objects such as Job Application, Job Requisition, Job Position, or Onboarding. Because those APIs return only the current snapshot, the connector can’t natively preserve every intermediate recruiting stage the way we do for Worker History.

    We know this limits the ability to calculate metrics like time-to-interview or time-to-hire, so we’re actively exploring options, both with Workday’s product team and internally, to see whether there is a feasible, supported workaround (for example, a combination of report-as-a-service endpoints or a log-based approach). If we identify an approach that provides reliable historical coverage and acceptable performance, we’ll post an update here.

    We don’t have a timeline yet, but I’ll keep this thread updated as soon as we have concrete progress to share. Please feel free to add any additional context about which recruiting objects or fields are highest priority on your side; that feedback helps us when evaluating potential solutions.

    Thanks for your patience,
    Tom