RaaS, WQL, REST or SOAP: the short answer

For a one-off or scheduled pull of a report's exact output, in CSV, XML or JSON, use RaaS. For a filtered, aggregated or paginated query across a data source, use WQL. For a single, known Workday resource inside an app or a narrow integration, use a REST API. For a business operation or a field that only the older web-service layer exposes, use SOAP. None of these replaces the others; most real integrations use two.

All four run under the calling account's own Workday security. None of them get around what that account cannot see.

What RaaS actually gives you

Reports as a Service turns an existing advanced or search report into a web service by enabling it under the report's Web Service setting. Workday then serves that report's output at a URL built from the report owner, the report name and the report's own prompts as query parameters: 

…/ccx/service/customreport2/<tenant>/<owner>/Headcount_by_Organization?Organization%21WID=<wid>&format=json

Every prompt the report defines becomes a parameter, so calling it correctly means reading the report's Prompts tab first, not guessing parameter names. RaaS supports CSV, GData, JSON, RSS, Simple XML and Workday XML output, both a REST-style URL and a SOAP/WSDL binding for the same report, and Workday's audit framework tracks changes to the report definition because that definition is a real, persisted Workday object. The call returns the whole result in one shot; there is no pagination parameter, and it honors the calling account's object and data-level security the same way the report does when a person opens it.

Copy a standard report to a custom report before enabling it as a web service. Workday can update a standard report on its own release schedule, and that change reaches every integration pointed at it.

Where WQL fits instead

Workday Query Language reads straight from a tenant's data sources and fields rather than a saved report, using SQL-like syntax with its own rules. It aggregates with GROUP BY and COUNT(), and its REST endpoint pages a large result instead of returning it all at once: 

SELECT supervisoryOrganization, COUNT()
FROM allWorkers
GROUP BY supervisoryOrganization

For the full method — finding a tenant's real data sources and fields, building the first query and choosing an execution route — see the Workday WQL guide. For the exact row limits on each route and how to page past them, see getting more than 500 rows from WQL. Access to WQL itself is a separate domain from the fields it queries, so the calling account needs both.

REST APIs and SOAP web services

Workday's REST APIs are resource-specific: a fixed, versioned endpoint such as workers or absence requests, not an arbitrary query. Collection endpoints that support pagination take limit and offset query parameters, and Workday returns the collection's total so a caller knows how many more pages remain: 

GET …/staffing/v6/workers?limit=20&offset=20

Each REST endpoint is secured to a domain or business-process security policy through Report/Task permissions, View for a GET and Modify for a write, whether the caller is a person or an integration system user. That is a different permission type from the Integration Permissions that secure SOAP web services, so an account cleared for one is not automatically cleared for the other. SOAP still covers business operations and fields that REST does not: Workday's Get_ operations retrieve data across a wider range of business objects than the REST catalog reaches, which is why older or deeper integrations still call Get Workers, Get Organizations or a similar Get_ operation directly. Both routes need a registered API client or an integration system user; see setting up a Workday integration system user and API client for that setup.

When none of these is the right tool

If the requirement is really "deliver this report to a system on a schedule," an outbound Enterprise Interface Builder wraps a report (including a RaaS-enabled one) with scheduling, transformation and delivery, so a caller does not poll a URL itself. If the data belongs to a curated or blended dataset rather than a live operational data source, build it in Prism Analytics first, then report on the Prism data source it publishes. If the value you need is a calculated field that returns blank in the output, the field or its security definition is usually the problem, not the extraction method; see why a calculated field returns blank. And if the data has no Workday data source or report at all because it lives inside a custom Extend app, the source is the app's own model component, not any of the four methods above.

What each is actually good at

  • Volume: WQL and RaaS both return up to a million rows. WQL pages that result in increments of up to 10,000; RaaS returns it as one file. REST paginates its resource collections in smaller pages, sized for an application to consume rather than for bulk extraction.
  • Filtering and aggregation: WQL filters and groups in the query itself. RaaS filtering comes from the report's own prompts and definition, and it aggregates through the report's summary settings rather than a query clause.
  • Calculated fields: a report built in Report Writer, and so RaaS, can use any calculated field the report's data source allows. WQL reads the fields Workday exposes on a data source, which is not identical to a report's calculated-field set.
  • Security context: RaaS and WQL both apply the calling account's object and data-level security. REST and SOAP apply the calling account's security to each resource or operation individually, through the specific permission type that secures it.
  • Change detection: only RaaS is backed by a persisted, named Workday object, so only its definition shows up in Workday's own audit history. A WQL query, REST call or SOAP request is just text your integration owns; nothing in Workday tracks edits to it.
  • Stability across tenant changes: WQL runs against the same request text in another tenant by pointing it at a different host. RaaS does not: the report must be migrated or rebuilt in the new tenant before its URL works there.

Pick this if…

  • You already have (or can build) the right report, want an audited, reusable definition, and need a file in CSV, XML or a feed: pick RaaS.
  • You need a filtered, grouped or large paginated extract, want to change the query without touching Workday, or want to run the same request across tenants: pick WQL.
  • You are building an app or a narrow integration against one well-known resource, and want Workday's own versioned contract for it: pick REST.
  • The operation or field you need only exists in Workday's web-service layer: pick SOAP.
  • The requirement is really scheduling and delivery, or the data has no Workday source yet: look at EIB, Prism or an Extend model component instead.

Sources checked