Find the run: View Background Process

Every EIB launch, scheduled or manual, opens the View Background Process page. Click Refresh until Percent Complete reaches 100 or the Status field settles on a final value. The statuses you'll see are Processing, Completed, Completed With Errors, Completed With Warnings, Failed, Aborted, and Not Run due to Exceptions on Future Process.

If you've navigated away, you don't have to remember to bookmark the run. Search with the intsys: prefix to find the integration system itself, run the Integration Events report (filtered to your integration and, if useful, a date range or status), or use Process Monitor with the process type set to Integration. All three lead back to the same event.

Once you're on the run, its tabs carry different pieces of the story: Process Info has the actual versus scheduled start time, Process History has the last five runs of this integration for comparison, Output Files has whatever the run produced, and Messages has the detail written out during execution, including data-size warnings for large report extracts.

"Completed With Errors" is not the same problem as "Failed"

Completed With Errors means the EIB ran end to end and Workday rejected some rows on their own merits: a bad reference ID, a missing required field, a security check the launching account failed for that one record. The rows that passed are already loaded. Don't read "Completed" alone as success, either — check the run's processed-record count before you assume every row you sent actually landed.

Failed is a different kind of problem: the run itself didn't finish, usually before Workday got far enough to evaluate individual rows. That points at the integration's setup — the data source, the transformation, the delivery step, or a limit the run exceeded — rather than at any one row of data. Aborted means someone or something stopped the run before it finished on its own.

Open the failure details, not just the status

On a Completed With Errors run, the Number of Errors field is a link: select it to read the actual messages, row by row. If the file was large or the errors are easier to work through in a spreadsheet, check the Output Files and Messages tabs first — for an inbound EIB with Handle Import Processing Errors left selected on Launch / Schedule Integration, Workday can attach a Failure Report, an Errors and Warnings spreadsheet, and a copy of your data with the failing rows flagged, directly to the integration event.

Fix the flagged rows in that attachment rather than re-exporting a clean file from scratch, then relaunch the same EIB with the corrected spreadsheet. These troubleshooting files don't stay attached forever — Workday retains them for 60 days — so pull a copy down if you need the detail for a longer investigation.

Workday error

"<value> is not a valid ID value for type = <Reference ID type>"

This is the general shape of the most common EIB rejection: <value> is not a valid ID value for type = "<Reference_ID_type>". It means the value in that reference ID column doesn't match any record's Reference ID in this tenant, for the ID type the column expects. Three things cause it: the ID is simply wrong (a typo, or an ID copied from a different tenant), the record it points to has been made inactive since the ID was captured, or the value is a real Reference ID but of the wrong type for that column — the spreadsheet may accept several ID types for the same field, and picking the wrong one produces exactly this message.

Don't guess at the correct value. Open the target record in Workday, use its Integration IDs > View IDs related action, and copy the ID next to the type the column actually expects. When you need the ID for many records at once, the Integration IDs report returns them in bulk.

Workday error

"The entered information does not meet the restrictions defined for this field."

Unlike the reference-ID error, this one doesn't name a bad value — because the value is fine. It means the account that launched the EIB doesn't have the security to act on the specific record referenced in that row. Most inbound EIBs don't run under an integration system user at all: unless the EIB is on a recurring schedule, Workday evaluates the security of whichever business user clicked launch. Check who actually ran it (or who's scheduled to) and what that account can reach — not the account you assumed was involved.

Three permissions matter for a business user launching an inbound EIB: Put access on the domain securing the web service the EIB loads into, Initiating Action in the business process security policy if that web service starts a business process, and Modify access on the Integration: Integration Event domain simply to launch and view the run at all. Missing any one of these produces a security rejection that looks like a data problem until you check the launching account.

Template and column mismatches

A spreadsheet built against an older version of the template silently drifts: someone adds a column for a multi-value field, hides a worksheet or area that's no longer used, or the template model itself changes, and a spreadsheet saved before that change now has the wrong data under the wrong header. Regenerate the template from the integration system's Template Model > Generate Spreadsheet Template related action rather than reusing a file that's been edited across several EIB versions, and keep the Spreadsheet Key column populated and consistent — it's what ties multi-row entries for the same record together.

Effective dates and required fields

Workday's own date fields carry no time component or time zone offset — the format is plain YYYY-MM-DD. A spreadsheet tool or a copy-paste from another system that adds a timestamp or an offset to what should be a date-only column is a common, easy-to-miss cause of a single row's rejection.

Required fields fail the same way: per row, not per file. A blank cell in a column the template marks required rejects that row and leaves the rest of the load untouched — which is exactly why Completed With Errors so often means most of the file loaded and a handful of rows didn't.

Load related data in the order it actually depends on

An EIB that loads by reference ID can only succeed on a row if the record that ID points to already exists in Workday. Loading pay group assignments before the workers' companies exist, or hiring into positions before the positions and their organizations are created, fails for the same reason as a wrong reference ID — because, as far as that row is concerned, it is one. When one load depends on another's output, run them in sequence and confirm each one's result before starting the next, rather than firing off a batch of interdependent EIBs at once.

Validate in a Sandbox tenant before you touch Production

Test a new or changed EIB, and any spreadsheet you're not fully confident in, against a Sandbox or Implementation tenant first — refresh it beforehand if it's gone stale against Production. Load a handful of rows, read the run's results back, and only then scale up to the full file and to Production.

kiweely holds itself to the same rule: it can read a client's tenant and, with consent, make changes one at a time in Production and read each one back — it never runs an EIB load, a bulk edit, or a scripted write loop against a Production tenant.

Prove the fix with one clean row

Before you relaunch the full spreadsheet, cut it down to the single row you just fixed and run that alone. A Completed status on that one row confirms the reference ID, the security, and the field values are right, before you find out the same way on the other 500 rows. If the EIB runs on a schedule under an integration system user rather than a business user, and the failure looks like an authentication problem rather than a data one, see Workday integration system user and API client authentication errors. For the account and permissions an EIB or any integration needs before its first run, see setting up a Workday integration system user and API client. And if you're not sure your Sandbox is current enough to trust the test, see refreshing a Workday Sandbox tenant.

Sources checked