13.4 Enterprise Interface Builder (EIB): Inbound Integrations & Spreadsheet Templates

Key Takeaways

  • Inbound EIBs ingest external data and commit changes directly into Workday by executing specific Workday Web Service operations (e.g., Put_Worker, Maintain_Supervisory_Organization).
  • The Generate Spreadsheet Template task creates an XML-driven Excel workbook with column headers, required field indicators, and embedded reference metadata bound to a web service operation.
  • External data files can be retrieved automatically from remote SFTP servers via scheduled polling, uploaded manually during launch, or received as email attachments.
  • Inbound processing evaluates records against business process validation rules; critical validation errors halt individual records, while warnings permit processing.
  • Inbound EIBs execute partial-failure commits where valid rows succeed independently; failed rows generate an Error Spreadsheet for targeted delta correction and reprocessing.
Last updated: September 2026

13.4 Enterprise Interface Builder (EIB): Inbound Integrations & Spreadsheet Templates

Quick Answer: An Inbound Enterprise Interface Builder (EIB) ingests external datasets and loads them into Workday by invoking a targeted Workday Web Service Operation (such as Put_Worker or Maintain_Contact_Information). External files can be uploaded manually, polled automatically from an SFTP server, or ingested via email. Data loading is commonly performed using Workday Spreadsheet Templates generated via the Generate Spreadsheet Template task. Inbound processing executes two-tier validation: XML schema compliance and core Business Process validation rules. Critically, Inbound EIBs process records independently (partial-failure processing); successful rows commit immediately to the tenant, while failed rows generate a downloadable Error Spreadsheet for targeted delta reprocessing.


Inbound EIB Architecture & Pipeline Overview

While Outbound EIBs extract data from the tenant, Inbound EIBs provide a robust, mass-data loading mechanism designed for data conversions, periodic automated updates, and mass operational changes.

Primary Use Cases for Inbound EIBs

  • Initial Tenant Data Migration: Loading historical worker populations, job profiles, compensation plans, and supervisory organizations during system implementation.
  • Recurring Automated Mass Updates: Ingesting external benefit election updates, periodic mass compensation adjustments, bonus payouts, or annual stock grant allocations.
  • External System Synchronization: Ingesting new hire records from an external applicant tracking system (ATS) or employee badge IDs from a physical security vendor.
+-----------------------------------------------------------------------------------------+
|                              INBOUND EIB ARCHITECTURE                                   |
+-----------------------------------------------------------------------------------------+
|  STAGE 1: RETRIEVAL           STAGE 2: VALIDATION             STAGE 3: COMMIT & AUDIT   |
|  +-----------------------+    +-----------------------+    +-----------------------+   |
|  | File Retrieval Method |    | Two-Tier Validation   |    | Web Service Execution |   |
|  | - SFTP / FTPS Polling |--->| 1. XML Schema Check   |--->| - Success: Commit row |   |
|  | - Manual File Upload  |    | 2. BP Validation Rules|    | - Error: Generate     |   |
|  | - Email Attachment    |    | Critical vs. Warning  |    |   Error Spreadsheet   |   |
|  +-----------------------+    +-----------------------+    +-----------------------+   |
+-----------------------------------------------------------------------------------------+

Web Service Operations as Inbound Targets

Every Inbound EIB is inextricably linked to a specific Workday Web Service (WWS) Operation. When configuring an Inbound EIB via the Create Integration System task (template: Import Process), the designer selects the target operation.

Standard HCM Web Service Operations

  • Put_Worker / Import_Process_Worker: Creates or updates worker records, personal information, and baseline employment attributes.
  • Change_Job: Executes staffing transfers, promotions, demotions, and lateral moves.
  • Request_Compensation_Change: Submits base pay, allowance, or bonus plan adjustments.
  • Maintain_Contact_Information: Mass updates work and home addresses, email accounts, and phone numbers.
  • Maintain_Supervisory_Organization: Creates and updates organizational hierarchies, staffing models, and leadership assignments.

Interaction with the Business Process Framework

