Web service, business object, operation
The words are Workday's. A web service is one WSDL, such as Financial_Management. An operation is one call in it: Get_ operations pull records into Snowflake, Submit_ and Put_ operations push records to Workday. The app groups operations by the business object they serve: Get Journals and Submit Accounting Journal both serve Journals.
A business object is on or off as a whole; its operations never run alone. Switching it on creates its IN_* and OUT_* tables, gives any operation that was never configured the recommended table prefix, key and load type, pairs the submit with the extract so it is verified, and starts every part. If any part cannot start, nothing starts and the page says why. Switching it off stops every part and keeps the configuration.
The catalog shows business objects in plain words. Workday operation names appear only on the Operation page.
Spec
The published description of an operation, generated from Workday's WSDL and documentation: elements, cardinality, types, enumerations, Workday's own per-field validation messages. An operation points at exactly one spec version. The spec is what lets the app build a request from a staging row, flatten a response into tables, and map a Workday fault back to the cell it means.
Record
One root row and its child rows: a journal header and its lines, an invoice and its lines. Workday accepts or rejects a record whole. One bad line fails that record and only that record. A file with many headers is many records.
Lines and attributes
A Workday record repeats in two ways, and the app treats them differently on purpose.
Lines are the rows people sum, order and reconcile: journal lines, invoice lines, split lines. Only lines become tables, such as OUT_JOURNAL_JOURNAL_ENTRY_LINE_DATA and IN_JOURNAL_JOURNAL_ENTRY_LINE_DATA.
Attributes are multi-valued facts about their parent: worktags, addresses, phone numbers, attachments, lists of references. An attribute is one *_JSON column on the parent row, so joining two of them can never multiply rows. Unnest it in a view when you want rows; the app generates one such view per attribute.
The submit decides. The repeating elements of the Submit_ request that carry amounts, quantities or a line order are the lines, and the matching extract keeps exactly those as tables, under the same names, with the record's header flattened onto one root row. A business object with no submit applies the same rule to its extract. The Spec tab on the Operation page shows what was decided.
In a template or staging table an attribute is written as a JSON array of objects keyed by Workday element name, with references as {"Company_Reference_ID": "C1"}. An attachment is one such object with the file name and content type as @Filename and @Content_Type and the file body base64 encoded in File_Content.
Upload, submit, extract, correction
Four words on screen.
- An upload is a file of records into this app, by hand on the Upload page or dropped on the inbox stage. One upload becomes one submit.
- A submit is records going to Workday, each answered with the new record's ID or the field to fix. A submit can be submitted again for records still waiting.
- An extract is records Workday sends here, as one run with a window.
- A correction is a new submit made of an earlier one's failed records, fixed in the app or by a correction upload.
Internally a submit is a batch that records its source (upload, file, SQL, scheduled, correction) and a reference to it, so every record stays traceable to where it came from.
Scope
The scope field is the column that names the company or agency a record belongs to, usually a Company reference ID. A user may only submit records for the scopes they are entitled to, and only sees batches and files in those scopes. Administrators and users entitled to * see everything. A file dropped under a scope folder binds its whole batch to that scope.
Source key
Every root row carries a SRC_REF_ID, your own identifier for the record. The app writes it into the record's own ID field in the request (the <Object>_ID under the data element, or a memo where the object has no such field) wherever the row left that field blank. That is what lets a record be found again after Workday's bulk import, what stops a record that already succeeded from being sent twice, and what joins your source rows to Workday's IDs.
Schedule
When an extract runs, written as JSON. {"rules": [{"at": ["01:00"]}]} runs it daily at one. Rules can name weekdays, several times a day, or an interval. An extract can also list submits in Run after, so it runs once a batch for them completes and Reconcile has fresh data.
Highwater
The end of the last successful incremental window. The next scheduled run starts from there. An ad hoc run with its own window leaves the highwater alone.
Retention
How long extracted rows and submitted staging rows are kept: a default under Admin, overridden per business object on the Operations page; 0 keeps everything. The heartbeat purges once a day and records a purge run in History. Batch headers stay, stamped with when they were purged; the current version of a merged record is never removed; raw request and response XML follows its own shorter retention.
Tuning
Whether runs adjust how hard they lean on Workday. Every business object starts automatic. The configured page size and max workers of an extract and the parallelism of a submit are ceilings: a run steps down one level when a call fails after its retries or when a level moved no more records per second than the one below, climbs back one level after three clean batches, and waits longer each time the same level gives way again. Every decision is logged, and the Operation page shows the levels the next run starts at. Switch a business object to as configured and every run uses the configured values exactly.
Heartbeat
One serverless task that drives everything on a clock: scheduled extracts, inbox scans, batching of staged rows, polling of imports in flight, entitlement sync, the daily purge. Every piece of work it starts runs in its own one-shot task, so a page refresh never loses a running job, and nothing holds a warehouse while idle.