How to Set Up Workday RaaS: Turn a Custom Report into a Web Service, Step by Step

To set up Workday RaaS (Reports as a Service), build or copy an advanced or search custom report, select Enable As Web Service on it, then open Web Services > View URLs from the report's related actions menu and copy the link for the output format you want. Anything that can call that URL with a Workday account allowed to see the report can then read its results.

This page is the setup procedure. If you are still deciding between RaaS, WQL and the REST APIs, read RaaS, WQL, REST or SOAP: which to use first.

Which reports can be a web service

Only advanced and search reports. Workday's setting for web services appears under the Advanced tab for those two types and nowhere else, so a simple, matrix or composite report has to be rebuilt as an advanced report before it can be served this way.

If the report you want is a Workday standard report, do not enable that one. Run Copy Standard Report to Custom Report (or Copy Custom Report for one you already own) and enable the copy. Workday recommends this because a change Workday makes to a standard report would otherwise change the output of every integration reading it.

Enable the report as a web service

You need the Custom Report Creation and Manage: All Custom Reports domains in the System functional area.

1. Run Create Custom Report, choose Advanced (or Search) as the report type, and select Enable As Web Service on the first page. For an existing report, run Edit Custom Report instead.
2. Open the Advanced tab. The Web Services Options section holds Enable As Web Service and Namespace.
3. Leave Namespace as Workday generated it unless you have a reason to change it. It follows the form urn:com.workday.report/Report_Name and does not change when the report is renamed or changes owner, which is deliberate: it keeps downstream integrations working.
4. Save the report.

Treat the namespace as part of the contract. Workday does not check that two reports have different namespaces, and if you edit one in the report definition without updating the requests that call it, those requests fail.

Get the report URL

1. Open the report definition and choose Web Services > View URLs from the related actions menu.
2. Enter a value for every prompt the report requires. Workday will not show output until you do.
3. Download the output file, or right-click the format you want and select Copy URL.

The same page also gives the other bindings. For SOAP, Web Services > View URLs has a WSDL link; Web Services > View WSDL shows the schema, from which you copy everything between the opening and closing xsd:schema tags if your tool wants a schema file.

Workday documents the URL like this:

https://<workday-url>/<tenant>/<username>/<report_name>?<prompt>=<value>&format=<format>

Here <username> is the report owner and <report_name> is the report name with spaces replaced by underscores. Copy the URL from View URLs rather than assembling it by hand. Workday's Studio material builds a report call from the path segment customreport2/<tenant>/<owner>/<report_name>, so expect that shape in the link.

One documented trap: GET requests for a custom web-service report fail if the owner's username contains a backslash. If the owner's username has one, the report needs a different owner.

Pass prompts as URL parameters

Each prompt on the report becomes a query parameter. The parameter name is the Label For Prompt XML Alias on the report's Prompts tab, a field that only appears once the report is a web service. Set it deliberately; do not leave it to whatever Workday generated.

The value follows the type of prompt:

Workday's own example, for a report owned by lmcneil in a tenant named gms:

https://<workday-url>/gms/lmcneil/Organization_Headcount?Organization%21WID=cb550da820584750aae8f807882fa79a&Include_Subordinate_Organizations=1&format=json

You can change these values in the URL without opening Workday, which is how a scheduler or another system runs the same report for a different organization or date.

Choose the output format

Add format= to the URL. The documented values are csv, gdata, json, rss and simplexml. Workday XML has its own link on the View URLs page, alongside an XSD and a WSDL.

• CSV is the quickest route into a spreadsheet. For UTF-8 CSV that opens correctly in Excel, add &bom=true. On advanced reports with column-group headings, CSV drops the grouping and may not keep the report's column order.
• JSON suits system-to-system calls.
• Simple XML flattens single and multi-instance fields to plain strings (multi-instance values separated by semicolons) and drops times from date-only fields. It is the easier choice for desktop tools. Workday XML is the literal Workday output, which is what REST and SOAP integrations usually want.
• RSS lets a person subscribe to an advanced report from a feed reader.

Who is allowed to call it

Enabling a report as a web service does not open it to the world. Workday limits the link to people with a valid account in the tenant and the security to see both the report and its data. Two settings decide that for a given caller:

• The Share tab on the report. Choose to share with all authorized users, or with specific groups and users, and the caller must be inside that set. Only groups with access to the data source and its filter can be chosen.
• The caller's own access to the data source and fields. RaaS returns what that account would see running the report in the browser, no more.

An integration should call the report as an integration system user in its own security group, not as a person. The setup, including the domain permissions and the API client, is in Workday integration system user and API client setup.

Limits to know before you build

• Workday gives web-service requests six hours to finish on a tenanted host, and five minutes through the Workday Cloud Platform gateway.
• A RaaS result can hold up to 1 million rows, but it comes back as one response. RaaS has no pagination and no GROUP BY; if you need a result in pages, WQL does that.
• A report set to Background Only needs the right permissions and a valid URL to run.

When a RaaS call fails

Workday's RaaS pages do not list error messages, so work from the causes they do document:

• Request worked yesterday and fails today. Someone edited the Namespace without updating the caller.
• GET request fails from the start. The report owner's username contains a backslash.
• Request returns nothing or is refused for one caller only. Check the Share tab and that caller's access to the data source. If the report returns empty for a person who can open it in the browser, see why a Workday report returns no rows.
• Output is missing a prompt or filters the wrong population. The parameter name must match the Label For Prompt XML Alias exactly, and single-instance prompts need the %21WID suffix with a Workday ID.
• Accented characters turn into garbage in Excel. Add &bom=true to a UTF-8 CSV request.

Enabling the web service is also what lets you use the report in an outbound EIB; see reading EIB results and errors for what to look at after the run.