Start with Workday, not a guessed query

Workday Query Language is SQL-like, but its names come from Workday data sources, filters, fields and aliases. The same-looking tenant can expose a different set to another person because WQL follows that person's Workday security. Before writing FROM or SELECT, inspect the connected tenant's data-source metadata.

Find the data source first, then its fields and any prompts required by its filter. An alias copied from another tenant, an old example or a display label is only a lead; Workday's metadata is the answer for the tenant you are querying.

Build the smallest query that can answer the question

Name only the fields you need, add one verified filter, and start with a modest limit. This makes a wrong field, missing permission or unexpected population visible before the query becomes difficult to diagnose. 

SELECT worker, employeeID, hireDate
FROM allWorkers
WHERE hireDate >= '2026-01-01'
ORDER BY employeeID
LIMIT 100

WQL has its own operators and clause order. It does not support SELECT * or LIKE. Text and dates are quoted; instance comparisons use the identifier form Workday reports for that field. If the question is a count or total, ask WQL to aggregate instead of loading every row and counting in a page script.

Choose the route that matches the job

  • View WQL Query Result is useful while developing a query in the tenant. It displays at most 500 rows.
  • The WQL REST API returns cached results in pages. Its page size can be up to 10,000 rows, while the query as a whole has a separate result limit.
  • An Extend page or orchestration runs WQL inside the app's authenticated Workday context. The page still needs loading, paging, empty and error behavior.

A route that works does not make every other route available. External REST access can need an API client, while an Extend app does not need one for WQL inside the app. Report which route produced the result and which limit applied.

AI can draft the query; Workday still decides

Workday itself provides a Generate WQL API and sample app that map natural-language questions to supported data sources. That generated statement still needs the calling person's Workday security and a real execution against the tenant. A plausible query is not proof that its source, fields, filters or results are right.

kiweely follows the same boundary: it can inspect available metadata, write the query, run it through an available connection and explain the result. Workday supplies the schema and the answer; the model does not invent either one.

Verify the result, not only the syntax

A valid query can still answer the wrong business question. Check the returned population, inspect a few known records, reconcile counts with a trusted Workday report when one exists, and state whether paging reached the complete result. Empty rows can mean a real empty population, missing access or a filter that excludes everything; distinguish those cases before reporting zero.

For exact messages, continue with WQL error messages and how to fix them. For larger results, see getting more than 500 rows from WQL.

Sources checked