10.3 Troubleshooting EIB Data Loads & Access Issues

Diagnose in this order

  1. INTEGRATION EVENT  → did it run? what status? what messages?
  2. SCOPE              → whole run failed, or individual rows?
  3. WHOLE RUN          → security · connectivity · template structure
  4. ROW LEVEL          → data · validations · business processes
  5. FIX & RELOAD       → correct rows only, never the whole file again

Every EIB launch produces an integration event recording the run, its status, and the messages generated. It is the first thing to open and it usually names the cause directly.

For scheduled integrations, Process Monitor shows the status of background and scheduled processing. Use it when an integration was expected to run and there is no integration event at all - that is a scheduling problem, not an integration problem.

Whole-run failures

When nothing processed, the cause is structural.

The distinction that saves the most time: an extract that succeeds with a delivery that fails is a connectivity problem, and the data is fine. An access error before any row processes is a security problem, and no data was touched. Neither requires looking at the spreadsheet.

Row-level failures on an inbound EIB

When some rows succeed and others fail, the cause is in the data - because, as section 10.1 established, an inbound EIB performs the same transactions a user would, and it therefore hits the same validations.

The reload discipline

Correct the failing rows and reload only those rows.

Reloading the whole file re-processes every row that already succeeded. Depending on the operation that produces duplicate records, re-triggered business processes, or a second round of notifications to everyone involved - and unwinding that is far more work than the original load. Build the corrected file from the failures only.

Access errors, resolved the same way as everywhere else

EIB access errors use the identical method from section 4.3, with the ISU in place of a person:

1. Read the message and identify the securable item.
2. View Security for Securable Item on that item - which domains secure it, which groups are permitted.
3. View Security Groups for User on the ISU - which ISSGs is it in?
4. Grant the ISSG Get (read) or Put (write) on the domain.
5. Activate Pending Security Policy Changes.
6. Relaunch.

Two mistakes to recognize instantly. Granting View and Modify to an ISSG instead of Get and Put - the account authenticates and the integration still fails. And skipping activation - everything looks configured and nothing is live.

The silent failure: incomplete output

The hardest EIB problem produces no error at all.

An outbound EIB with a constrained ISSG returns only the instances that account can see. Workday reports success, the file is delivered, and it is incomplete. Similarly, an integration using change detection legitimately sends only what changed - an empty file may be entirely correct.

Before treating a small output as a defect:

1. Run the underlying report interactively as a fully privileged user and compare the row count.
2. Check whether the ISSG is constrained, and to which organizations.
3. Establish whether the integration uses change detection.
4. Check the report's own filters and any data source filter, using the reporting method in section 8.4.

Symptom-to-cause quick reference

Escalating beyond EIB

Sometimes the correct answer is that EIB is the wrong tool. Return to the ordered guidance in section 9.2: if the requirement needs per-object processing, multiple web service calls per object, complex error handling and logging, multiple output files, or custom error and warning messages, then a connector with Document Transformation, Orchestrate, or Workday Studio is the intended tool. The Platform Administrator objective is to support basic integrations using Enterprise Interface Builders - and recognizing the boundary of "basic" is part of that objective, not a gap in it.