Core Connector Worker Cannot Obtain the List of Workers With Data Changes
What does "Core Connector Worker Cannot Obtain the List of Workers With Data Changes" mean in Workday Core Connector?
A Core Connector Worker integration fails right at the start, before it writes any output, because the first call it makes to gather changed workers is rejected. This is almost always a security gap on the account the integration runs as, not a fault in the connector configuration.
Quick fix
Grant the integration's user get access to the worker data domain covering public worker reports, then relaunch. Use the securable item search on the underlying worker retrieval operation to confirm the exact domain rather than guessing at it.
Permanent fix
Attach integration accounts to a dedicated security group whose domain access is maintained as a set, and grant that group whenever an integration is cloned. Review the field attributes each connector requests and confirm every backing domain is granted before the first run, so access gaps surface during build rather than at launch.
Troubleshooting
- Note that the run fails before any records are written. That points at the initial worker retrieval call, not at field level configuration further down.
- Identify the account the integration actually runs as. That is the integration system user attached to the integration system, not the person who pressed launch.
- Check that account's security groups for get level access to the domain covering public worker reports. Without it the first call fails and the run stops immediately.
- If the integration was cloned from a working one, compare the two side by side. Cloning copies the configuration but does not copy the security group memberships the original account relied on.
- Once the first call succeeds, expect a second wave of access failures on individual field attributes, and grant the domains behind those fields as well.