Why a Workday Graph API query suddenly fails with "Cannot query field"

What "Cannot query field" means in the Workday Graph API

"Cannot query field" is GraphQL's validation error for a field the schema does not have on that type. The request is rejected before Workday runs anything, so it is not a data or permission problem: the schema your request reached has no field with that exact name in that position. When a query that used to work starts failing this way, either the request is now reaching a different schema, or the schema changed under it.

Workday's Graph API reference lists this kind of failure among the request errors that happen before execution begins (invalid syntax, missing arguments, invalid input types and variables). Read errors[] in the response body rather than trusting the status code: Workday returns 200 for many failed queries and 400 for an unsuccessful one, and each error's locations gives the line and column of the field. In an Extend page, any response with errors[] is treated as an error even on a 200.

Cause 1: the request is calling a different schema version

The endpoint is versioned: https://{apiGatewayBasePath}/graphql/{version}, and the schema belongs to the version. The Graph API Explorer shows the latest version by default and lets you pick earlier ones from a dropdown; offline, before you connect it to a tenant, it shows only the v1 schema. So a query written and tested in the Explorer against one version can fail when the app or orchestration posts it to another, and the reverse.

To check, find the version in the failing request's URL, select the same version in the Explorer while connected to the same tenant, and run the query there. If it fails in the Explorer too, the field does not exist in that version. Either move the request to the version where the field exists, after testing the rest of the query against it, or rewrite the query for the version you are on.

Cause 2: the Extend app's reference ID changed

Extend business objects, attachment objects and event business objects appear in the Graph API schema under names that start with the app's reference ID, such as charitableDonations_ycjtxv_Charity for the query and charitableDonations_ycjtxv_charities for its data source. Workday adds the reference ID so names are unique across the schema.

That makes the names account-specific. Workday's documentation says that if you import an app from one account to another, you must update the query and mutation names in the app to use the target account's reference ID. A query copied with the old prefix asks for a root field that does not exist in the new account's schema, and fails with "Cannot query field" on that root field.

Two edge cases Workday calls out also change the name: if the app's reference ID or a field name begins with a number, the schema inserts an App_ prefix, so 9inventory_abc123_Item is not the name you query. Workday's advice is to start both the reference ID and every field name with a letter.

The fix is a search-and-replace of the old reference ID across the app's Graph Query components, PMD graphQuery attributes and orchestration request bodies, then a redeploy. In the Explorer, check the new names in the Documentation Explorer first; Workday notes you have to refresh the browser after a deploy to see the updated schema.

Cause 3: a field you query was removed or renamed

Workday publishes a Graph API Changelog in the Reference section of the Developer Site, filterable by Breaking and Non-Breaking changes and by Field, Type and Input. Workday describes breaking changes as the ones that need you to update queries or mutations, says all schema updates are non-breaking except changes marked for deprecation, and says it checks a field is unused before removing it from the schema.

If causes 1 and 2 do not apply, filter the changelog to Breaking and search for the field and type in the error.

For your own Extend business objects, the schema changes when you deploy: Workday adds or updates the query and mutation operations to match the model components. Rename a field in the business object and deploy, and any page or orchestration still asking for the old name fails this way.

Cause 4: the field is on a different type than you think

The error names a type: the field is missing on that type, not everywhere. Two common versions of this in Workday:

• Fields asked for at the wrong level. Workday queries return a wrapper with data, and the object fields go inside it. Putting businessTitle directly under worker instead of under worker { data { ... } } asks the wrapper type for a field it does not have.
• A related object queried as if it were a scalar. A field like uploadedBy on an attachment is an object; select its subfields, such as uploadedBy { workdayID { id } }.

The Explorer's type-ahead (Ctrl+Space on Windows, Option+Space on macOS) lists the fields valid at the cursor, which settles this quickly.

What "Cannot query field" is not

It is not a security failure. When the calling account lacks access, Workday returns the query with warnings in extensions.warnings: S39 for an inaccessible data source, S40 for an inaccessible data source filter, and S41 for an inaccessible field. The field exists in the schema; you just cannot read it. Graph API access itself needs the Workday Graph API Applications domain, plus View on the domains that secure each data source you query, as listed under "Secured by" in the schema documentation. If you see S41, fix security; do not rewrite the query.

It is also not a formatting problem with the request body, although that is a separate trap: Workday's reference notes that outside the Explorer and PMD graphQuery attributes, for example in Orchestration Builder and Postman, the query must be a single line with no newline characters.

Prove the fix

Run the corrected query in the Graph API Explorer connected to the tenant, on the exact version the app or orchestration calls, as a user with the same security. Then run the real caller: load the Extend page and confirm the response has no errors[], or check the orchestration step's response. Confirm the data itself too. A query that now validates but returns S41 warnings or empty data has moved from a schema problem to a security or data problem, which the guide to fields a user cannot see covers.

If you are choosing between Graph API and REST for this read, Workday Extend Graph API vs REST API compares them.