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.

During entitlement aggregation in the Workday Accounts Connector, you may encounter one of the following issues:

  • Aggregation completes successfully, but the SECURITY_GROUPS attribute is not returned.

  • Aggregation fails with the following error:

    Copy 
     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 form 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.

The account aggregation fails with the following error message:

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

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

POST https://{orgName}.api.identitynow.com/cc/api/source/update/{workdaySourceID}
Form-Data: key:connector_aggregationThreadSize
value: <Number of aggregation Threads/>

Copy 
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

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 light weight test connection operation for OAuth 2.0 authentication by setting lightWeightTestConnection to true using the Identity Security CloudREST APIs. Refer to Best Practices: REST API Authentication and REST API - Update Source (Partial).

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.

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.

Explanation : This issue generally occurs when there is firewall in between Identity Security Cloud and Workday tenant or Identity Security Cloud is installed in Linux system and due to firewall/network issue the connection gets blocked.

Resolution:

  • Please verify if there are any firewall rule present in the customer’s environment. If so, please check port 443 and Workday URL is unblocked .

  • It has been observed that when customer hits the below request from another machine using postman/soap tool, they receive the response. But ideally, it should be tested from server of virtual appliances using below CURL command. Customer needs to create a xml file on VA adding below request and in the file they need to provide the username and password as provided in application xml and hit the below CURL command from terminal.

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

    <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 terminal throws any error for above command then they can check with Network Team.

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 the permission issue. To avoid this instance, make sure that the service account is added to an unconstrained security group.

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.

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.