Core Connector Worker Fails Mid-Run: The Call to Get_Workers Failed, Task Submitted Is Not Authorized
The error The call to the Get_Workers web service operation failed. This may be related to insufficient privileges held by the user account configured for the integration. The reported problem was: Processing error occurred. The task submitted is not authorized. at ParallelMediation.request.0.ParallelPagedGet
What does "The call to the Get_Workers web service operation failed" mean in Workday Core Connector?
The connector launched successfully but failed while fetching worker data, because the integration user lacks Get access to a domain that Get_Workers reads. This is a data-retrieval permission gap, not a launch permission gap.
Quick fix
Grant the integration user's security group Get and Put integration permissions on the worker data domain named by Security for Securable Item, activate the change, and relaunch.
Permanent fix
Derive the domain list from Security for Securable Item for every operation a connector calls, and grant those domains when the integration system is built rather than reacting to the first failed run. Keep integration security groups per interface family so adding a data section to one connector cannot silently widen access for another.
Troubleshooting
- Separate this from a launch failure. The trailing ParallelPagedGet shows the integration was already running and was paging worker data, so the launch security is fine and the missing permission is on the web service operation.
- Run Security for Securable Item against Get Workers and read back the domains that govern it, rather than working from memory or from another tenant's configuration.
- Check that the integration user's security group has Get access, specifically integration permissions, on the worker data domains that operation reads. View access alone is not enough for a web service call.
- Compare against a working connector in the same tenant. If another integration retrieves workers successfully, diff the two integration systems' security groups rather than auditing every domain.
- Activate pending security policy changes before retesting. An unactivated policy change looks identical to no change at all.
- If it still fails after activation, narrow the population with a launch parameter. A failure that only appears for some workers points at a domain covering a specific data section rather than at worker access in general.
Was this helpful?