9.2 Workday Integration Tools & Choosing the Right One
Key Takeaways
- Workday's integration tools are Cloud Connect connectors, Orchestrate, Document Transformation, and Workday Studio, alongside the Enterprise Interface Builder.
- End-to-end connectors target a specific external endpoint, while generic connectors such as Core Connector: Worker provide a customizable foundation for a dataset.
- Connectors rely on underlying SOAP web services and remove the need to write web service requests by hand.
- Document Transformation only transforms the output of a connector; it does not extract data itself.
- Workday Studio is the Eclipse-based environment for the most customizable integrations, used when you need multiple web service calls per object, per-object processing, or complex error handling.
The delivered integration tools
To build an integration system you use an integration tool.
| Tool | Description | Features |
|---|---|---|
| Cloud Connect (Connectors) | Integration systems for simple inbound data loads and outbound extracts. Includes vendor-specific (end-to-end) and generic connectors | Integration services, change detection, work with business processes, integration maps, integration attributes, integration field overrides |
| Orchestrate | Web-based tool for creating and customizing integrations without code | Orchestration Builder, custom transformations, batch integrations, interacts with Workday and third-party endpoints |
| Document Transformation | Advanced transformation tool with basic error message functionality. Only used with connectors | Error handling, business process, multiple files |
| Workday Studio | Eclipse-based development environment for the most customizable integration systems | Integration maps, attributes, field overrides, error handling, multiple files, multiple web service calls, multiple transformations |
Alongside these sits the Enterprise Interface Builder (EIB), the tool the Platform Administrator exam concentrates on, covered in Chapter 10. EIB is the customer administrator's tool for spreadsheet-driven inbound loads and report-driven outbound extracts, and it requires no development environment.
End-to-end versus generic connectors
End-to-end connectors integrate with specific external endpoints, like Aetna. Generic connectors, like Core Connector: Worker, provide a generic foundation to a specific dataset that you can customize.
Run the Integration Template Catalog report in Workday for the list of available connectors. Checking this catalog first is the single best habit in integration design: if a connector exists for your vendor, building anything else is wasted effort.
Connectors eliminate the need to directly use SOAP web services. With connectors you do not write web service requests - the connector makes the request and the SOAP calls on your behalf. You would only need to make SOAP or REST calls if you are using Workday Studio.
Data sources by tool
Inbound integrations insert external data using Workday SOAP or REST web services. Outbound integrations can use any data source type, but it varies by tool.
| Integration tool | Data source |
|---|---|
| Connector | Relies on underlying SOAP web services. The user does not select a web service operation or write a request |
| Connector with Document Transformation | Uses the same source as its connector, because it does not extract the data - it only transforms it |
| Orchestrate | RaaS, SOAP, or REST. Can call Workday and third-party endpoints |
| Workday Studio | RaaS, WQL, SOAP, or REST |
The Document Transformation row is the one that gets tested. Document Transformation is a transformation layer, not an extraction tool - it always sits on top of a connector.
Choosing a tool for an inbound integration
Workday publishes this as an ordered list - consider the tools in this sequence and stop at the first that fits.
| Order | Tool | Use if |
|---|---|---|
| 1 | End-to-End Connector | There is a template for the specific vendor providing the input file, and you do not need to transform the data |
| 2 | Generic Connector | There is a template with all the data elements you need to import, and your inbound data is in XML or CSV |
| 3 | Orchestrate | There is no packaged solution; you need event-driven and batched scenarios; you need to transform data; you need to interact with Workday or third-party APIs |
| 4 | Connector with Document Transformation | You need to modify the input file to meet Workday format requirements; you have an XML input file; you need custom error or warning messages |
| 5 | Workday Studio | A variety of scenarios; multiple WWS requests per object; process each object individually; complex error handling and logging |
Choosing a tool for an outbound integration
| Order | Tool | Use if |
|---|---|---|
| 1 | End-to-End Connector | There is a template for the specific vendor receiving the output file |
| 2 | Generic Connector | There is a suitable template; you need change detection |
| 3 | Orchestrate | No packaged solution; you need to call one or multiple APIs; event-driven and batched scenarios; you need to transform the data |
| 4 | Connector with Document Transformation | You need to modify the output of a core connector; multiple output files; a non-XML output format; custom error or warning messages |
| 5 | Workday Studio | A variety of scenarios; multiple WWS requests per object; per-object processing; complex error handling and logging |
The ordering is the answer. These lists are deliberately sequenced from least to most effort, and exam items are built on that sequence. When a scenario says a vendor template exists, the answer is the connector - even when Studio would technically also work. Studio is the last resort, not the powerful default.
Note the one difference between the lists: change detection appears as a reason to choose a generic connector on the outbound side. Change detection answers "send only what changed since last time," which is an outbound concern.
Where EIB fits
EIB is the administrator-facing tool that does not appear in those two lists because it addresses a different problem. Connectors, Orchestrate, and Studio build integration systems for ongoing automated exchange with a specific endpoint. EIB handles the everyday cases:
| Need | Tool |
|---|---|
| Load a spreadsheet of data into Workday | Inbound EIB |
| Extract a custom report to a file on a schedule and deliver it | Outbound EIB |
| Exchange data continuously with a named vendor system | Connector |
| Orchestrate multi-step logic across APIs without code | Orchestrate |
| Anything requiring per-object processing or complex error handling | Studio |
The Platform Administrator objective is explicitly to support basic integrations using Enterprise Interface Builders. You are expected to recognize the other tools and know when a requirement exceeds EIB - not to build in Studio.
Integration maps, attributes, and field overrides
Connectors and Studio share three configuration concepts worth recognizing:
- Integration maps translate a Workday value into an external system's value - Workday's
Regularbecomes the vendor'sR. - Integration attributes supply runtime parameters to the integration - a file name, a directory, a threshold.
- Integration field overrides replace the value of a delivered field with a calculated field, so the outbound file carries a derived value.
Field overrides are where calculated fields (section 8.1) re-enter the integrations story: much of the shaping of an outbound file is done with calculated fields rather than with code.
A vendor supplies an end-to-end connector template for the exact system receiving an outbound file, and no data transformation is needed. According to Workday's ordered guidance, which tool should be chosen?
Which statement about Document Transformation is correct?
Which capability requires Workday Studio rather than a connector?