Data Model

WQL APIs

When ConnectionType is set to WQL, the provider models Workday data sources as views. To get a complete list of these data sources, run the Data Sources standard report in Workday. The provider exposes each data source using its WQL Alias, which is shown on the View Data Source page.

The provider exposes two kinds of data sources:

Prism data sources provide access to published tables and dataset defined within Prism Analytics. All Prism data sources start with the prefix cds_. These data sources are easy to consume because they do not require providing values for prompts. They are also the most performant because they are served from dedicated Prism services. However, they must be created explicitly within the Prism Data Catalog, and are only updated when they are refreshed within Prism.
Core data sources provide access to built-in Workday data sources like Workers and Journals. Workday does not recommend using these sources directly, as they are both more difficult to query and slower than data sources from Prism. They use the same resources as the rest of your Workday tenant and complex queries (or queries returning many rows) can slow down your tenant for other users. The main behefit of these data sources is that they always contain live data instead of needing to be refreshed.

The provider does not list all the data sources defined within Workday. It only exposes data sources that are accessible to the authenticating user. For example, if the authenticating user has only HR roles, they may view data sources containing employee records, but not data sources about financial assets.

The provider only supports one data source filter per data source. When the unfiltered version of the data source is available, it picks the first filter when a filter is required. For further information, see WQLDataSourceFilters.

To work around this limitation, use UseSplitTables to split each data source into multiple views with fewer columns.

Reports

When ConnectionType is set to Reports, the provider also grants access to reports that are exposed using Reports as a Service (RaaS). These reports are exposed as views within the Reports schema. Accessing these reports requires extra connection setup beyond the basic settings for WQL access. For details on what it required, see Fine-Tuning Data Access.

REST APIs

The data model included in the REST section is only available when ConnectionType is set to REST.

SOAP APIs

The data models listed in Service are only available in the SOAP API. To use them, set ConnectionType SOAP.

Prompts

Many WQL data sources, reports, REST endpoints, and SOAP services have prompts that affect what rows Workday reports. The provider exposes these prompts as input columns that have the _Prompt suffix. Most prompts accept only a single value, but prompts that accept multiple values can be set with IN or equals:

SELECT * FROM [Account Balance Data]
WHERE Company_Prompt IN ('1234567890abcdef', 'f1234567890abcde')
AND Region_Prompt = 'ef1234567890abcd'
AND Include_Managers_Prompt = TRUE
AND Start_Date_Prompt = '2022-01-01'

Other filters may be included with prompts. These do not affect the way Workday generates the report, but the provider removes non-matching rows from the response:

SELECT * FROM [Account Balance Data]

/* Prompts */
WHERE Company_Prompt IN ('1234567890abcdef', 'f1234567890abcde')
AND Region_Prompt = 'ef1234567890abcd'
AND Include_Managers_Prompt = TRUE
AND Start_Date_Prompt = '2022-01-01'

/* Other filters */
AND Department = 'Sales and Marketing'
AND Account_Type = 'LIABILITY'

Request References

In addition to _Prompt columns, the SOAP data model also includes columns with the _RequestRef suffix. Request references are parameters that normally correspond to a data field that stores an ID. These parameters increase read performance by allowing the provider to request individual records, instead of requesting all records and filtering internally.

Normally the provider matches a request reference to its data field. When this happens the provider exposes only the data field and translates filters on the data field into request reference parameters. However, if the provider cannot match a request reference to a data field, it instead adds a separate _RequestRef column. These columns are used exactly the same way as _Prompt columns within queries.

Response Filters

The provider's SOAP data model includes one other type of input column that uses the _RespFilter suffix. These columns control the two date inputs within the response filter:

As_Of_Effective_Date_RespFilter tells Workday to retrieve records as they appeared on a given date. This allows you to either exclude changes after that date (if set to the past), or include changes before that date (if set to the future). By default the provider uses an effective date two years in the future.
As_Of_Entry_DateTime_RespFilter tells Workday to retrieve records that were created as of the given timestamp. At the start of a query, Workday determines what records should be returned and caches them on the current session. The provider provides the same entry timestamp for each page so that Workday returns consistent results from the cache. Setting this field is not recommended as most SOAP tables have data fields that store the created and last modified timestamp for each record. This field is included for cases where the default entry datetime causes the request to fail.

Aggregate Prompts

The SOAP data model includes endpoints with more complex prompts than other services. SOAP includes structured prompt values that the provider typically flattens into individual prompts. These can be provided as simple values (like text and timestamps) which the provider uses to build the XML for the SOAP request.

Sometimes this is not possible because the prompt contains complex repeated values that must appear together. For these cases the provider supports aggregate prompts provided as XML. The XML must have a root element called Rows, which contains child elements that match the criteria field. The criteria field itself has a different structure depending upon the specific table and prompt you are using. Refer to the Workday SOAP documentation for full definitions of each criteria type.

For example, the Workers table in the Human Resources schema has a prompt called Eligibility_Criteria_Data_Prompt. Workday documents the Eligibility_Criteria_Data structure as having three values: a single field, an optional effective date, and an optional entry timestamp. The following query provides two of these eligibility criteria values:

SELECT * FROM Human_Resources.Workers WHERE Eligibility_Criteria_Data_Prompt = 
'<Row>
  <Eligibility_Criteria_Data>
    <Field_Reference Descriptor="field a">
      <ID type="WID">abc123</ID>
    </Field_Reference>
    <As_Of_Effective_Date>2024-05-28</As_Of_Effective_Date>
  </Eligibility_Criteria_Data>
  <Eligibility_Criteria_Data>
    <Field_Reference Descriptor="field b">
      <ID type="WID">def456</ID>
    </Field_Reference>
    <As_Of_Entry_DateTime>2024-05-28T14:27:42-05:00</As_Of_Entry_DateTime>
  </Eligibility_Criteria_Data>
</Row>'

Note the following differences between the XML you provide here and what Workday natively accepts:

The provider inserts namespace prefixes on all elements and attributes. Your aggregate must not include any namespaces.
The provider does not change the text content of elements or the values of attributes. Workday rejects requests that have incorrectly formatted data, so you must be careful to format values according to Workday requirements. In this example, providing the value "May 28 2024" in the As_Of_Effective_Date element would cause the request to fail.

ADO.NET Provider for Workday