Slow Workday Custom Reports: Fixing Data Source Filter and Calculated Field Timeouts

When a Workday custom report or Reports-as-a-Service (RaaS) endpoint runs slowly or times out, the bottleneck almost always traces to one of four root causes: an overly broad or nonindexed Report Data Source (RDS) without a built-in Data Source Filter, post-retrieval Report Filters that evaluate unindexed or calculated fields across millions of instances, deep chains of Lookup Related Value / Extract Multi-Instance calculated fields, or full-dataset sorting and effective-date evaluations. You can pinpoint the exact millisecond breakdown by enabling logging in Edit Report Performance Log Settings, inspecting View Report Performance Logs, and validating structural integrity with Custom Report Exception Audit.

1. Know Workday's hard report processing and instance limits

Before changing a report definition, identify which Workday ceiling your report is hitting:

If a report is never meant to finish interactively in the browser, open Edit Custom Report, navigate to the Advanced tab, and check Background Only in the Report Performance section (available on all custom report types except Simple reports). You can audit all background-only definitions across your tenant using the All Background Only Custom Reports report.

2. Diagnose the bottleneck with View Report Performance Logs

Do not guess which column or filter is slowing down a report. Turn on performance logging:

1. Run the Edit Report Performance Log Settings task and select the slow custom report to log.
2. Run the custom report (note that if you click Notify me later during the run, Workday marks the initial interactive log entry as Failed and writes a second log entry for the background execution).
3. Open the View Report Performance Logs report and click View on the execution record.

Focus on these specific diagnostic fields in the log:

3. Replace broad data sources and Report Filters with Built-In Data Source Filters

Workday states that the Data Source you select is the single largest factor in report performance. When report writers default to All Active and Terminated Workers or Workers for HCM Reporting and then narrow the population on the Filter tab, Workday must first load the entire worker population (up to the 3-million prefilter limit) before discarding 99% of the rows.

Apply this three-step hierarchy when selecting a data source (use the Data Sources report or Business Object Details report to compare options):

1. Choose an Indexed Data Source first: Indexed RDSs (such as Indexed Workers or Trended Workers) are pre-indexed for aggregation, faceting, and large-volume retrieval. Check Optimized for Performance on the Advanced tab so Workday restricts field prompts to indexed fields only.
2. Use a Built-In Data Source Filter instead of a Report Filter: Whenever an RDS provides a predefined Data Source Filter (for example, selecting the Workers by Role filter on Workers for HCM Reporting, or using Workers by Organization), use it. Built-in data source filters restrict the instances retrieved at the data source level before report-level processing begins.
3. Choose a Focused or Transactional Data Source when appropriate:
   • If a report is for a manager viewing their team, use My Direct Reports instead of filtering All Active Workers by manager.
   • If a report lists one employee selected at runtime, use Worker from Prompt.
   • If a report lists workers who received a bonus in a date range, build the report on the transactional event RDS (such as Payroll Results) and filter by date range and bonus type, rather than scanning every active and terminated worker in the tenant.

4. Optimize filter order, subfilters, and calculated field chains

When you must filter on the Filter tab or compute values via calculated fields, small structural changes yield massive speedups:

• Verify the Indexed check box on the Filter and Matrix tabs: On Advanced, Matrix, and Trending reports, Workday displays an Indexed check box on each row of the Filter on Instances grid. Run View Indexed Fields for Data Source to see which fields are marked Indexed for Filter, Indexed for Facets, Indexed for Aggregation, and Indexed for Group By. Remember that on an indexed RDS with Optimized for Performance active, you cannot filter on a calculated field.
• Order filter conditions from most restrictive to least restrictive: Workday evaluates conditions in the Filter on Instances grid in top-to-bottom order. Put the condition that eliminates the largest number of records on row 1.
• Eliminate Subfilter nested loops: Adding a Subfilter on an Advanced report forces Workday to loop through related business object instances for every primary record. If the related business object is the true subject of the report, make that related business object the report's Primary Business Object so you can filter it directly at the top level.
• Use static Global fields and prune deep calculated field chains: Every Lookup Related Value (LRV) or Extract Single/Multi-Instance (ESI/EMI) field that traverses another calculated field multiplies execution count (Times Executed in Field Performance Metrics). When referencing constants or current dates in prompts and calculations, select static fields from the Global business object because they evaluate once and return the same value for every row.
• Run at the Current Moment when possible: Indexed RDSs only support the current moment. Even on standard data sources, specifying a past or future Effective Date forces Workday to reconstruct point-in-time object graphs rather than reading current values.

5. Run Custom Report Exception Audit and Calculated Field Exception Audit

Broken field references, retired data sources, and invalid security permissions after ownership transfers can cause reports and calculated fields to stall or fail unexpectedly. Workday delivers dedicated audit reports to catch these defects proactively:

• Custom Report Exception Audit: Validates custom report definitions across your tenant and lists the report owner, error severity, and specific problem description or solution (an empty output confirms zero definition errors).
• Custom Reports I Can Run Exception Audit: Filters exception results specifically to custom reports you have permission to run.
• Custom Report Exceptions by Owner: Identifies structural hygiene issues by owner, including reports with terminated owners, unshared reports, expired temporary reports, worklets not placed on any dashboard, and reports referencing items marked (Do Not Use). (You can also run All Custom Reports with "Do Not Use" Items or My Custom Reports with "Do Not Use" Items to replace retired RDSs and fields.)
• Calculated Field Exception Audit and Report Specific Calculated Field Exception Audit: Revalidates tenant-wide and report-specific calculated fields to surface broken references or evaluation errors before they impact production reports or RaaS integrations.

How kiweely fits

Refactoring a slow RaaS report into an indexed data source or replacing a 6-level calculated field chain with a clean WQL query or optimized report definition requires seeing how data sources, filters, and calculated fields connect in your tenant. Kiweely inspects your report definitions, traces calculated field dependencies, and helps you tune custom reports or migrate heavy RaaS extracts to high-performance WQL endpoints. Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.

Frequently asked questions

Why does View Report Performance Logs show my report status as Failed when I clicked Notify Me Later?

When an interactive report crosses the 15-to-20-second threshold and you select Notify me later, Workday terminates the synchronous browser thread—recording that initial log entry with an Execution Status of Failed—and immediately launches a new background process that generates its own separate log entry in View Report Performance Logs. Inspect the second log entry to see the completed background timing metrics.

Why did Workday deliver my scheduled Excel or PDF report as a CSV file instead?

Workday enforces row and Workday Markup Language (WML) size limits on scheduled report outputs. If an Excel or PDF output exceeds 1 GB of WML, or if a PDF report exceeds 10,000 rows, or an Excel report exceeds 500,000 rows, Workday automatically switches the output to Text (CSV) (which supports over 1 million rows up to a 15 GB file size) and logs a warning in Process Monitor.

Does sorting a custom report affect RaaS or browser execution time?

Yes. Enabling sort rules on the Sort tab forces Workday to load and evaluate the entire result set in memory before returning the first page. Removing unnecessary sort rules—or sorting only on simple text fields rather than single-instance or multi-instance relational fields—significantly reduces Top Level Sort Time (ms).