Depending on the web service operation and configuration flags, an Inbound EIB can interact with Workday business processes in two distinct modes:

  1. Standard Business Process Routing: The inbound operation initiates the formal business process definition (e.g., triggering approval chains, notifications, and To-Do tasks for managers and HR partners).
  2. Automatic Execution / Approval Bypass: For historical data conversions or automated administrative feeds, specific Put_* operations allow administrators to bypass approval routing, writing directly to the tenant database under elevated administrative security.

Workday Spreadsheet Templates: Generation & Structure

To facilitate structured data entry without requiring external parties to author complex XML envelopes, Workday provides Spreadsheet Templates.

+-----------------------------------------------------------------------------------------+
|                          WORKDAY SPREADSHEET TEMPLATE (.XLSX)                           |
+-----------------------------------------------------------------------------------------+
|  Row 1: Workday Schema Metadata & Operation Bindings (NEVER EDIT OR DELETE)             |
|  Row 2: Business Object & Field Tech Names (e.g., Worker_Reference, Effective_Date)     |
|  Row 3: Human-Readable Column Labels (Red = Required Field, Black = Optional)           |
+-----------------------------------------------------------------------------------------+
|  DATA ENTRY ROWS                                                                        |
|  Row 4: | 10245 | John   | Smith | 2026-10-01 | US_San_Francisco | Full_Time |          |
|  Row 5: | 10246 | Maria  | Garcia| 2026-10-01 | UK_London        | Full_Time |          |
+-----------------------------------------------------------------------------------------+

The Generate Spreadsheet Template Task

Administrators generate pre-configured Excel workbooks via the Generate Spreadsheet Template task:

  1. Enter the target Web Service Operation (e.g., Put_Job_Profile or Change_Job).
  2. Select the Web Service Version (e.g., v44.0).
  3. Select specific Operation Sections: Many web service operations contain hundreds of potential fields. The administrator selects only the functional sections relevant to the project (e.g., selecting Job Profile Identification and Compensation Grade, while excluding Union Membership).
  4. Download the generated .xlsx workbook.

Anatomy & Golden Rules of Spreadsheet Templates

  • Header Rows Protection (Critical Exam Watchpoint): Rows 1 through 3 contain internal XML schema definitions, object namespaces, and field mappings. Administrators and end users must never edit, insert, reorder, or delete these header rows. Modifying header text or corrupting row 1 breaks the XML conversion engine and causes an immediate fatal import failure.
  • Field Indicators & Color Coding:
    • Red / Bold Column Headers: Mandatory fields required by the underlying web service operation. Leaving these blank guarantees a validation error.
    • Black Headers: Optional or conditionally required fields.
  • Reference IDs vs. WIDs: Workday fields expecting an object reference (e.g., Location, Job Profile, Supervisory Organization) require a valid Reference ID (e.g., Location_ID: LOC_US_NYC, Job_Profile_ID: JP_FIN_ANALYST), not the 32-character hexadecimal Workday Internal ID (WID). Reference IDs are case-sensitive and must match active values in the tenant.

Inbound Data Retrieval & Transport Configuration

Inbound EIBs support flexible data ingestion methods depending on whether the process is an ad-hoc administrative action or an automated enterprise interface.

Inbound Retrieval Mechanisms

  1. SFTP Inbound Polling: The integration connects to a remote SFTP server on a recurring schedule. Key configuration settings include:
    • SFTP Address & Port: Host server credentials and SSH authentication.
    • Directory Path & File Pattern: The remote folder path and wildcard filename matching pattern (e.g., Worker_Updates_*.xlsx or Bonus_Import_*.csv).
    • Post-Processing Action: To prevent reprocessing the same file on subsequent runs, administrators configure the integration to Delete File or Move File to Archive Directory upon successful ingestion.
  2. Manual File Attachment: During manual execution via Launch / Schedule Integration, the user uploads the completed spreadsheet or XML file directly from their local workstation.
  3. Email Retrieval: The EIB monitors a secure inbound Workday mailbox, detaches spreadsheet attachments from incoming emails sent by authorized senders, and executes the import.
  4. PGP Decryption: If external partners transmit sensitive payroll or personnel data encrypted with Workday's PGP Public Key, the inbound EIB automatically decrypts the file in memory using the tenant's private key before processing.

