How Workday accepts data
Load order and mechanism apply across every object on this platform.
- 1Foundation before workersSupervisory organisations, locations, job profiles, cost centres and compensation structures. Workday will not stage a worker into an organisation that does not exist.
- 2Choose EIB or Core Connector per objectEnterprise Interface Builder handles spreadsheet-shaped bulk loads against a web service; Core Connectors and Workday Studio cover the higher-volume and more complex integrations. Object volume and complexity decide which.
- 3Loads run as business processesThis is the difference that surprises teams coming from ERP. A Hire in Workday is a business process, not an insert. It has steps, conditions and approvals, and a load that ignores the process configuration either fails or leaves events sitting in flight.
- 4Staged hires and effective datingWorkers are commonly staged with a hire event and effective dates that reconstruct history, which means the load order follows the timeline as well as the dependency graph.
- 5Positions and supervisory hierarchyPosition management, where used, requires positions before workers; supervisory organisation assignment then rebuilds the reporting structure.
- 6Compensation after employmentCompensation plans and grades resolve against structures loaded earlier, so compensation is a later pass rather than a column on the worker load.
- 7Work the EIB error outputEach load returns per-row results. Failures are categorised against the business process or the validation that rejected them, corrected and reloaded.
Treating a Workday load like an ERP insert is the single most common cause of a failed first cycle. Events, effective dating and the business process framework decide what a load actually does.