Why a Workday report returns no rows, or the wrong rows

Confirm which layer is empty before you touch the report

A report with no rows, or fewer rows than you expect, is almost never one problem. It is one of several independent layers, and any one of them can remove every row on its own. Before editing the report, build a fresh Advanced report on the same data source with no report filter, no subfilter and no prompt values entered, and run it.

If that bare report returns rows, the data source and your security are fine, and the report's own filter, subfilter or prompt is doing the excluding. If it returns nothing, the problem is upstream: the data source's built-in filter, or your own security against that data source. That one test tells you which half of this guide to read first.

The data source already decided which rows can exist

Workday delivers zero, one, or several data sources for a given business object, and each one is itself a filter, not a neutral list of everything. All Workers returns active, terminated and future workers. All Active and Terminated Workers drops future workers. All Active Employees drops contingent workers, terminated workers and future workers entirely, no matter what you configure afterward on the Filter tab.

If a report is missing terminated or contingent workers, or unexpectedly shows someone who left months ago, check the data source's name and its stated primary business object before you touch a single filter condition. A report built on the wrong data source can never surface those rows, regardless of how the rest of the report is set up. The Business Object Details report is the fastest way to see which data sources exist for a business object and what each one's built-in filter actually is.

Data source filter, report filter and subfilter each remove rows independently

An indexed data source can carry one or more data source filters, chosen when you create the report. A report filter — the Filter on Instances grid on the Filter tab — is layered on top of that at runtime. For advanced reports, a subfilter on a related business object's field removes primary-object rows based on data that never appears anywhere in the report's output. All three can eliminate the same row for entirely different reasons, and none of them is visible from either of the other two tabs.

When a row is missing, open the Edit Custom Report task and read the data source, the Filter tab and the Subfilter tab in that order. Don't assume the visible column list is the only filter in play — a subfilter in particular filters on a field the report never displays.

Parentheses in the Filter on Instances grid group AND and OR conditions. A missing or misplaced parenthesis can quietly turn an intended “A or B” into “A and B,” dropping every row that only matches B.

A blank prompt is not the same as no filter

When a filter condition's Comparison Type is set to prompt the user, leaving that prompt blank at run time does not mean “ignore this condition.” Workday still evaluates the condition, now against a blank value, and any row that doesn't match a blank comparison is excluded. The same applies to the Effective Date and Entry Date prompts on the Prompts tab: if nobody supplies one, Workday uses the moment the report actually runs, not a moment you assumed, and a report looking for as-of data on a past or future date can correctly return nothing for a run made with today's default.

If the report is shared with other people, check what each person actually enters at the prompt, or what default value you configured for them. Two people running the identical report definition with different prompt values will legitimately see different rows — that is the report working as designed, not a bug.

A related business object can multiply rows, or make them vanish

The primary business object behind the data source determines what a “row” is. A report on the All Active Employees data source returns one row per Employee, with related instances like dependents collapsed into sub-rows underneath. A report on All Dependents returns one row per Dependent, so the same employee can appear more than once. If you expected one row per worker and see several, or the reverse, check whether the data source's primary business object is really the one you intended.

A subfilter, or a report filter that reads a field on a related business object, depends on that related instance existing at all. A worker with no dependent, for example, has no related instance for the condition to read, so a condition such as “equal to” a value cannot match and the row is filtered out rather than shown with a blank. That looks identical to a row lost to security or to the data source itself, so confirm which one you're actually looking at on a single known instance before you change the filter.

The running user's security decides their rows, not just which reports they can open

A domain security policy secures the data source itself, and separately secures every report field that appears in the report. A person can have access to run a shared report while still lacking access to the data source or to one of the fields it filters or sorts on, and they will see fewer rows, or none, with no error at all. Sharing a custom report only extends to users who already have security access to both the report's data source and its data source filter; Workday won't let you share it with anyone else, and it won't quietly grant them access either.

Also check whether the relevant security group is constrained or unconstrained. An unconstrained group sees every instance the data source and fields allow. A constrained group — most role-based and job-based groups — only sees instances within that person's own organization or supervisory scope. Two people can run the exact same report definition with the exact same prompt values and correctly see two different sets of rows, because one of them belongs to a constrained security group and the other doesn't.

Indexed data sources come with hard return limits

Workday caps how many instances a report can return before and after filtering, and the cap depends on whether the data source is indexed. A nonindexed data source is limited at prefiltering and again at postfiltering or grouping. An indexed data source carries its own limit at each stage, and Workday recommends restricting an indexed report to indexed fields — the Optimized for Performance option enforces exactly that — to get the intended benefit.

On a very large tenant, a report that looks like it's returning incomplete or wrong rows, rather than an outright error, can be silently running into one of these limits. Workday's own guidance is to add a more specific data source filter, or move to an indexed data source, rather than assume the report definition itself is wrong.

A calculated field used as a filter condition can quietly return blank

If the report filters, sorts, or prompts using a calculated field, and that field resolves to blank for a given instance — a broken related-object lookup, a security gap on one of the fields the calculation reads, or an Evaluate Expression condition that never matches — the filter treats that instance the same as any other non-matching row. It disappears from the output with nothing to indicate that the calculation, rather than the underlying data, produced the gap.

If you've ruled out the data source, the filters, the prompts and security above, and a calculated field is involved in the filter, see why a Workday calculated field returns blank next. That field's own logic is the last place left to check.

Diagnostic order

Work through these in order; each one rules out a layer before you touch the next.

Prove it on one instance, then scale up

Pick one instance you already know should appear, and walk it through the layers above in order: data source, then filter and subfilter, then prompts, then the related object, then your own security compared with the affected user's. Once that single instance is explained, the same fix almost always accounts for the rest of the missing rows.

kiweely can read a client's tenant directly, with the person's consent, so it can check what a data source, a filter or a security group actually returns instead of guessing from the report definition alone.

If a field or filter behaves differently in one tenant than another, see copying Workday configuration between tenants. If the missing or wrong rows show up in a WQL query or a RaaS feed rather than a native report, see RaaS, WQL and the REST API.

Sources checked

• Report security
• Building custom reports
• Set Up Filter Options for Custom Reports
• Set Up Prompt Options for Custom Reports
• Reference: Reporting Limits