# Troubleshooting

If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support.

For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information:

- [SailPoint Identity Services Documentation](<https://documentation.sailpoint.com/saas/help/index.html>)
- [SailPoint Support Knowledge Base](<https://support.sailpoint.com/csm?id=kb_view2&amp;kb_id=05ff44289f011200550bf7b6077fcfa3>)
- [SailPoint Developer Community](<https://developer.sailpoint.com/>)

## Account Aggregation Returns Zero Accounts

**Issue**: Account aggregation completes successfully but returns no accounts from Workday. The integration user may lack the required domain security policy permissions, even if all documented permissions have been assigned.

**Resolution**: Ask the customer's Workday administrator to verify and configure the following permissions:

1. In Workday, search for **Domain Security Policies for Functional Area**.
2. Select **Staffing** and go to **Worker Data: Workers**.
3. Under the **Integration permission** section, verify that the SailPoint security group is listed.

   - If the security group is not present, add it to the Integration permission section.
4. Run the **Activate Pending Security Policy Changes** task.
5. Verify that the issue is resolved.

## Aggregation Is Passed but the SECURITY\_GROUPS Attribute Is Not Fetched

**Issue**: During entitlement aggregation in the Workday Accounts, you may encounter one of the following:

- Aggregation completes successfully, but the `SECURITY_GROUPS` attribute is not returned.
- Aggregation fails with the following error:

  ```text
   invalid request: WQL error.",
   "errors":[{"error":"Enter a valid report field. This field is invalid: cf_SecurityGroupName.",
   "field":"cf_SecurityGroupName",
   "location":"Invalid SELECT clause"
  ```

**Resolution**: Check with your Workday team to verify and correct the configuration by following these steps:

1. In the search bar, enter **Edit Calculated Field**.
2. Search for Security Group Name from the list of **Calculated Field**.
3. Under the Additional Info section, verify that the **WQL Alias** Name is set exactly as follows: `cf_SecurityGroupName`.

   > **Note**
   >
   > The alias is case-sensitive and must be entered exactly as shown.
4. If the alias is incorrect or missing, update it accordingly.
5. Save the changes and re-run the entitlement aggregation.

## Workday Accounts Connector Does Not Provision Multiple Requests Simultaneously

**Resolution**: This is a limitation of the Workday API, where multiple provisioning requests containing different entitlements cannot be processed simultaneously. As a workaround, customers should include all required entitlements within a single provisioning request.

## Create Account Operation Fails

**Issue**: The Create Account operation fails with the following error: `Please check the logs. Either username, filenumber, or worker-type is empty.`

**Resolution**: The Create Account policy must include values for username, filenumber, and worker-type. If any of these values are missing, the operation will fail with the error mentioned above.

## The Task Submitted Is Not Authorized

**Issue**: Account aggregation fails with the error message `The task submitted is not authorized.`

**Resolution**: GET Permissions for the attribute "User-based Security groups". This corresponds to the element `USER_BASED_SECURITY_GROUPS` on the default account schema.

## Aggregation Is Taking a Long Time to Complete

**Resolution**: In order to improve the performance of the aggregation, specify the following parameter:

```text
POST https://{orgName}.api.identitynow.com/cc/api/source/update/{workdaySourceID}

Form-Data:

key: connector_aggregationThreadSize
value: 4
```

> [!NOTE]
>
> The value of the thread needs to be determined as per the VA configuration.

## Test Connection Operation Fails with OAuth 2.0 Authentication When There Are Bulk Accounts Present in the Workday Accounts Source

**Issue**: The test connection operation fails with the following error: `Reduce the number of instances returned by using request criteria, response filters, or date ranges. Your request returns <number of instances>, which is more than the limit of 1000000.`

**Resolution**: Use the lightweight test connection operation for OAuth 2.0 authentication by setting `lightWeightTestConnection` to `true` using the SailPoint REST APIs. Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>).

> [!NOTE]
>
> In this case, if the "Integration" permission is not provided, add this functional area permission to the API Client Integration used for OAuth 2.0.

## Account Aggregation of Service Center Representative Accounts Fails

**Issue**: Account aggregation of service center representative accounts fails with the error: `The task submitted is not authorized.`

**Resolution**: Verify the following:

- For Basic authentication, the service account must include the *Manage: Service Center* permission.
- For OAuth 2.0 authentication, the Workday Account used by the API Client to generate the refresh token must be an integration user and have the *Manage: Service Center* permission.

## Test Connection Fails with a Connection Reset Error

**Explanation**: This issue generally occurs when there is a firewall between SailPoint and the Workday tenant, or SailPoint is installed on a Linux system and the connection gets blocked due to a firewall/network issue.

**Resolution**:

- Verify whether any firewall rule is present in the customer's environment. If so, verify that port 443 and the Workday URL are unblocked.
- It has been observed that when a customer sends the following request from another machine using Postman/a SOAP tool, they receive a response. Ideally, it should be tested from the virtual appliance server using the following `curl` command. The customer needs to create an XML file on the VA with the following request, provide the username and password from the application XML, and run the `curl` command from the terminal:

  ```text
  curl -X POST -d @TestConnection.xml https://wd2-impl-services1.workday.com/ccx/service/{tenant_name}/Human_Resources
  ```

  ```xml
  <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:bsvc="urn:com.workday/bsvc">
  <soapenv:Header>
  <Security
  xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
  <UsernameToken>
  <Username>XXXXXX</Username>
  <Password>XXXXXX</Password>
  </UsernameToken>
  </Security>
  </soapenv:Header>
  <soapenv:Body>
  <ns1:Get_Workers_Request xmlns:ns1="urn:com.workday/bsvc"
  ns1:version="v32.1">
  <ns1:Request_Criteria>
  <ns1:Exclude_Inactive_Workers>false</ns1:Exclude_Inactive_Workers>
  <ns1:Exclude_Employees>false</ns1:Exclude_Employees>
  <ns1:Exclude_Contingent_Workers>false</ns1:Exclude_Contingent_Workers>
  </ns1:Request_Criteria>
  <ns1:Response_Filter>
  <ns1:Page>1</ns1:Page>
  <ns1:Count>1</ns1:Count>
  </ns1:Response_Filter>
  <ns1:Response_Group>
  <ns1:Include_Reference>true</ns1:Include_Reference>
  <ns1:Include_Roles>true</ns1:Include_Roles>
  </ns1:Response_Group>
  </ns1:Get_Workers_Request>
  </soapenv:Body>
  </soapenv:Envelope>
  ```
- If the terminal throws any error for the above command, check with the Network Team.

## Workday Account Connection Is Successful but Aggregation Fails

**Explanation**: `<faultcode>SOAP-ENV:Client.validationError</faultcode>` The entered information does not meet the restrictions defined for this field.

**Resolution**: This error occurs due to a permission issue. To avoid this, make sure that the service account is added to an unconstrained security group.
