This page provides a guide to Establishing a Connection to Workday in CData Cloud, as well as information on the available resources, and a reference to the available connection properties.

Connecting to Workday

Establishing a Connection shows how to authenticate to Workday and configure any necessary connection properties to create a database in CData Cloud

Accessing Data from CData Cloud Services

Accessing data from Workday through the available standard services and CData Cloud administration is documented in further details in the CData Cloud Documentation.

Connect to Workday by selecting the corresponding icon in the Database tab. Required properties are listed under Settings. The Advanced tab lists connection properties that are not typically required.

Connecting to Workday

After you set the parameters for the desired API and have created a custom OAuth and/or Azure AD API client, you are ready to connect.

Connection Prerequisites

Obtaining the BaseURL and Tenant

To obtain the BaseURL and Tenant properties, log into Workday and search for View API Clients. On this screen, Workday displays the Workday REST API Endpoint, a URL that includes both the BaseURL and Tenant.

The format of the REST API Endpoint is: https://domain.com/<subdirectories>/mycompany, where:

• https://domain.com (the portion of the URL before subdirectories and company name) is the BaseURL.
• mycompany (the portion of the URL after the very last slash) is the Tenant.

For example, in the REST API endpoint https://wd3-impl-services1.workday.com/ccx/api/v1/mycompany, the BaseURL is https://wd3-impl-services1.workday.com and the Tenant is mycompany.

Enabling WQL Service

1. Open Workday.
2. In the search bar, search for View Domain.
3. At the prompt, enter Workday Query Language.
4. Check the Allowed Security Group Types to see if one of them includes the user you are connecting with.

Authenticating to Workday

This section describes both methods of authentication.

OAuth

Note: Because they facilitate authentication to Workday APIs, this document frequently refers to custom OAuth applications as custom API Clients.

Authenticating as a Normal User

After you have an API client configured, set the following properties to connect using Workday credentials:

Standard OAuth User

• ConnectionType and related properties.
• AuthScheme: OAuth.
• OAuthClientId: The Client ID obtained from the View API Client page.
• OAuthClientSecret: The Client Secret obtained from the View API Client page. If you are using a public client, leave this blank.
• Tenant: The tenant for the account.
• BaseURL: The base URL for the REST API Endpoint in the View API Clients page.
• OAuthAuthorizationURL: Optional but recommended. The Authorization URL in the View API Clients page.

AzureAD User

• ConnectionType and related properties.
• AuthScheme: AzureAD.
• OAuthClientId: The Client ID obtained from the View API Client page.
• Tenant: The tenant for the account.
• BaseURL: The base URL for the REST API Endpoint in the View API Clients page.
• SSOProperties: The Azure-specific properties used for SSO, including the AzureTenant, AzureClientId, AzureClientSecret and Resource.

Authenticating as an ISU

To authenticate as an ISU, you must first create either an API Client or an API Client for Integrations, as described in Creating a Custom API Client Application. You can create either of these clients using the JWT bearer grant type.

After you set the appropriate properties, you are ready to connect.

API Client for Integrations

• ConnectionType and related properties.
• AuthScheme: OAuthISU.
• OAuthClientId: The Client ID obtained from the View API Client page.
• OAuthClientSecret: The Client Secret obtained from the View API Client page.
• OAuthRefreshToken: The refresh token obtained from the Manage Refresh Tokens for Integrations page.
• Tenant: The tenant for the account.
• BaseURL: The base URL for the REST API Endpoint in the View API Clients page.

API Client (JWT)

• ConnectionType and related properties.
• AuthScheme: OAuthJWT.
• OAuthJWTCertType: The certificate type. If you created the certificate with keytool or openssl pkcs12, this should be PFXFILE.
• OAuthJWTCert: The path of the certificate file you created.
• OAuthJWTCertPassword: The password of the certificate file you created.
• OAuthJWTIssuer: The Client ID obtained from the View API Client page.
• OAuthJWTSubject: The username of the ISU you are using.
• Tenant: The tenant for the account.
• BaseURL: The base URL for the REST API Endpoint in the View API Clients page.

Reports and SOAP API

To use Basic authentication, set these connection parameters:

• ConnectionType: SOAP or Reports.
• AuthScheme: Basic.
• User: The Workday user account name.
• Password: The Workday user's password.
• Tenant: The tenant for the account.
• BaseURL: The base URL for the REST API Endpoint in the View API Clients page.

Other authentication methods are configured the same way as for the WQL and reporting services.

