Studio WorkdayOutREST GET on Custom Object Returns 404 Until the Record Is Manually Edited
What it means
A Studio WorkdayOutREST GET call against a custom object record returns 404 even though the record clearly exists and looks correct in the UI. Manually opening and saving the record in the tenant, even without changing any values, makes the same GET call start succeeding, which points to the record never having been indexed for REST retrieval rather than a path or permissions problem.
Troubleshooting
- Confirm the record is visible and correct in the standard UI first, to rule out a genuine data problem.
- Reproduce the GET call outside Studio (Postman or curl) with the same custom object alias and ID to confirm the 404 isn't specific to the WorkdayOutREST component's path configuration.
- Open the record in the tenant UI and save it without changing any field values, then immediately retry the same GET call to confirm whether re-saving is what resolves it.
- If confirmed, check whether the record was created via a bulk load (EIB, web service) rather than through the UI. Bulk-created custom object records are a common trigger for this, since they can bypass whatever indexing step a UI save performs.
Open and re-save the affected custom object record once in the tenant UI to make it retrievable via REST, then retry the integration.
If records are created via EIB or web service load rather than the UI, add a no-op update step to the load process (or confirm with Workday support whether an explicit reindex step is needed) so newly created records are REST-retrievable immediately, instead of discovering the gap only when the first GET call fails.