Overview
Recently, multiple Workday sources across Sandbox and Production environments have been impacted by the Workday S22 error.
The S22 error code in Workday indicates a “Permission Denied” response. This typically occurs during integration attempts (API or custom integrations) when the user account, API client, or security group lacks the necessary permissions or scopes required to perform a specific action.
This issue particularly affects Workday sources where either of the following are enabled:
- Workday Credential Authentication
- Workday Query Language (WQL) Data Source
Because WQL requires additional permissions in Workday, any missing scope or security domain permission can result in the S22 permission error during aggregation or API calls.
Impact
At present:
- Production Workday Sources
- A mitigation has been implemented through a feature flag that temporarily disables the WQL Data Source.
- These sources are currently relying only on the Worker API.
- Sandbox Workday Sources
- No automatic change has been applied.
- These environments are being used to validate the root cause and confirm the proper permission configuration required in Workday.
Note: Due to recent changes on the Workday side, this error started appearing in customer environments, and the steps outlined above should help resolve the issue
Cause
The S22 error can occur due to the following reasons:
1. Missing API Client Scopes
The OAuth API client configured in Workday may not have the required Functional Area scopes enabled.
2. Integration System User (ISU) Permissions
The Integration System User (ISU) may not have the necessary access to:
- Workday Query Language domains
- Worker data domains used by the connector
Without these permissions, WQL queries executed by the connector will fail.
Resolution
The resolution involves updating the API client scopes and validating the domain security permissions.
Phase 1: Update API Client Scopes in Workday
- Search for Edit API Client task in Workday.
- Select the API Client Integration used for OAuth 2.0
- Click OK
- Click on the Scope (Functional Areas) field
- Select Tenant Non-Configurable
- Click OK
Phase 2: Activate Security Changes and Validate
- Run the task ‘Activate Security Policy Pending Task’
- Login to the Identity Security Cloud (ISC) portal and perform below steps
- Perform a Test Connection on the Workday source to verify credentials.
- Initiate a Manual Aggregation.
Troubleshooting
If the S22 Permission Denied error persists after completing the steps above, verify that the Integration System User (ISU) has both View and Modify permissions for the following domains in Workday:
- Domain Security Policies for Functional Area → System → Workday Query Language.
- Domain Security Policies for Functional Area → Staffing → Worker Data : Staffing.
- Always run the Activate Pending Security Policy Changes task after modifying any domain policies.
Reference connector guide document Links:
- Workday Query Language - Permission to Workday Query Language domain
- Worker Data : Staffing- Permission to the Worker Data source
Validating WQL Using Postman
To determine whether the issue originates from Workday permissions or the connector, you can test the WQL query directly using Postman.
Step 1: Generate Access Token
Generate the OAuth access token using the same credentials configured in the Workday source.
Step 2: Create WQL Request
- URL :
https://{WORKDAY_HOST_URL}/api/wql/v1/{tenant_name}/data?limit=100&offset=0 - Method : POST
- Body :
{
“query”: “SELECT employeeID, workdayID FROM allWorkers (effectiveAsOfDate=‘2026-03-09’, entryMoment=‘2026-03-09T11:49:10.891-04:00’) WHERE currentlyActive = false AND currentWorkerRecord = true”
}
- WORKDAY_HOST_URL : Copy the value from the Workday Base URL up to
.com.
Why Is This Important?
The Workday Worker API does not always provide sufficient context in scenarios where a worker has multiple termination events within a short period. In such cases, the connector relies on Workday Query Language (WQL) to correctly identify the latest worker record and update the employee data in the source of truth.
Currently, WQL has been temporarily disabled in Production via a feature flag as a mitigation for the S22 error. As a result, the connector is relying solely on the Worker API, which may not return the correct termination record in certain edge cases.
This makes it important for customers to validate the required permissions and scopes in their Sandbox environment first, and then apply the same configuration in Production.
If the required permissions are not configured, the Workday connector may fail to aggregate the correct terminated worker record, particularly when a worker has multiple termination events within the configured Past_Termination_Offset window.
Next Steps
To restore full functionality and ensure accurate aggregation, please follow the steps below:
-
Validate the WQL request using Postman (optional but recommended) to confirm the query works successfully with the current permissions.
-
Update the required API client scopes and domain permissions in the Workday tenant in the Sandbox environment.
-
After updating the permissions in Workday, perform the following validation steps for the Workday Source in the Sandbox environment:
- Test Connection
- Manual Aggregation
- WQL query execution
-
Once validation is successful, apply the same configuration changes on the Workday tenant in the Production environment.
-
After the Production configuration is complete, notify the SailPoint team so the feature flag disabling WQL can be removed, allowing the connector to resume using WQL for worker aggregation.
Additional Notes
-
For SaaS connectors, there is currently no feature flag available to disable WQL. As a result, the only resolution is to update the required permissions and scopes in Workday. There is no alternative workaround, so customers are advised to add the required scopes as soon as possible.
-
For VA based source, we recommend that customers complete the validation and testing of the required scopes in their Sandbox environment and apply the same changes to Production by 30th March 2026.
-
Starting 31st March 2026, WQL will be automatically re-enabled in the Production environment. If the recommended configuration is not implemented in Production before this date, aggregation failures may occur. To avoid any impact, please ensure the required permissions are configured prior to this change.
-
If you complete the configuration earlier, please reach out to your Customer Success Manager (CSM) so the feature flag can be enabled sooner and your source can resume using WQL immediately.
-
This impact applies to all Workday connector variants, including:
- Workday
- Workday Accounts
- Workday StudentThis includes both Virtual Appliance (VA) and SaaS connector deployments where WQL is used for aggregation.