How to load data into an Extend business object with EIB

Use an inbound EIB with the Extend Spreadsheet Template file type. Deploy the app, give the loading user's security group Modify on the app's domain in App Manager, create the EIB against the business object, generate its spreadsheet template, fill it in and launch the EIB (Load Data to Extend Business Objects Using EIBs). The business object's REST API with ?bulk=true is the other documented way to write data, and the one that supports updates by id.

Before you build the EIB: model and security

Two things in the model are hard to change once data is in, so settle them first:

  • The reference ID. Setting "isReferenceId": true on a TEXT field makes it the object's Reference ID: required, unique and impossible to delete. Workday recommends setting it before you load data, because if existing values are not unique, the deployment that adds the attribute fails (Reference: Model Component Attributes). A legacy key such as the old system's request number is the usual choice.
  • Search-enabled fields. enableSearch, which makes a TEXT field selectable in report prompts, has the same uniqueness rule and the same advice to set it before loading.

Then grant access. In the tenant, open the App Manager report, choose Configure for the app, and in the Model Components section's Security Domains grid create or edit the domain security policy. Add a row to Report/Task Permissions for the security group that holds the loading users and select Modify (Configure Extend Apps to Manage Data Using EIBs). The permission applies at the app level, so you do not repeat it for each business object. Workday lists Activate Pending Security Policy Changes as the next step.

Create the inbound EIB

  1. Run Create EIB, name it and select Inbound.
  2. On Get Data, choose the retrieval method (an attachment at launch is simplest for a one-off load).
  3. Under Data Format, set File Type to Extend Spreadsheet Template.
  4. In Extend App Ref ID, pick the app; in Extend Model Component, pick the business object. Both prompts only offer what is deployed to this tenant.
  5. On Transform and Deliver, confirm Workday has set Transformation Type and Delivery Method to Workday Extend.

One EIB loads one business object, because the Extend Model Component prompt takes one. If the app has an Equipment Request object and a separate Equipment Line object, build two EIBs.

Generate and fill the template

From the EIB's related actions, choose Template Model > Generate Spreadsheet Template and confirm. The XLSX appears on the Output Files tab when generation finishes. The business object's fields are the columns; Workday requires this XLSX format for Extend loads.

The template's columns come from the business object's fields, so it is sensible to generate it again after the model changes (a recommendation; the docs don't spell out template versioning). Template generation failures themselves are covered in EIB generate spreadsheet template errors.

Workday's EIB spreadsheet data entry guidelines apply to the filling. For reference (SINGLE_INSTANCE) fields, load parents before children so the instances they point to exist.

Launch it and read the result

From the related actions, choose Integration > Launch / Schedule. An EIB with critical errors cannot be selected. On the Integration Attachment row of the criteria grid, select the filled spreadsheet. Select Add Errors to Attachment as well: Workday creates an attachment in the Integration Events report and inserts comments in the key fields of rows that have errors.

When the event completes, open the Messages tab and read the completion status in the Execution Summary. Workday describes the load as uploading the data as if you entered it manually. The docs don't say how EIB treats secureByTarget, but Workday's bulk REST example shows what constrained security does there: a manager's rows for their own team succeed and the rest return status 400 (Example: Order of Responses in Bulk Operations). If your object uses secureByTarget, load as a user whose access covers every row, and check the first small load for rejections. General EIB error reading is in EIB results and the error toolbar.

Updates and repeat loads: use the bulk REST API

Workday's EIB procedure for Extend describes loading data and says nothing about matching existing rows, so prove in a sandbox what a second run of the same rows does before relying on it to correct a load.

For changes to existing records, the business object's REST API supports bulk POST, PUT, PATCH and DELETE of up to 100 instances per request with ?bulk=true. PUT, PATCH and DELETE need each instance's id in the body (Reference: Business Object API Requests):

curl -X PATCH "https://api.workday.com/apps/{appId}/v1/equipmentRequests?bulk=true" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{
    "data": [
      { "id": "{requestWid1}", "status": "Closed" },
      { "id": "{requestWid2}", "status": "Closed" }
    ]
  }'

The responses come back in the same order as the requests, so you can match each failure to its input row. To get the ids, report on the data first (see the proof section below) and match on your reference ID. If many records have to be removed, see bulk deleting Extend business objects.

An orchestration that reads a CSV and posts batches of 100 is the same API driven from inside Workday (Workday's own bulk example says larger datasets need Orchestrations); see processing a CSV file in Orchestrate.

Prove the load

Count, then sample:

  1. Build a custom report on the business object's data source (named after its defaultCollection label), or use WQL against its alias, and compare the row count with the spreadsheet. The Extend Object Instance Count report, secured by Manage: App Manager, shows the instance count for Extend business objects and attachments in the tenant (Reference: Limits on Model Components).
  2. Open a handful of loaded records in the app's own pages as a business user and check that reference fields resolve to the right worker, cost center or parent, and that dates and amounts read as entered.
  3. If the data must leave Workday again, the same custom report, enabled as a web service, is the source for an outbound EIB (Extract Data from Extend Business Objects Using EIBs).

Keep the tenant limit in mind for large history loads: 10 million instances per tenant on Extend Core and Legacy SKUs (100 million on Extend Professional for business objects), shared across every Extend business object and attachment object in the tenant.

kiweely can do the reading-back part in the real tenant: it reads the loaded rows as the signed-in user and compares them with the source spreadsheet.

Sources checked