Fine Tuning Data Access

SOAP API

When connecting with ConnectionType set to SOAP, the following properties will determine what tables are exposed:

• Service: A comma-separated list of Workday WSDLs to load. Each WSDL contains one schema which exposes multiple tables.
• WSDLURL: The URL to load a Workday WSDLs from. If provided, this will override Service and present WSDLs tables under the Workday schema.
• WSDLVersion: The version of the Workday API to load the WSDLs for. This can be used to request a newer or older version of the Workday data model.

Accessing Reports as a Service

When connecting with ConnectionType set to Reports, the Cloud supports reading reports that have been exposed through Workday Reports as a Service (RaaS). Workday does not have a built-in way for the Cloud to determine which reports have been exposed via RaaS, so you must create a custom report to use this feature:

1. Open the Create Custom Report form.
2. Name the report Reports as a Service.
3. Enter Advanced for the report type.
4. Select Enable As Web Service.
5. Clear Optimized for Performance.
6. Enter All Custom Reports for the Data Source.

After the report is created, you need to add a few columns and filters:

1. In Fields
   • For the first column, enter Report Name.
   • Add a second colum and enter Web Service Namespace.
   • Add a third colum and enter Report Owner.
   • Add a fourth colum and enter Brief Description.
2. Make sure all columns have the primary business object as their Business Object. The primary business object has the name Custom Report and should have a box-and-arrow icon beside it. If the icon is an ellipsis (...) instead, then click menu , select Primary Business Object and then Custom Field.
3. Open the Filter tab and create a new filter. Enter Web Service Namespace as the field and is not blank as the Operator.
4. Add a second filter. Enter Current User as the field, in the selection list as the Operator, Value from Another Field as the comparison type, and Authorized Users as the comparison value.
5. Click OK to save the report. If Workday displays any warnings then click OK again to dismiss them.

Note that the Current User filter is optional but recommended. It is there to ensure that the Cloud does not surface reports that your account does not have permissions to view. However, if the report has performance issues then the filter can be removed.

The final step is to find the URL associated with the report. This URL is used to set the CustomReportURL connection property.

1. Open the newly created report.
2. Click the ellipsis (...) button beside the report title in the upper-left corner of the screen
3. Find the Web Services tab within the pop-up. You may have to scroll down inside the pop-up to see it.
4. Hover over it and select View URLs.
5. Copy the Workday XML link.

Change Process Permissions (REST API)

The permissions used by the Begin and Submit stored procedures (see REST) are configured differently to other REST resources. The permissions for each change resource is determined by its underlying business process. For example, executing BeginOrganizationAssignmentChange triggers the Change Organization Assignments for Worker business process within Workday

If you find that the the Cloud is unable to start a business process, update the processs security policy as follows:

1. Open the Edit Business Process Security Policy task. Provide the name of the business process at the prompt.
2. In the Who Can Start the Business Process section, find the initiating action containing the text REST.
3. Add a security group that covers the user or integration service user configured with the Cloud.
4. Execute the Activate Pending Security Policy Changes task to apply the change.

Reports

No Valid RaaS Reports

The Cloud discovers reports by accessing the catalog report indicated by the CustomReportURL property. If the output of the catalog report is not valid, the Cloud states that the report "does not list any valid RaaS reports" and fails the connection. There are a few common reasons for this:

1. The schema of the catalog report is incorrect. You should check that the report has all the columns described by Fine-Tuning Data Access. In addition, make sure that the Column XML Alias is empty on each field. A missing field or invalid alias prevents the Cloud from processing the data in the catalog report.
2. The user does not have access to any reports. For each report you want the user to access, you should check that the user can access the data source used to create the report. The report itself must also be accessible to the user. The user should either own the report, or have access through the options listed in the Share tab in the report definition.
3. The report is not web service enabled. To verify this, run the catalog report by hand and check that the Web Service Namespace column is not empty. If it is, go to the report definition, open the Advanced tab, and activate the Enable As Web Service option. Note that this option is not available for all types of reports.

SOAP

Invalid Request

While connecting to the SOAP service, you may receive an error stating "Invalid Request". This is a server-side Workday error. It often indicates that your user account has not been granted the permissions required to either connect via the API, or to obtain the specific information you have requested.

The tables and columns are retrieved from a publicly available service that requires no authentication, so this error may appear while either testing the connection, or when trying to retrieve data after metadata has been obtained.

The Task Submitted is not Authorized

