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

Community

Connector Improvement: Workday Financial Management - Add Workday ID (WID) to JOURNAL_ENTRY_LINE table

Answered
Tyler Sauerbrei User

Connector Name: Workday Financial Management

Description of Request: Please expose the native Workday ID (WID) as a column in the JOURNAL_ENTRY_LINE core table.

The Problem: Currently, the connector uses an internal Fivetran-generated INDEX based on the sequence of <Journal_Line> elements in the Get_Journals API response. Because the native LINE_ORDER field is frequently NULL for Operational Journals, there is no way to reliably join core table journal lines with other Workday data sources (such as RaaS reports or other Workday Web Services) that identify lines by their unique 32-character Workday ID (WID).

Joining solely on the Header ID (JOURNAL_ENTRY_ID) is not a viable workaround as it creates a Cartesian product/fan-out when a journal entry contains multiple lines.

Proposed Solution: Map the Journal_Line_Reference WID from the Journal_Entry_Line_DataType in the Get_Journals SOAP response to a new column (e.g., JOURNAL_LINE_WID) in the JOURNAL_ENTRY_LINE table.

Business Value / Impact:

  • Auditability: Ensures 1:1 data integrity between Snowflake and Workday.

  • Extensibility: Allows users to join Fivetran-synced core tables with custom Workday RaaS reports and external datasets.

  • Reliability: Eliminates reliance on the INDEX column, which is sensitive to changes in API response sorting and cannot be cross-referenced outside of Fivetran.

Please sign in to leave a comment.

Comments

6 comments

Date Votes
  • Official comment
    Tom Jose Fivetranner

    Hi Tyler,

    Apologies for the delayed response. I wanted to make sure I came back to you with something substantive rather than a holding reply.

    After a thorough investigation with our engineering team, including reviewing the Workday Financial Management SOAP API schema up to the latest version (v42.1), we've confirmed that the Journal_Line_Reference WID is not exposed in the Get_Journals API response at the line level. This means it isn't something Fivetran is overlooking in the mapping. Workday simply doesn't surface it through their SOAP Web Service. You can verify this in the official API documentation here: https://community.workday.com/sites/default/files/file-hosting/productionapi/Financial_Management/v42.1/Get_Journals.html

    I understand this isn't the answer you were hoping for, and I want to acknowledge that the gap you've identified is real and your auditability use case is completely valid.

    On the near-term front: I noticed JOURNAL_LINE_NUMBER is already present in your Fivetran JOURNAL_ENTRY_LINE table. Unlike INDEX, this is a system-assigned number from Workday itself. If this field also appears in your RaaS report, it may already give you a reliable join key without any connector changes. Could you check and try using it as a join key, and let me know how that goes?

    On the longer-term front: Workday's newer REST-based query interface (WQL) appears to expose journal line level data including the WID, which the SOAP API does not. Fivetran has a WQL connector currently in private preview and this could be worth exploring as a potential path to get the WID into your destination natively. I want to be upfront that this is still early access and I haven't fully validated this specific use case yet but if you're open to it, I'd be happy to investigate further with you.

    Thanks for your patience on this.

    Tom

  • Tyler Sauerbrei User

    Important Note: This is a critical requirement for financial auditability, not just a "nice to have" feature.

  • Tom Jose Fivetranner

    Hi Tyler,

    Thanks for submitting this detailed feature request. I really appreciate how clearly you've documented both the technical gap and the business impact.

    What I understand: You need the native Workday ID (WID) for individual journal lines exposed in our JOURNAL_ENTRY_LINE table. Currently, the connector provides:

    • INDEX - a Fivetran-generated sequence number based on API response order

    • LINE_ORDER - frequently NULL for Operational Journals

    Neither of these allows you to reliably join journal lines with other Workday data sources (like RaaS reports) that reference lines by their unique 32-character WID. Joining on just the header-level JOURNAL_ENTRY_ID creates a Cartesian product when journals have multiple lines.

    Next Steps: I'm working with our Workday connector engineering team to investigate:

    1. Whether the underlying Workday API response includes a WID for individual journal lines that we're not currently mapping i.e. whether the Journal_Line_Reference WID is consistently available in the Get_Journals response and what would be involved in exposing it.

    2. Any potential schema considerations

    I'll follow up once I have more clarity on the technical feasibility. In the meantime, if you have any additional context such as specific RaaS reports you're joining to or example WIDs you're working with, please feel free to share and I'll factor that into our investigation.

    Thanks again for the thorough documentation, the auditability use case is well articulated.

    Thanks,

    Tom

  • Tyler Sauerbrei User
    Hi Tom,

    Thank you for the quick response and for looking into this with the engineering team. The ability for us to join this data is critical for our internal financial reporting needs, as we currently have no reliable way to reconcile core table data with our supplemental reports.

    To assist with your investigation, I have attached three screenshots from our environment that illustrate the gap:

    1. Core_Journal_Entry_Line.png: Shows the current Fivetran schema where INDEX is the only line-level identifier, and LINE_ORDER is NULL (as expected for Operational Journals).

    2. RaaS_Detail.png: This is a Workday RaaS report for the exact same transaction. You can see the column CF_Journal_Line_WID (e.g., 7c2d6aa0c3d29000ed70b8ab8eb20000). This confirms that Workday assigns a unique WID to every line, regardless of whether it is an Operational Journal.

    3. RaaS.png: Shows the Workday UI for the same Journal Entry, confirming the specific Workday ID exists at the line level.

    The Gap: While Fivetran generates a sequential INDEX starting at 0, that value doesn't exist in Workday's UI or RaaS reports. Conversely, the WID exists in the Workday API and UI, but is missing from the Fivetran core table. Without the WID in the core table, we have no reliable way to join these two datasets.

    If the Get_Journals API response already contains the Journal_Line_Reference (WID), mapping it to a new column would solve this auditability issue immediately.

    1. Core_Journal_Entry_Line.png:

    2. RaaS_Detail.png:

    3. RaaS.png:

    Do you have an update from the investigation with the Workday connector engineering team?
     
    Thanks Tom,
  • Tyler Sauerbrei User

    Hi Tom,

    I wanted to follow up on this request as we move further into our project.

    As mentioned previously, the absence of the JOURNAL_LINE_WID in the core table is currently a blocker for our financial reporting. Without a persistent ID to join our core tables and RaaS reports, we are forced to rely on manual workarounds that bypass the automation benefits of Fivetran.

    Given the screenshots provided last week showing the WID is natively available in the Workday UI and RaaS (and therefore the API), has the engineering team been able to confirm a timeline for adding this mapping?

    We are eager to move forward with a scalable solution.

    Thanks for your help.

    Tyler

  • Tyler Sauerbrei User

    Hi Tom,

    Thank you for the detailed investigation and for confirming the limitations of the Workday v42.1 SOAP API.

    I would like to move forward with the WQL connector Private Preview. If WQL can indeed surface the line-level WID, it would help solve our auditability gap for and provide a much more robust architecture for our Snowflake destination.

    Could you please let me know the next steps to get started? Specifically:

    1. What is the process for gaining access to the Private Preview?

    2. Do you have any documentation or a sample schema for the WQL-based JOURNAL_ENTRY_LINE equivalent?

    Looking forward to exploring this path with you and the engineering team.

    Thanks Tom,