Error Handling, Two-Tier Validation & Partial-Failure Commits

When an Inbound EIB executes, records pass through two sequential layers of validation before any data is committed to the database.

+---------------------------------------------------------------------------------------+
|                               TWO-TIER INBOUND VALIDATION                             |
+---------------------------------------------------------------------------------------+
|  RAW INPUT FILE (Spreadsheet / CSV)                                                   |
|         |                                                                             |
|         v                                                                             |
|  [ TIER 1: XML SCHEMA VALIDATION ]                                                    |
|  - Checks XML syntax, date formats (YYYY-MM-DD), numeric bounds, missing headers       |
|  - Failure here halts the ENTIRE file immediately (Fatal Structural Abort)             |
|         |                                                                             |
|         v (Valid XML Payload Generated)                                               |
|  [ TIER 2: BUSINESS PROCESS & TENANT RULE VALIDATION ]                                |
|  - Validates Reference IDs exist in tenant (e.g., Cost Center, Job Profile)          |
|  - Enforces HCM business logic (e.g., Effective Date cannot precede Hire Date)        |
|  - Evaluates individual records independently (Row-by-Row Evaluation)                 |
|         |                                                                             |
|         +---------------------------------------+                                     |
|         |                                       |                                     |
|         v                                       v                                     |
|  [ VALID ROWS COMMIT ]                  [ FAILED ROWS REJECTED ]                      |
|  - Successfully written to tenant       - Omitted from database                       |
|  - Transaction Log event created        - Written to ERROR SPREADSHEET                |
+---------------------------------------------------------------------------------------+

Tier 1: XML Schema Validation

The first layer verifies the structural integrity of the file. If an invalid date string (e.g., 10/31/26 instead of 2026-10-31) is placed in a strict date element, or if header row metadata was corrupted, the XML parser halts execution. Tier 1 failures abort the entire integration event.

Tier 2: Business Process & Domain Rule Validation

If the XML schema is valid, Workday submits the records to the target web service operation. Each record is evaluated against core HCM business rules and active tenant security:

  • Does the specified Supervisory Organization exist and remain active?
  • Does the proposed compensation fall within the assigned Compensation Grade Profile?
  • Does the worker have an active position eligible for the requested job change?

Critical Errors vs. Warnings

  • Critical Errors: Represent rule violations that prevent record creation (e.g., invalid Worker ID or missing mandatory effective date). The individual record is rejected.
  • Warnings: Flag potential operational concerns (e.g., proposed salary exceeds the grade maximum, but policy allows exceptions). If the EIB launch settings have Ignore Warnings checked, the record commits successfully despite the warning.

The Partial-Failure Architecture (Exam Trap)

A foundational concept on the certification exam is that Inbound EIBs do not execute an all-or-nothing rollback across the entire batch:

If an Inbound EIB processes a spreadsheet containing 500 employee records, and 480 rows are valid while 20 rows contain invalid Cost Centers, the 480 valid rows commit permanently to the tenant database. The integration does not roll back the successful 480 records. The Integration Event completes with a status of Completed with Errors.

Reprocessing Failed Rows via the Error Spreadsheet

When an Inbound EIB completes with errors:

  1. Open the Integration Event audit page.
  2. Navigate to the Event Documents section and download the generated Error Spreadsheet.
  3. The Error Spreadsheet contains only the rejected rows, with an additional column appended on the far right describing the exact validation error message for each record.
  4. Correct the errant values directly in the Error Spreadsheet.
  5. Re-launch the Inbound EIB using the corrected Error Spreadsheet. Only the corrected delta records are imported, completely eliminating the risk of duplicating already-committed rows.

The "Validate Only" Launch Parameter