While connecting, you may receive an error stating "Processing error occurred. The task submitted is not authorized".

This is a server-side error Workday error. This error typically indicates that your Workday account does not have the necessary module activated to access the table or Service you are attempting to connect to.

Ensure the correct module is activated if you receive this error. The Cloud is unable to dynamically determine which modules are available at runtime, but the exposed services can be configured via the Service connection property.

Required Scopes and Endpoint Domains for Workday

These permissions are defined by access scopes, which determine what data your application can access and what actions it can perform.

This topic provides information about the required access scopes and endpoint domains for the Workday Cloud.

Understanding Scopes

Scopes are a way to limit an application's access to a user's data. They define the specific actions that an application can perform on behalf of the user.

For example, a read-only scope might allow an application to view data, while a full access scope might allow it to modify data.

Required Scopes for Workday

Understanding Endpoint Domains

Endpoint domains are the specific URLs that the application needs to communicate with in order to authenticate, retrieve records, and perform other essential operations.

Allowlisting these domains ensures that the network traffic between your application and the API is not blocked by firewalls or security settings.

Note: Most users do not need to make any special configurations. Allowlisting is typically only necessary for environments with strict security measures, such as restricted outbound network traffic.

Required Endpoint Domains for Workday

Customizing the SSL Configuration

By default, the Cloud attempts to negotiate TLS with the server. The server certificate is validated against the default system trusted certificate store. You can override how the certificate gets validated using the SSLServerCert connection property.

To specify another certificate, see the SSLServerCert connection property.

Connecting Through a Firewall or Proxy

HTTP Proxies

To authenticate to an HTTP proxy, set the following:

• ProxyServer: the hostname or IP address of the proxy server that you want to route HTTP traffic through.
• ProxyPort: the TCP port that the proxy server is running on.
• ProxyAuthScheme: the authentication method the Cloud uses when authenticating to the proxy server.
• ProxyUser: the username of a user account registered with the proxy server.
• ProxyPassword: the password associated with the ProxyUser.

Other Proxies

Set the following properties:

• To use a proxy-based firewall, set FirewallType, FirewallServer, and FirewallPort.
• To tunnel the connection, set FirewallType to TUNNEL.
• To authenticate, specify FirewallUser and FirewallPassword.
• To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.

The CData Cloud models Workday data as an easy-to-use SQL database with tables, views, and stored procedures.

The Cloud exposes four data models, which you select in ConnectionType:

• WQL exposes Workday data sources as read-only views using the Workday Query Language (WQL) service.
• Reports exposes Workday reports as views using Reports as a Service (RaaS). When ConnectionType is set to Reports, the Cloud 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 is required, see Fine-Tuning Data Access.
• REST exposes Workday data as tables and views using the REST API.
• SOAP exposes Workday data as views using the SOAP API. The data models listed in Service are only available in the SOAP API.

Note: For performance reasons, you should use WQL instead of SOAP in most situations. WQL generally is much more performant because it supports server-side filtering and aggregation.

Stored Procedures

Many WQL data sources, reports, REST endpoints, and SOAP services have prompts that affect what rows Workday reports. The Cloud 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 Cloud 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'

SOAP-Only Input Columns

The Cloud's SOAP data model includes other types of input columns that are not found on other data models. They allow you to control other aspects of the SOAP request. Like prompt columns, each type of input has its own suffix to distinguish it from other inputs.

Request References

Normally the Cloud matches a request reference to its data field. When this happens the Cloud exposes only the data field and translates filters on the data field into request reference parameters. However, if the Cloud cannot match a request reference to a data field, it instead adds a separate column with a _RequestRef suffix.

Response Filters

• 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 Cloud 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 Cloud 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.

Response Groups

Normally the Cloud determines the response groups automatically. Either the response group is hardcoded (see IgnoreHardcodedIncludes), or the Cloud calculates response groups based on the table and columns in the query. This process does not always given correct results because the Workday API does not explicitly report what fields each include and exclude affects. The Cloud has to guess based on the names of the response groups.

Setting response groups manually is useful for tables with response groups that do not follow the usual pattern. You should make sure that queries return the expected data when you provide response groups manually. Providing a single response group input will disable all hardcoded and automatically determined groups for the table you are querying. Incorrect response groups can return too little data, or reduce read performance by returning too much data.

Aggregate Prompts

Sometimes this is not possible because the prompt contains complex repeated values that must appear together. For these cases the Cloud 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 Cloud inserts namespace prefixes on all elements and attributes. Your aggregate must not include any namespaces.
• The Cloud 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.

