Getting records into Workday

Which Workday operation sends

Workday offers up to three families of writer per business object. Submit_ (or Put_ for objects without a business process) sends one record per call and answers at once with the record's Workday ID, or with the field to fix; a record may hold up to a thousand lines, five thousand for a customer invoice. Bulk_Import_ sends many records in one asynchronous call and answers with a process reference; the outcome arrives a little later through Workday's import process reports, which name a refused record by its position in the call.

The app uses both. A business object's writer is the record-at-a-time call. A batch goes through the import when the submit's Configure form sets Load method to Workday import, or, under Automatic, when the batch would take longer than the threshold under Admin one record at a time, judged by the writer's measured rate from its last submits. An imported batch shows as Workday is importing in History until the heartbeat has read every process. Each refused record carries Workday's message, with the column named where the message quotes the value, and accepted records are read back by their source key so Reconcile joins them as usual.

Three things differ about the import, and the app handles each:

• The import runs under the integration user's name and password even when the app signs in with OAuth, because Workday's import process signs in again as the caller. Keep those credentials in the secret or records go one at a time.
• The import needs its own Workday grant. The setup panel lists it as optional, and the app falls back to one record at a time when the tenant refuses it.
• The import reports only what it refuses. A record Workday accepts with a critical exception, such as a journal created unbalanced, comes back clean, where Submit_ would report the exception on the spot. Keep the rules that cover those conditions on, such as BALANCED on journals, and they are caught before the send.

Three paths, one set of checks

A pipeline, a file share and a person with a spreadsheet all feed the same staging tables and go through the same validation. The Feed tab of each submit shows the exact table names, inbox folder and template for that operation.

SQL

Write rows into the business object's OUT_* tables with any tool: SQL, Snowpipe, dbt, a stream. The tables exist from the moment the business object is on.

• Leave BATCH_ID empty; the app fills it when it batches the rows.
• Set SRC_REF_ID on every root row, your own identifier for the record.
• Link child rows to their parent by OUT_PARENT_ROW_ID and order them with OUT_SEQ. Workday locates a line by its position, so the order matters.
• Set SOURCE_REF to name your pipeline, so every record stays traceable to where it came from. SOURCE_TYPE defaults to sql.

Every business column is text. Rules check the text and the app converts it to Workday's type at send time, so a date is 2026-03-31 and a decimal is 100.00, as you would write them in a file.

With Staged rows: batch on the schedule, the heartbeat batches and submits them. Otherwise press Batch staged rows and validate on the Feed tab, or call the procedure from SQL:

CALL CREATE_BATCH('Financial_Management', 'Submit_Accounting_Journal', 'nightly-journals');

File drop

Drop a CSV or XLSX on the inbox stage under the business object's folder:

@<app>.DATA.WD_INBOX/<web service>/<business object>/[<scope>/]<file>

The folder is the whole contract; nothing is read from the file name. The second folder is the business object as the Operations page names it, with underscores for spaces (Journals, Supplier_Invoices), matched regardless of case. The file goes to that business object's submit, so the folder stays the same when the Workday operation behind it changes. When the submit has a scope field, the third folder is the scope, and every record in the file must belong to it: a blank scope value is filled from the folder, a different value fails that record.

• A CSV is the root table. Its header row is the template's column names, SRC_REF_ID included.
• An XLSX has one sheet per table, named after the table.
• Child tables may also arrive as sibling CSVs named <stem>__<table>.csv next to <stem>.csv. They are attached when the root file loads.
• Put files with the Snowflake CLI, the Snowsight stage uploader, or any connector. An SFTP bridge or cloud landing zone can be bound as an external stage and listed under Admin.

The heartbeat registers new files every tick and loads each one as a batch. A file that cannot be parsed, has no root rows, or lacks a key column is rejected whole with one reason. A file whose rows fail validation is loaded, and the failing records wait for correction while the rest can go. Dropped files: hold for approval, the default, keeps a checked file until someone submits it from History; auto submit when valid sends it at once.

A result file is written back beside the drop, in results/<stem>.result.csv, with one row per record: status, Workday ID, and the messages. It is written after validation and again after the submit finishes, so a system that only speaks files learns what happened. The same content dropped twice is skipped; the same name with new content is a new batch.

Upload

The Upload page, and the Feed tab of the submit for administrators, takes a file directly. Download the template there: one sheet per table, root first, child rows naming their parent in PARENT_KEY (the root's SRC_REF_ID, or the parent row's ROW_KEY). The batch is checked at once and opens in History.

Two-part IDs

Some Workday IDs are unique only inside a parent. A Ledger_Account_ID belongs to an account set, and Workday rejects it without one. The staging table and the template carry a companion column beside such an ID, such as LEDGER_ACCOUNT_REFERENCE_LEDGER_ACCOUNT_ID_PARENT, holding the Account_Set_ID. Leave it blank and the id_parent_defaults setting on Admin fills it, which suits a tenant with one account set. The WID form of a reference never needs a parent. Extracts keep the parent too.

What happens to a batch

1. Checked. Every validation rule runs, aggregate rules look across a record's lines, scope is checked, and reference IDs are looked up in the extracts that are on. A record with any error waits; the rest are ready. Nothing has reached Workday.
2. Submitted. Ready records go to Workday, in waves of the parallelism the tuner has settled on, each on its own connection. A transport failure ends the batch after the wave it happened in; the records that never left stay pending and the next Submit sends them. Or, over the threshold, the batch goes through the import in chunks and waits for Workday.
3. Verified. The accepted records of each wave are read back from Workday in one call, so History shows Workday's status for the new record at once. The Workday ID is the join key for reconciliation.
4. Answered. Every record has its own result row: succeeded with its Workday ID, failed with its errors mapped to the table, row and column, or pending. The result file is written back for a dropped file.

Records are matched by SRC_REF_ID. One that already succeeded is skipped unless the batch option Resend records that already succeeded is set, so a file dropped twice cannot create a record twice.