Workday gives you three tools for building integrations: Enterprise Interface Builder (EIB), Cloud Connect (including Core Connectors), and Workday Studio. They overlap just enough to make the choice confusing — and the wrong pick shows up months later as a maintenance burden or a rebuild.
This guide lays out what each tool actually does, where each one fits, and a decision framework you can apply to any integration requirement.
Enterprise Interface Builder (EIB)
EIB is Workday's no-code integration tool. It handles straightforward, single-direction data flows: one data source, an optional XSLT transformation, and one transport out. Functional consultants and system administrators are its primary users — no development environment or programming background required.
What it handles well:
- Scheduled file exports from Workday (CSV, XML, JSON)
- Simple inbound data loads from flat files
- Report-based outbound feeds to SFTP, email, or REST endpoints
Where it stops:
- One data source per integration — no joining, merging, or multi-step orchestration
- No conditional logic, looping, or dynamic routing
- Limited error handling (retry at the transport level, but no custom recovery flows)
Payload limits:
- 30 MB for browser-uploaded files
- 300 MB for SFTP inbound files
- XSLT transformations recommended under 100 MB; above 400 MB, the risk of timeout or memory failure rises significantly
- 15 GB memory ceiling per tenant for all running integrations
- 2-hour maximum for XSLT processing
EIB is the right starting point for any integration requirement. If a Custom Report can produce the data and a single transport can deliver it, EIB will do the job with the least ongoing maintenance.
Cloud Connect and Core Connectors
Cloud Connect packages are prebuilt, vendor-specific integrations maintained by Workday and its partners. Core Connectors cover foundational scenarios — payroll (PECI), benefits, tax filing, time tracking — with event-driven data flows that capture deltas rather than full snapshots.
What they handle well:
- Worker lifecycle events to payroll vendors like ADP, Ceridian, or in-house systems (via PECI)
- Benefits enrollment and life-event feeds
- Tax-form generation and filing
- Time-tracking exports
Where they stop:
- Configuration, not development — you choose options and map fields, but you cannot add custom logic
- Limited to the vendors and scenarios Workday has built packages for
- Customization beyond the provided configuration requires a separate Studio or EIB integration downstream
Cloud Connect is the right choice when Workday or a certified partner has already built and maintains the exact integration you need. The prebuilt packages handle schema changes across Workday releases, which eliminates a significant maintenance burden.
Workday Studio
Studio is the developer-grade tool. It is a set of Eclipse-based IDE plugins where skilled developers build integrations as visual assemblies — directed graphs of components that define how data flows from source to destination.
Assembly components include:
- Transports: Workday-In (launch events, scheduled triggers), HTTP/REST, SOAP, SFTP, and AS2
- Mediation steps: XSLT transformation, MVEL expression evaluation, Copy, Log, and Write
- Control flow: Splitter, Aggregator, Choice Router, Loop, and Document Iterator
- Validation: Full XML schema validation, MVEL expression checks, and XPath assertions
- Subassemblies: Reusable fragments that can be shared across integrations
Studio integrations deploy as CLARs (cloud archives) containing collections, and run as named Integration Systems on the tenant. Monitoring is through Workday's Integration Events, which provide step-by-step run reports.
What it handles well:
- Multi-source data merges (e.g., combining Custom Report output with web-service calls)
- Complex transformation chains with conditional routing
- Web-service orchestration — calling Workday SOAP APIs, external REST endpoints, or chaining multiple calls
- High-volume processing with XSLT 3.0 streaming
- Custom error handling, retry logic, and notification flows
Where to be cautious:
- 250 MB per individual file, 1 GB total generated output, 1.5 GB memory per integration
- XSLT can consume roughly 10x the source data in memory when not using streaming
- The same 2-hour processing cap applies
- Requires developers with Java, XML, and XSLT skills — the learning curve is steep
Studio is the right tool when the integration needs logic that EIB and Cloud Connect cannot express: conditional branching, multi-step orchestration, web-service chaining, or custom error recovery.
At-a-Glance Comparison
| Dimension | EIB | Cloud Connect | Studio |
|---|---|---|---|
| Primary user | Functional consultant, admin | Admin configuring prebuilt packages | Developer (Java/XML/XSLT) |
| Complexity | Single source → transform → transport | Prebuilt, event-driven packages | Multi-source, multi-transform, custom logic |
| Custom logic | None | Configuration options only | Full (XSLT, MVEL, routing, looping) |
| Error handling | Transport-level retry | Package-defined | Custom (Choice Router, error mediation) |
| Typical use | Scheduled exports, simple loads | Payroll, benefits, tax vendors | Complex orchestrations, web-service chains |
| File size cap | 300 MB (SFTP) / 30 MB (browser) | Vendor-specific | 250 MB per file, 1 GB total output |
| Memory | Shared tenant pool (15 GB) | Shared tenant pool | 1.5 GB per integration |
| Maintenance | Low | Low (vendor-maintained) | High (your team owns it) |
A Decision Framework
Start from the simplest tool and escalate only when the requirement demands it:
Step 1 — Can a Custom Report produce the data? If the integration is a single outbound feed that a Workday report can generate, start with EIB. Add an XSLT transformation if the target system needs a different format.
Step 2 — Does a prebuilt connector exist? If the integration targets a common vendor scenario — payroll processing, benefits enrollment, tax filing — check whether Workday or a partner offers a Cloud Connect package. These are maintained across Workday releases, which saves significant effort during biannual updates.
Step 3 — Does the integration need programming logic? If the answer to both previous questions is no — or if the integration requires conditional routing, multi-source merges, web-service orchestration, or custom error recovery — Studio is the appropriate tool.
Common Mistakes
Using Studio when EIB would suffice. A scheduled CSV export to an SFTP server does not need an assembly with transports, mediation steps, and XSLT transformations. EIB does this in minutes with zero code. Studio adds development time, a steeper maintenance burden, and a dependency on developer availability for changes.
Skipping Cloud Connect because "we already have Studio developers." Cloud Connect packages are maintained by Workday through release updates. A custom Studio integration that replicates what a Core Connector does will need manual review and potential rework every six months when Workday ships a new release.
Building one monolithic Studio integration instead of composing smaller ones. Large assemblies with dozens of steps become difficult to debug and impossible to test in isolation. Studio supports subassemblies for a reason — use them to keep individual integrations focused and testable.
Ignoring payload limits until production. The memory and file-size constraints are hard limits. An integration that works in sandbox with 10,000 records may fail in production with 200,000. Design for production volumes from the start, and use XSLT 3.0 streaming for any transformation that will handle documents over 100 MB.
Tools like kiweely can help teams evaluate existing integrations and identify where a simpler tool would reduce maintenance — its assistant can open a Studio integration, walk through the assembly logic, and flag whether the complexity is warranted.