When ConnectionType is set to WQL, the schema exposes Workday data sources as read-only views using the Workday Query Language (WQL) service. The Views section contains examples of read-only SQL tables that might be available. All the data sources used by these views are part of core Workday and the HCM module. To get a complete list of these data sources, run the Data Sources standard report in Workday.

Common views include:

Views are similar to tables in the way that data is represented; however, views are read-only.

Queries can be executed against a view as if it were a normal table.

CData Cloud - Workday Views

Accesses the Allowance Plan as the primary object and returns one row per plan. Includes all allowance plans. Does not contain built-in prompts. This data source delivers the additions and removals for plans over time.

Columns

Accesses the Bonus Plan as the primary object and returns one row per bonus plan. Includes all active bonus plans. Does not contain built-in prompts. The data source delivers the additions and removals for bonus plans over time.

Columns

Accesses the Compensation Plan as the primary object and returns one row per plan. Includes all active plans. Does not contain built-in prompts. This data source delivers the additions and removals for plans over time.

Columns

Accesses the Compensation Rule as its primary object. The Compensation Rule object returns one row per Compensation Rule. Includes all Compensation Rules. Does not contain any built-in prompts.

Columns

Accesses Job Profile as the primary object and returns one row per job profile. Includes all active and inactive job profiles. Does not contain built-in prompts.

Columns

Accesses the Merit Plan as the primary object and returns one row per plan. Includes all active and inactive plans. Does not contain any built-in prompts. The data source delivers the additions and removals for plans over time.

Columns

Accesses the Position as its primary object. The Position object returns one row per position. Includes only open positions that are in supervisory organizations that the user has access. Does not contain any built-in prompts.

Columns

Accesses Pre-Hire as the primary object and returns one row per pre-hire. Includes all pre-hires as well as pre-hires converted to hires. Does not contain built-in prompts.

Columns

Accesses the Workday Account object and returns one row per Workday account. Includes all Workday accounts ever created, either currently enabled or not. Does not contain built-in prompts. This data source will show settings of the user login information and preferences in Workday.

Columns

Accesses the Worker as its primary object and returns one row per worker. Includes all workers even workers to be hired in the future. Does not contain any built-in prompts. This data source can be used to build reports on all workers. Helpful Tips - 1) If the worker is hired in the future, all fields will be returned based on the effective date. 2) If no effective date is specified, the system will use the current date as the effective date. 3) If the effective date is less than the worker's hire date, no effective dated information (such as position information, compensation information and so on) will be returned. 4) If effective dated behavior is desired, use the "All Active and Terminated workers" data source instead.

Columns

Returns all classes accessible by the current user

Columns

Accesses the Organization as its primary object. The Organization object returns one row per organization. Only includes supervisory organizations that the user manages. Prompts the user at run-time for Supervisory Organization to automatically filter the report results.

Table Specific Information

Select

The Workday Cloud requires filtering on organizations_Prompt in order to perform the query.

For example:

SELECT * FROM organizationsIManage WHERE organizations_Prompt = '1fcf0b79747a43d1a4de334e0c214b1b';

Columns

Accesses the Position Group as its primary object. The Position Group object returns one row per Position Group. Includes all unfilled and filled Positions. Prompts the user at run-time for a Compensation Rule to automatically filter the report results.

Table Specific Information

Select

The Workday Cloud requires filtering on compensationEligibilityRule_Prompt in order to perform the query.

For example:

SELECT * FROM positionsValidForCompensationSelectionRule WHERE compensationEligibilityRule_Prompt = '1fcf0b79747a43d1a4de334e0c214b1b';

Columns

Accesses the Organization object and returns one row per organization. Includes all active and inactive organizations with no superior. Does not contain built-in prompts.

Columns

Accesses the Organization as its primary object. The Organization object returns one row per organization.

Table Specific Information

Select

The Workday Cloud requires filtering on organization_Prompt in order to perform the query.

For example:

SELECT * FROM topLevelOrganizationsAndSubordinates WHERE organization_Prompt = '1fcf0b79747a43d1a4de334e0c214b1b';

Columns

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

The Cloud 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 Cloud 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 Cloud 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.

When ConnectionType is set to REST, the Cloud models Workday information as an easy-to-use SQL database with tables and views.

Tables

The Tables section, which details standard SQL tables, and the Views section, which lists read-only SQL tables, contain samples of what you might have access to in your Workday account.

