Before anything is sent
Every batch is checked in the app before a single call to Workday. Three layers of checks run, and every error names the record, the table, the row and, where it can, the column and line:
- Spec rules, generated from the WSDL and read-only: required elements, sizes, types, enumerations.
- Reference lookups, generated from the extracts that are on: a company, supplier, cost center or worktag ID must exist in the extract before a record that names it is sent.
- Your rules, written per operation on the Operations page: anything the tenant's own configuration demands, from a mandatory memo to a balanced journal.
A record with any error waits for correction. The rest are ready and go. Nothing is half sent.
Writing a rule
Rules live per operation. Each one names a table and a column, a check type and a parameter.
| Check | Parameter |
|---|---|
REQUIRED |
none |
REQUIRED_ANY |
JSON list of columns, one must be filled |
MAX_SIZE, EXACT_SIZE |
a number |
ALLOWED_CHARACTERS |
alphanumeric, numeric, alpha or money |
REGEX |
a pattern the whole value must match |
DATE |
a format such as YYYY-MM-DD |
TYPE |
date, datetime, boolean, decimal or integer |
IN_LIST |
JSON list of allowed values |
DEPENDENT_FIELD_NON_NULL |
another column that must be filled when this one is |
DEPENDENT_FIELD_NULL |
another column; this one may be blank only when that one is filled |
LOOKUP |
{"view": {"prefix": "COMPANY", "suffix": "company"}, "column": "..."} to require the value to exist in an extract |
LOOKUP_LIST |
the same, plus "id_type": every entry of that type in a reference list such as the worktags cell must exist there |
Aggregate checks look across a record's child rows and fail the whole record. They live on the root table, and the field is a label such as LINES:
| Check | Parameter |
|---|---|
BALANCED |
{"table": "journal_entry_line_data", "debit": "DEBIT_AMOUNT", "credit": "CREDIT_AMOUNT"} |
SUM_EQUALS |
{"table": "<child>", "column": "<col>", "value": 0} |
MIN_CHILDREN |
{"table": "<child>", "min": 1} |
Rules check text. Every staging column is text, so a rule sees exactly what the file or the pipeline wrote, and the app converts the value to Workday's type at send time.
What Workday says
After the rules, Workday validates each record at submit time. A validation fault from Workday carries one message per problem, with Workday's own wording and an XPath into the request. The app maps the XPath back through the spec to the staging table, the row and the column, so the error lands on the cell it means, inside a line's JSON cell too. A processing fault, which Workday raises for the record as a whole, lands on the record.
Submit_ and Put_ sometimes accept a record and still answer with an exception: a journal created but not balanced, an invoice that exists but cannot complete. The record then has a Workday ID and a critical or error exception. The app shows it as failed with its Workday ID, and its correction updates the record Workday holds instead of creating a second one.
Every error code
Every rejected record carries one or more errors, each with a code, a message, the table and row it belongs to, and where the engine could tell, the column and line. The code says who found it. History and this page use the same table.
| Code | Found by | Points at |
|---|---|---|
| REQUIRED, REQUIRED_ANY, MAX_SIZE, EXACT_SIZE, ALLOWED_CHARACTERS, REGEX, DATE, TYPE, IN_LIST, DEPENDENT_FIELD_NON_NULL, DEPENDENT_FIELD_NULL, LOOKUP, LOOKUP_LIST | a validation rule, before send | exact row and column |
| SUM_EQUALS, BALANCED, MIN_CHILDREN | an aggregate rule across a record's lines, before send | the record |
| ENTITLEMENT | scope check, before send | the record's scope column |
| KEY, DUPLICATE, MISSING_ROW, BUILD | the app, before send: a missing key, a source key already sent, a line without its parent, a cell that could not be converted | the row, and for BUILD the column |
| VALIDATION | Workday, a validation fault | table, row and column, from Workday's XPath |
| FAULT | Workday, a processing fault | the record |
| ERROR, CRITICAL | Workday, beside the new record's ID | the record, which exists and cannot complete; its correction updates it in place |
| WARNING | Workday, beside the new record's ID | informational; the record succeeded |
| TRANSPORT | the network | the record where the batch stopped; the rest stay pending |
On the Detail page the same codes roll up into four categories a person can act on: checked here, Workday rejected, Workday warning and connection.
Errors from an import
A batch sent through Workday's bulk import is answered by Workday's import process messages. Each names a refused record by its position in the call, and the app turns that back into the record. Where the message quotes the offending value, the app locates it in the record's cells, inside JSON attributes too, and names the column and line. The import reports only what it refuses; see Getting records into Workday for what to keep in rules because of that.