Build new integrations in Orchestrate, with two exceptions
Workday's own integration training now tells builders to default to Orchestrate: "When you think about the Workday integrations landscape, we want you to focus on Orchestrate." Orchestrate for Integrations is the browser-based, drag-and-drop tool for event-driven and batch integrations, and it is where Workday is putting new capability. Workday Studio, the Eclipse-based developer tool, "remains a tool to use but only when you are dealing with complex or a small subset of specialized requirements."
In practice that means: default to Orchestrate for a new integration. Reach for Studio only when the integration needs multiple web service calls per object, has to process each object individually, or needs error handling and logging beyond what Orchestration Builder's components provide. And before either one, check whether a Workday-delivered connector or EIB already does the job — Workday's own decision order puts both ahead of custom-built integrations.
What Orchestrate actually is
Orchestrate for Integrations lets you design, build, manage, and share integrations between Workday and external systems using Orchestration Builder, a drag-and-drop environment for building workflows called orchestrations. It's entirely browser-based on the Workday Developer Site (developer.workday.com) — there's nothing to download or install. An orchestration can call Workday and third-party APIs, transform data, and run on a schedule or in response to an event, like a business process reaching a certain step.
There are two Orchestrate products, and mixing them up causes confusion: Orchestrate for Integrations and Orchestrate for Extend. Integrations-flavored orchestrations get components the Extend flavor doesn't, including Send Workday RaaS Request, Trigger Business Process, Trigger Integration, Trigger PDF Generation, and Store Documents. Extend-flavored orchestrations, in turn, support both synchronous and asynchronous execution and can call several AWS components that aren't available on the integrations side. If you're building inside an Extend app, you're using the Extend flavor by default; a standalone integration uses Orchestrate for Integrations.
Getting access isn't automatic. Before Orchestration Builder is usable, your organization opts in to Workday's Innovation Service Agreement, using the Innovation Services and Data Selection Opt-In report in your Production tenant — select Workday Orchestrate for Integration under the WCP section. Universal Main Subscription Agreement (UMSA) customers get the feature automatically; Main Service Agreement (MSA) customers enable it through Innovation Services first. You then use the Maintain Workday Build Company for Orchestrate for Integration task to name a company administrator, who can sign in to the Developer Site and add other users. None of this requires installing anything locally.
What Workday Studio actually is
Workday Studio is an Eclipse-based integrated development environment that you install separately from Workday, as a set of plugins on top of the Eclipse IDE. It's a full Java development environment: you drag and drop components for flow control, data manipulation, and code reuse, and write custom logic where the delivered components don't cover a case. Workday has used Studio for years to build many of its own packaged connectors.
Studio runs locally on your computer against a workspace — a folder holding your projects and tenant connections — and it deploys the integrations you build to run in Workday's cloud. Its Cloud Explorer view connects to a Workday tenant to launch, review, and import deployed integrations; its Project Explorer is your local working copy. You debug locally, in Studio, before deploying. That local debugger, and the ability to write arbitrary Java, is the capability Orchestrate doesn't have.
EIB and connectors usually come before either one
Before Orchestrate or Studio, Workday's own guidance puts two simpler tools first. Enterprise Interface Builder (EIB) is a wizard-guided tool for simple inbound and outbound integrations, built from an integration system, a data source, a transformation, and a transport protocol — no programming required. It's the most commonly used Workday integration tool for straightforward, one-off or scheduled data movement.
Cloud Connect connectors are Workday-delivered templates. End-to-end connectors are fully built for a specific third-party endpoint — a bank, a benefits provider, the IRS, E-Verify — and need no coding or document transformation; Workday maintains and updates them each release. Generic connectors, often called Core Connectors (Core Connector: Worker, Core Connector: Organization, and similar), give you most of the configuration for a dataset without being tied to a specific endpoint — you still configure services, maps, and field overrides to fit your requirements. Workday supports the delivered code of a Core Connector; configuring and testing it for your tenant is on you.
Workday's own decision order for a new integration, from its integrations training: manual entry for low-volume or highly complex data, then Cloud Connect — an end-to-end connector if one exists for the vendor, otherwise a generic connector — and only then a custom integration built in Orchestrate or Workday Studio. Reaching for Orchestrate or Studio before checking for a matching connector usually means rebuilding something Workday already maintains for you.
Orchestrate vs. Studio, side by side
| Orchestrate for Integrations | Workday Studio | |
|---|---|---|
| Who builds it | Anyone comfortable with a drag-and-drop builder; minimal code | Developers comfortable with Java and Eclipse |
| What you need first | Innovation Services opt-in and a company on the Workday Developer Site | The separately downloaded Workday Studio application, connected to your tenant |
| Where it runs | Entirely browser-based, on the Workday Developer Site — no download | Installed and run locally; deploys built integrations into Workday's cloud |
| Monitoring | Orchestration Builder logs, Debug Orchestrations, orchestration summary reports, verbose logging | Cloud Explorer against the deployed integration, plus Workday-side integration events and logs |
| Data sources | RaaS, SOAP, REST | RaaS, WQL, SOAP, REST |
| Typical fit | Event-driven and batch integrations, transformations, calling one or more APIs | Multiple web service calls per object, per-object processing, complex error handling and logging |
This mirrors how Workday itself frames the choice: Orchestrate for real-time, transactional workflows built with a drag-and-drop interface, "not suitable for large batch data jobs" on its own; Studio for "highly customized and complex integrations that require advanced logic," at the cost of a steeper learning curve and longer build times.
When Studio is still the right choice
Pick Studio when an integration needs to make several web service requests per object rather than one call per batch, when each object has to be processed and error-handled on its own rather than as part of a set, or when the error handling and logging requirements go beyond what Orchestration Builder's built-in components support. These are exactly the criteria Workday's own tooling comparison uses to route a new integration to Studio instead of Orchestrate or a connector.
Studio is also still the right tool when you're extending a Workday-delivered connector or document transformation that already assumes Studio, since the sample code, transformations and support model attached to that template are written for it.
Don't rip and replace working Studio integrations
Nothing about Workday's shift in emphasis toward Orchestrate makes an existing, working Studio integration wrong. Workday still supports Studio, still updates it, and still uses it internally. Rewriting a stable integration in Orchestrate for its own sake spends effort re-testing something that already passes today, with no change in what the business gets.
Migrate opportunistically instead: when you're already touching an integration for a real change — a new field, a new endpoint, a bug — and the change is easier to make or test in Orchestrate, move that piece then. If a Studio integration is a genuine ongoing cost — nobody left on the team reads Java, or the local Eclipse setup is the thing slowing down every fix — that's a real reason to plan a rebuild. "It's older" or "Workday says Orchestrate now" are not.
Decide in this order
- Would manual entry cover it — low volume, or the data is too irregular to justify automating? If so, stop there.
- Does a Workday end-to-end connector already exist for this vendor or service? Run the Integration Template Catalog report to check before assuming there isn't one.
- Does a generic Core Connector cover the dataset, possibly with a document transformation for formatting? If the shape of your data matches a Core Connector, use it and configure it.
- Is this a simple, one-shot or scheduled data movement with no complex transformation? EIB is usually faster to build and support than either Orchestrate or Studio for that case.
- If none of the above fit: does the integration need multiple calls or bespoke error handling per object, or genuinely custom logic no component covers? Build it in Studio.
- Otherwise — event-driven, batch, or API-calling work that doesn't need per-object processing — build it in Orchestrate.
Where this connects
Once you're building in Orchestrate, its errors deserve their own read — see Workday Orchestrate errors and what they mean for the ones that point you the wrong way. Both Orchestrate and Studio integrations commonly pull data through RaaS, WQL, or REST; if you're deciding how to source that data, see RaaS, WQL, and REST for Workday reporting and integrations.
kiweely builds and validates the orchestrations inside Workday Extend apps in your tenant and reads back what a run actually did, but the choice between Orchestrate, Studio, a connector and EIB is still yours to make before anything gets built. This guide is meant to make that first call quickly.