Common tables include:

The Cloud models the data in Workday as a list of tables in a relational database that can be queried using standard SQL statements.

CData Cloud - Workday Tables

Records ad hoc project-time transactions. This table allows tracking of manually entered work hours for project-based assignments, workforce planning, payroll processing, and cost allocation.

Workday Resource Information

Columns

Manages file attachments that are associated with cases. This table enables users to upload supporting documents, images, or records during case creation for compliance, auditing, and issue resolution.

Table Specific Information

Select

The Workday Cloud requires filtering on Id in order to perform the query.

For example:

SELECT * FROM Attachments WHERE Id = 'f8e80f38f2af100009b00e67c49b12f2';

Workday Resource Information

Columns

Get Audience

Workday Resource Information

Aggregate Fields

The Cloud represents the following fields as aggregates containing JSON text. Each of them conforms to their respective schema. Fields marked with an asterisk are required and must be included if their parent object is. Fields marked with a hyphen are read-only and must not be included when calling stored procedures or when performing an INSERT or UPDATE.

This information is derived from the Workday REST API specification which does not explicitly list all business rules and validations that apply to each object. More fields may be required than what is listed here.

CampaignCategory_Aggregate

[{
  descriptor: Text /* A preview of the instance */
  id: Text /* Id of the instance */
}]

ConnectTypes_Aggregate

[{
  descriptor: Text /* A preview of the instance */
  id: Text /* Id of the instance */
}]

ExcludesWorkers_Aggregate

[{
  descriptor: Text /* A preview of the instance */
  id: Text /* Id of the instance */
}]

IncludesWorkers_Aggregate

[{
  descriptor: Text /* A preview of the instance */
  id: Text /* Id of the instance */
}]

Columns

Reads /campaignCategory entries from the Audiences table.

Workday Resource Information

Columns

Reads /connectTypes entries from the Audiences table.

Workday Resource Information

Columns

Reads /excludesWorkers entries from the Audiences table.

Workday Resource Information

Columns

Reads /includesWorkers entries from the Audiences table.

Workday Resource Information

Columns

Contains detailed records of billable transactions. This table captures information such as transaction amounts, associated accounts, billing periods, and customer details for financial processing and revenue tracking.

Workday Resource Information

Columns

Maintains a record of cases that a user has access to view.This table supports issue tracking, employee relations cases, IT service requests, and customer support interactions.

Workday Resource Information

Aggregate Fields

The Cloud represents the following fields as aggregates containing JSON text. Each of them conforms to their respective schema. Fields marked with an asterisk are required and must be included if their parent object is. Fields marked with a hyphen are read-only and must not be included when calling stored procedures or when performing an INSERT or UPDATE.

This information is derived from the Workday REST API specification which does not explicitly list all business rules and validations that apply to each object. More fields may be required than what is listed here.

Attachments_Aggregate

[{
  contentType: { /* Content type of the attachment */
     -descriptor: Text /* A description of the instance */
     -href: Text /* A link to the instance */
     *id: Text /* wid / id / reference id */
  }
  descriptor: Text /* A preview of the instance */
  fileLength: Numeric /* File length of the attachment */
  fileName: Text /* File name of the attachment */
  id: Text /* \~Case\~ Attachment ID. */
}]

QuestionnaireResponses_QuestionnaireAnswers_Aggregate

[{
  answerDate: Date /* The answer in a date format. */
  answerMultipleChoices: [{
      descriptor: Text /* A preview of the instance */
      id: Text /* Id of the instance */
  }]
  answerNumeric: Numeric /* The answer in a numeric format. */
  answerText: Text /* The text answer for a questionnaire. */
  descriptor: Text /* A preview of the instance */
  id: Text /* Id of the instance */
  questionItem: { /* Question Item for Questionnaire Answer. Question item represents the question in a questionnaire. */
     -descriptor: Text /* A description of the instance */
     -href: Text /* A link to the instance */
     *id: Text /* wid / id / reference id */
  }
  questionnaireAttachments: [{
      contentType: { /* Content type of the attachment */
         -descriptor: Text /* A description of the instance */
         -href: Text /* A link to the instance */
         *id: Text /* wid / id / reference id */
      }
      descriptor: Text /* A preview of the instance */
      fileLength: Numeric /* File length of the attachment */
      fileName: Text /* File name of the attachment */
      id: Text /* Id of the instance */
  }]
}]

Columns