When preparing for major production mass updates, administrators utilize the Validate Only launch parameter:

  • Simulation Mode: The EIB executes the entire retrieval and two-tier validation pipeline without committing any changes to the tenant database.
  • Risk Mitigation: Generates an audit log detailing all potential validation failures, allowing administrators to scrub data errors before executing the live import.

Auditing & Transaction Logs

Every inbound integration creates an immutable audit trail within the Workday architecture:

  • Integration Event Statuses: Reflects overall health: Completed (100% success), Completed with Warnings, Completed with Errors (partial failure), or Failed (fatal tier-1 abort).
  • Event Documents Repository: Archives the original uploaded input file, the converted Workday XML document, and the generated Error Spreadsheet.
  • Tenant Transaction Log: Every committed record writes an entry to the Workday Transaction Log recording the timestamp, the ISU identity, and the exact before-and-after attribute values, maintaining compliance with SOX and enterprise audit mandates.

Inbound EIB Configuration & Validation Matrix

The following matrix summarizes the configuration parameters and operational rules for Inbound EIBs:

Stage / ParameterConfiguration TaskOperational FunctionCritical Validation Rule / Exam Watchpoint
Template GenerationGenerate Spreadsheet TemplateCreates operation-bound Excel workbookNever modify, insert, or delete header rows 1–3
Inbound System SetupCreate Integration SystemLinks EIB to specific Web Service OperationEnsure target operation aligns with intended data action
Retrieval TransportConfigure Integration ServicesConnects to SFTP, Manual, or Email sourceArchive or delete processed files on SFTP to prevent loops
Reference DataSpreadsheet column data entryIdentifies related business objectsMust use Reference IDs (e.g. LOC_NYC), never 32-char WIDs
Pre-Import TestingLaunch / Schedule IntegrationRuns validation without database commitCheck Validate Only to preview errors safely
Error ManagementIntegration Event Document ViewGenerates delta error spreadsheetDownload Error Spreadsheet; re-upload only corrected rows

Certification Pitfalls & Common Exam Traps

  1. The All-or-Nothing Rollback Myth: Certification exams regularly attempt to deceive candidates by asserting that if one row fails in an Inbound EIB, all prior rows are rolled back to preserve database consistency. Candidates must know that Workday commits valid rows independently. Only the invalid rows fail.
  2. Spreadsheet Header Row Corruption: If an exam scenario describes an import failing immediately with a fatal XML schema parser error before any records are validated, look for users who modified, deleted, or inserted columns in rows 1, 2, or 3 of the spreadsheet template.
  3. Reference ID Type Confusion: Entering the display name of a Supervisory Organization (e.g., "Global Sales Operations") instead of its unique Organization Reference ID (e.g., SUPERVISORY_ORG-6-104) will cause a validation failure. Reference IDs are mandatory.
  4. Reprocessing the Entire Original File: When an import of 1,000 workers results in 50 errors, the correct procedure is never to fix the original file and re-upload all 1,000 rows. Doing so may re-trigger business processes or cause duplicate event errors for the 950 successful workers. The correct action is downloading and reprocessing the Error Spreadsheet, which contains only the 50 failed rows.
Loading diagram...
Inbound EIB Data Validation, Partial-Failure & Reprocessing Lifecycle
Test Your Knowledge

An HR Operations team executes an Inbound Enterprise Interface Builder (EIB) to load annual compensation adjustments for 2,500 workers. The integration event finishes with a status of 'Completed with Errors', indicating that 2,420 records processed successfully, while 80 records failed due to missing allowance plan IDs. What occurred in the Workday database?

A
B
C
D
Test Your Knowledge

Prior to executing a mass position update for 10,000 employees in the production tenant, a Lead HCM Consultant wants to verify that all position reference IDs and job profiles are valid without committing any actual changes to the live worker records. Which configuration setting fulfills this requirement?

A
B
C
D
Test Your Knowledge

An Inbound EIB loading 500 new contingent workers completes with 35 validation errors. What is the recommended, certified procedure for resolving and loading the failed records?

A
B
C
D