Workday Reports: Every Type Explained and How to Build Them from Scratch

Workday’s reporting layer is one of the most technically rich parts of the platform, and it is also one of the most consistently underused. Most live tenants rely on a handful of saved standard reports and a set of Advanced custom reports that were built during implementation, exported to spreadsheets, and turned into manually maintained dashboards outside the system. That pattern is expensive, fragile, and entirely avoidable.

The platform ships with eight distinct custom report types, a full-featured Report Writer capable of computed fields, multi-level groupings, runtime prompts, and web service exposure, a BIRT rendering layer for branded PDF output, a scheduling engine with multiple recurrence patterns, and a Report as a Service API that any authorized external system can call without custom middleware. Sitting above all of that is Workday Prism Analytics, which extends the reporting layer to handle external data blending and persistent analytical datasets.

This guide covers all of it at practitioner depth. It explains the object model that the Report Writer operates against, the structural differences between all eight report types and when each is the correct choice, the full step-by-step configuration process for building an Advanced report through to scheduled delivery, the security model that governs what every user sees when any report runs, and the architectural boundary where the Report Writer ends and Prism begins. It is written for administrators, report writers, and functional consultants who are already inside the system and want to use it at a higher level.

The Object Model the Report Writer Operates Against

Before touching the Report Writer, you need to understand what it is actually querying. Workday is built on a proprietary development platform called XpressO. Every entity in the system – a Worker, a Position, a Cost Center, a Journal Line, a Benefit Plan, a Purchase Order – is represented as a business object. Objects have typed fields, and objects relate to each other through defined relationships. A Worker relates to their Supervisory Organization, their Compensation Grade, their Job Profile, their Manager, their Pay Group, and dozens of other objects. Those relationships are traversable in the Report Writer, which means you can pull fields from any related object into a report without writing any join logic yourself.

This is the critical distinction between Workday reporting and SQL-based reporting. You are not writing queries against database tables. You are navigating a declared object graph that Workday has already modeled. The Report Writer exposes that graph through a field-selection interface where you search for fields by name, select them, and the platform resolves the traversal internally. The benefit is that report builders without database expertise can access deeply relational data. The constraint is that you are limited to the relationships Workday has defined, and no custom join logic outside those relationships is possible at the Report Writer layer.

The entry point to this object graph in any given report is the data source. A data source is functionally equivalent to a view in a relational database. It defines the primary business object the report is centered on, the set of instances of that object that are accessible (all active workers, all terminated workers, all journal lines for a specific ledger, all open positions in a supervisory organization), and the security context that scopes what any given user can see when the report executes. Every custom report has exactly one data source. That constraint cannot be worked around in the Report Writer – it is a deliberate architectural boundary. Multi-source outputs require the Composite report type, which assembles multiple separate sub-reports rather than querying multiple data sources from within a single report definition.

Data sources come in two structural variants: indexed and non-indexed. Indexed data sources are pre-optimized for query performance. Workday pre-builds index structures for them, which means report queries execute against those indexes rather than scanning full object populations. For large-tenant reports – anything running against populations of tens of thousands of workers or financial transactions – choosing an indexed data source is not optional if you want the report to be usable in production. Non-indexed sources remain available and are sometimes the only option for specific object types, but they carry significant performance costs at scale. The Edit Data Source task on any data source shows its indexing status. Understanding what drives report performance – and how data source selection is the largest single variable – is a prerequisite for designing reports that will still function correctly two years into production operations. The Workday data source permissions guide covers this architecture alongside the domain security layer that governs data source access, which are inseparable concerns in practice.

Standard Reports vs. Custom Reports: What the Distinction Actually Means

Workday delivers hundreds of standard reports across every functional area. These are Workday-maintained report definitions that cover common operational needs – headcount summaries, benefit enrollment reports, payroll register outputs, financial period-close extracts. Standard reports cannot be edited directly. They are updated by Workday across releases, which means any customization you need must live in a copy rather than in the original.

Copying a standard report creates a custom report instance that is owned by your tenant and fully editable. The copy inherits the original data source, column configuration, and filter logic, giving you a fully functional starting point that you can extend. This copy-and-modify pattern is the most efficient path when a standard report satisfies 70-80 percent of a requirement. You avoid rebuilding field configurations from first principles and work from a proven data source selection.

Custom reports can be created in four ways: by copying an existing custom report, by copying a Workday standard report, by creating a new report from scratch using the Create Custom Report task, or by initiating a report from context within the application, which pre-populates the data source based on the object type visible at your current location in the system. The in-context creation path is underused and genuinely useful during implementation when you need to quickly prototype a report structure against a specific object type you are actively working with.

The Eight Custom Report Types

The report type selection made at creation is not easily reversible for most types. Getting it right at the start avoids rebuilds. Here is what each type can and cannot do, and when it is the correct choice.

Simple Reports

Simple reports are scoped to a single primary business object and exclude three capabilities that practitioners rely on in production: calculated fields, related business object traversal, and web service exposure. You can select fields from the primary object, define sort order, and apply basic filters. The result is a flat list of primary object instances visible to the running user.

Simple reports cannot be shared with other users in the standard sharing model. They cannot function as sub-reports within Composite configurations. They cannot be used as data extraction endpoints for outbound EIBs or Prism Analytics pipelines. And once a report is created as Simple, it cannot be upgraded to Advanced later. For all of these reasons, most production environments skip Simple entirely and use Advanced as the default type even for straightforward list requirements. The marginal setup cost difference is negligible, and the structural constraints of Simple become a maintenance problem the moment any downstream use case materializes.

Advanced Reports

Advanced is the dominant report type in every mature Workday tenant. Estimates from Workday documentation and community resources consistently place Advanced reports at approximately 90 percent of custom report volume in typical tenants. The remaining 10 percent is where the other types apply.

An Advanced report supports data from both the primary business object and any related business objects accessible through the selected data source. It supports calculated fields at both the tenant-wide and report-specific scope. It supports multiple levels of row groupings with subtotaling, sub-filters evaluated against related objects, run-time prompts that accept user-supplied parameter values at execution, chart attachments, worklet deployment onto dashboards and landing pages, report sharing with security groups or individual users, and web service exposure via Report as a Service.

The RaaS capability is what makes Advanced reports the data layer for integration architectures. When you expose an Advanced report as a web service, Workday generates endpoint URLs in multiple output formats: Workday XML, Simple XML, CSV, JSON, RSS, and GData. These URLs are accessible via Actions – Web Services – View URLs from the report’s related actions menu. External consumers – Workday Prism Analytics pipelines, outbound EIBs, third-party BI tools, Adaptive Planning integrations, and custom applications – authenticate against these endpoints using an Integration System User account and pull data on demand or on a scheduled basis. For a detailed breakdown of how the Workday API layer that RaaS operates within is structured, including OAuth 2.0 authentication flows and endpoint construction, the Workday public API architecture guide covers the complete integration stack.

One requirement that trips up many implementations: Prism Analytics datasets can only ingest data from Advanced reports. This is a hard platform constraint. Simple, Matrix, Trending, Composite, and all other report types cannot feed a Prism dataset directly. If you are designing a reporting architecture where custom Report Writer reports will feed into Prism for external data blending, persistent datasets, or complex transformations, all upstream extraction reports must be Advanced type with web service exposure enabled.

Advanced reports also serve as the data source layer for BIRT layouts, which are Workday’s mechanism for attaching branded PDF output to reports. BIRT (Business Intelligence and Reporting Tools) is an Eclipse-based layout engine integrated with Workday Studio. It uses an Advanced custom report as its data feed and applies a designed template to produce formatted PDF outputs – pay slips, offer letters, contract documents, formatted compliance reports. The Workday BIRT payroll reporting guide covers the full technical implementation of BIRT layouts against Advanced report data sources, including XML/XSD validation requirements and multi-language localization configuration.

Matrix Reports

A Matrix report is Workday’s pivot table. It aggregates data at the intersection of row and column groupings rather than outputting a flat instance list. The output is a grid where each cell displays a calculated measure – most commonly a count or sum – scoped to the specific row group and column group intersection that cell belongs to.

The Matrix report configuration interface differs substantially from the Advanced report interface. Instead of a Columns tab for adding output fields, you configure a dedicated Matrix tab. You define a Row Group field (the dimension displayed down the left side of the grid), optionally a Column Group field (the dimension across the top), and one or more Measures (the aggregated values in the cells). Common practical configurations include headcount by Supervisory Organization and Period, spend by Cost Center and Account Category, open requisitions by Hiring Manager and Requisition Status, or terminations by Termination Reason and Quarter.

The data source selection for a Matrix report follows the same rules as for Advanced reports. For workforce matrix analytics, common sources include All Active and Terminated Workers, Workers by Organization, and snapshot-based sources such as Workers – Snapshot. Snapshot sources are pre-aggregated point-in-time datasets that perform dramatically better for time-series matrix queries than live object sources, which scan the full population at execution. For any matrix report covering multiple periods of historical workforce data, snapshot data sources are the architecturally correct choice.

Matrix reports support drill-down natively. When a user clicks a cell value in the rendered grid, Workday can display the underlying instance records that make up that aggregate. The fields shown in the drill-down view are configured separately in the report definition’s detail data section. This gives you precise control over the drill-down output without exposing it in the summary grid. A headcount matrix can show department-by-location counts in the summary and display full worker name, hire date, job title, and compensation grade in the drill-down – all from the same report definition.

The View By feature in Matrix reports allows users to switch the column grouping dimension at runtime by selecting from a set of pre-defined dimension fields. This means a single Matrix report can serve multiple analytical cuts – for example, letting the user switch the column grouping between Quarter, Location, and Job Level – without requiring separate report builds for each permutation. View By is an underused feature that eliminates significant report proliferation in large tenants.

Building a headcount report as an Advanced list, exporting it to Excel, and creating a pivot table manually is a pattern that represents everything the Matrix report type was designed to eliminate. If your use case involves aggregated dimensional analysis, the correct tool is Matrix. If your report writers are regularly exporting Advanced reports to pivot in Excel, that is a signal that Matrix reports are not being used where they should be.

Composite Reports

Composite reports assemble multiple sub-reports – each of which must be a Matrix or Trending report type – into a single unified output. The sub-reports bring their own data sources, their own dimensions, and their own measures. The Composite layer then aligns them by shared dimension values and supports composite-level calculated fields that perform arithmetic across values from different sub-reports.

The canonical composite use case is an executive workforce scorecard that combines headcount, active requisitions, period hires, period terminations, and payroll cost into a single output – segmented by the same organizational dimensions, covering the same time periods. Each of those five data points comes from a separate data source. None of them can be joined inside a single Advanced or Matrix report. The Composite layer is the only place in the Report Writer where cross-source metric assembly is possible.

Sub-report alignment within a Composite report is controlled through two mechanisms: joins and unions. A join merges columns from two sub-reports at matching dimension intersections. If sub-report A is a headcount matrix by department and month, and sub-report B is a payroll cost matrix by the same dimensions, a join on department and month produces a composite output where each row shows both headcount and payroll cost side by side. A union appends rows from different sub-reports sequentially into a single output stream – used when you need to show different categories of records in sequence rather than side by side.

Composite-level calculated fields operate on measure values from different sub-reports. Turnover rate (terminations divided by average headcount), cost per hire (recruiting spend divided by new hires), and revenue per employee (financial revenue divided by headcount) are all metrics that can only exist at the Composite level because their numerators and denominators come from different underlying data sources. Defining these cross-source metrics entirely within Workday eliminates the need for the manual spreadsheet calculations that are otherwise required.

Composite reports are resource-intensive. They execute multiple sub-report queries, align results across shared dimensions, and evaluate composite-level calculations on top of the assembled output. Workday’s default maximum report runtime is one hour. A Composite report with poorly scoped sub-reports, large unfiltered datasets, or deeply nested calculated fields will approach or exceed that limit in production. Sub-report filters, indexed data source selection, and the Optimize for Performance flag on individual sub-report configurations are all levers that must be applied deliberately in Composite report design.

The Workday composite reporting guide covers the full technical construction process for Composite reports, including join key configuration, union logic, composite calculated field expressions, drill-down linkage from composite cells to detail sub-reports, and the specific optimization patterns required to make large composites run within acceptable time bounds.

Trending Reports

Trending reports are structurally similar to Matrix reports but require a mandatory time dimension. Every Trending report configuration includes a time range definition – typically a start period and end period supplied at runtime via prompts – and the output organizes measure data across those periods automatically. This makes Trending reports the correct type for any workforce or financial analysis that needs to show change over time: headcount by month over a rolling 12-month window, attrition rate by quarter over three years, open requisition aging week over week.

The underlying data source choice is particularly important for Trending reports. Workday provides snapshot-based data sources specifically for time-series analysis – Workers – Snapshot, Positions – Snapshot, and equivalents for financial objects in some functional areas. These sources contain pre-aggregated point-in-time data that is optimized for the kind of period-over-period queries that Trending reports execute. Running a Trending report against live object data sources for long historical windows causes substantial performance degradation because Workday must reconstruct the historical state of each object instance across every period in the range.

Trending reports are most commonly deployed as sub-reports within Composite configurations rather than as standalone outputs. A Trending sub-report feeding the time-series dimension of a headcount composite, aligned with a Matrix sub-report providing the cross-sectional dimension, produces the kind of multi-dimensional period-over-period scorecard that executives and HR analytics teams actually want to see.

nBox Reports

nBox reports display data in a two-dimensional matrix designed specifically for talent analytics. The configuration requires defining two evaluation dimensions (most commonly Performance Rating and Potential Rating), the number of segments on each axis (a 3×3 configuration produces the nine-box grid that talent management practitioners are familiar with), and the score thresholds that determine which cell segment a worker falls into based on their values on the two dimensions.

The output renders as an interactive grid where each cell shows the worker count in that performance-potential combination, with drill-down capability to the individual workers. In a 3×3 nBox with Performance on one axis and Potential on the other, clicking the top-right cell (High Performance, High Potential) displays the specific workers in that combination with whatever detail fields you have configured in the drill-down.

nBox reports are used in succession planning calibration sessions, annual talent review cycles, and workforce development planning within Workday’s Talent Management module. They are not general-purpose analytical tools – they exist for this specific use case and are configured as components of talent review business processes rather than as standalone reporting objects.

Transposed Reports

A Transposed report inverts the standard orientation of a Workday report output. In a standard report, instances appear as rows and fields appear as columns. In a Transposed report, field names appear as rows down the left side and instances appear as columns across the top. The practical effect is a side-by-side comparison layout where you can read all attributes of one instance in a single column, and compare it directly against a small number of other instances in adjacent columns.

Transposed reports are appropriate for a narrow set of comparison use cases – comparing three or four job profiles across twenty or thirty attribute fields, or comparing open positions in a department across their compensation, required qualifications, and reporting structure. When the number of comparison attributes substantially exceeds the number of comparison instances, the Transposed layout is easier to read than the standard orientation.

This type is rarely needed in standard HCM or Finance reporting and becomes relevant primarily in position management review scenarios, job architecture design work, and compensation benchmarking contexts.

Search Reports

Search reports define the output structure of a Workday faceted search – the result set that appears when users run a search in the application interface and use filter facets to narrow results. They are also used as the data extraction layer for outbound EIBs that need to consume search-result-style outputs filtered by runtime-supplied facet criteria.

In integration architecture, Search reports matter specifically for outbound EIB configurations where the extraction logic needs to apply dynamic runtime filters rather than pulling full table scans. A benefits carrier outbound integration that should only extract workers with specific benefit plan elections can use a Search report as its data source, passing the benefit plan selection as a runtime facet filter rather than requiring a full worker population extract followed by external filtering. The Workday EIB features and architecture guide covers how Search reports fit within outbound EIB data source patterns alongside Advanced report-based extractions. For more detailed EIB workflow optimization – including how calculated fields embedded in report data sources reduce transformation overhead in integration payloads – the advanced EIB workflow guide covers that architectural layer in depth.

Report Writer Core Concepts: What You Need to Understand Before Building

The Report Writer introduces vocabulary that is worth understanding precisely before building production reports.

Business Objects: Primary and Related

The primary business object is the entity type at the center of the report. In a report built on the All Active Workers data source, Worker is the primary business object. Every row in the report output corresponds to one instance of the primary business object that passes the filter criteria and falls within the security scope of the running user.

Related business objects are entity types connected to the primary object through Workday’s declared relationship graph. A Worker’s related objects include their Job Profile, their Supervisory Organization, their Manager (who is also a Worker, creating a self-referential relationship), their Pay Group, their Cost Center, their Compensation Grade, and many others. Advanced reports can traverse these relationships and pull fields from related objects. The traversal depth is not limited to single-hop relationships – you can navigate multi-hop chains, for example pulling fields from the Cost Center of the Supervisory Organization that supervises the worker’s direct Supervisory Organization.

Calculated Fields: Tenant-Wide vs. Report-Specific

Calculated fields fall into two scopes. Tenant-wide calculated fields are defined independently of any specific report and can be used across multiple reports, integrations, and business process conditions once defined. Report-specific calculated fields exist only within the report definition where they are created. They cannot be reused in other reports without being rebuilt.

The practical implication is that calculated fields implementing broadly useful business logic – tenure in months, pay period type classification, compensation band derivation – should be built as tenant-wide fields to prevent redundant definitions accumulating across dozens of report definitions. Report-specific fields are appropriate for logic that genuinely applies only to one specific report’s requirements.

Workday’s calculated field function library covers date arithmetic, text manipulation (concatenation, substring extraction, trimming), conditional logic (If/Then/Else with Boolean conditions), lookup functions against related objects and reference tables, currency conversion, numeric aggregation (count, sum, average, min, max), organizational hierarchy traversal (finding the nth level manager above a worker), and change detection (identifying when a field value differs from its prior-period value). The security model for calculated fields is worth understanding precisely: if a calculated field references a field that the running user does not have security access to, the calculated field returns a blank value for currency and numeric types and an empty string for all other types. The calculation does not error – it silently returns empty. This behavior is documented in Workday’s Report Writer Fundamentals materials and has significant implications for shared reports where different users have different field access.

Filters: Primary vs. Sub-Filter Evaluation

Filters in Workday reports evaluate differently depending on whether they are applied against the primary business object or against related business objects.

A filter applied to a field on the primary business object is evaluated first, before any related object traversal occurs. This reduces the record population early in query execution and is the most performant place to scope a report. A filter condition that says the Worker’s Hire Date is after a specific date eliminates ineligible Worker instances before Workday resolves any of the related object fields.

A sub-filter is applied against a related business object. It evaluates the condition against the related object instances associated with each primary object instance. The evaluation logic behaves like an existence check: the primary instance is included if at least one of its related instances satisfies the sub-filter condition. This means sub-filters do not restrict which related object values appear in the output for an included primary instance – they determine whether the primary instance appears at all. Understanding this distinction prevents a class of common report logic errors where practitioners expect a sub-filter to narrow the related object output for included rows, which it does not do.

Prompts

Prompts are runtime parameters that users supply when executing a report. Each prompt is associated with a field from the data source and inserts the user-supplied value into one or more filter conditions at execution. A date range prompt connected to Hire Date filter conditions, a Supervisory Organization prompt that scopes the output to a user-selected org subtree, and a Worker Type prompt that lets users choose between employees, contingent workers, or both – all of these make a single report definition serve a wide range of analytical queries without requiring separate report variants for each combination.

Prompts can be configured as required or optional. Optional prompts with defined default values execute with those defaults if the user provides no input, which is the correct configuration for scheduled reports that run automatically without user interaction. Multiple prompts can be defined on a single Advanced report, and individual prompts can accept multiple selected values or single values depending on configuration.

Populate Undefined Prompt Defaults is a setting in the Advanced report configuration that pre-fills prompt values for web service consumers that do not supply explicit prompt parameters in their API calls. This is essential for RaaS-based integrations where the consuming system does not always supply every prompt value in the request URL.

Step-by-Step: Building an Advanced Custom Report

The following is a complete walkthrough of the Advanced report creation process from initial task invocation through to scheduling and delivery.

Step 1 – Security Prerequisites

Before accessing the Create Custom Report task, verify that your user account meets two separate security requirements. You must be assigned to the Report-writer user-based security group and must have access to the Custom Report Creation security domain. These are separate requirements – having one without the other prevents report creation. You also need access to the security domain covering the data source you intend to use, and access to the security domains covering the fields you want to add. A report writer who lacks domain access to Compensation data cannot add compensation fields to a report even if they can create reports generally. The Workday data source permissions guide maps out this multi-layer permission requirement in detail, including the specific domain security policy configurations that govern report creation access across functional areas.

Step 2 – Create Custom Report Task

From the Workday search bar, type Create Custom Report and select the task. Enter a report name. If your organization does not have a naming convention for custom reports, establish one before scaling report output. A functional area prefix combined with the primary object and report purpose – for example HCM-Worker-NewHire-90Day or FIN-Ledger-CostCenter-PeriodDetail – enables report library management as the tenant matures. Select Advanced as the report type.

Step 3 – Data Source Selection

The data source field is the most consequential configuration decision in the entire build. Search for the appropriate source. For workforce reports, common starting points include All Active and Terminated Workers (appropriate for workforce snapshots), All Workers (broader scope including contingent), Active Workers by Organization (scoped to an org subtree with runtime prompt for the org selection), and Workers by Organization and Staffing Model (for organizations using position management). For Finance, common sources include All Journal Lines, Accounting Journals, Budget Targets by Ledger Account, and Transaction Detail variants.

If the report needs data scoped to a specific supervisory organization hierarchy and you want that scope to be controlled by a runtime prompt, choose a data source that natively supports organizational scoping. Do not rely entirely on post-selection filters against the organization field to scope records from a tenant-wide source – this works correctly but eliminates the performance benefit of organizational scope being embedded in the data source definition itself.

Enable the Optimize for Performance flag at this stage for large-population reports. This instructs Workday to use an alternative query execution path that is faster for high-volume datasets. It has side effects on certain calculated field types and disables some drill-down behaviors, so validate the report output after enabling it. Enabling this flag and discovering that key calculated fields are incompatible is easier to resolve early in the build than after the full column configuration is complete.

Step 4 – Column Configuration

On the Columns tab, add the output fields. Click the plus icon to open the field search, which returns fields from the primary business object and all accessible related objects. Workday identifies fields by their object path, shown as breadcrumbs indicating the traversal – for example, Worker > Job > Pay Group > Pay Group Name. Add the fields needed for the report output.

For each column, set the Column Heading Override value. This is not optional for reports that will be exposed as web services – Workday requires column heading overrides to be defined before web service exposure is allowed, and these values become the XML element names in the report’s schema that all consuming integrations reference. Set them to stable, meaningful names at build time. Changing a column heading override after integration consumers are built against the report breaks those consumers because the XML element names in the output change.

Configure individual column sort settings and column widths as needed. Reorder columns by dragging to match the expected output layout.

If calculated fields are needed in the output, click the calculated field option in the column configuration to either reference an existing tenant-wide calculated field or build a new report-specific one inline. Common calculated field requirements in Advanced reports include:

• Tenure computation (difference in months between Hire Date and today, using the Date Difference function against the system date field)
• Risk band classification (conditional field returning a label such as High, Medium, or Low based on a numeric score range, using nested If/Then logic)
• Compensation ratio (a worker’s salary divided by the midpoint of their grade range, using arithmetic functions against two related object fields)
• Organizational level derivation (traversing the management hierarchy to determine how many levels below the CEO a worker sits, using the Organizational Level function)

Step 5 – Filter Configuration

On the Filter tab, define the conditions that restrict the output to the required record scope. Structure filters to apply the most restrictive conditions on indexed primary object fields first. A filter on a primary object field like Active Status, Hire Date range, or Worker Type eliminates ineligible records before any related object traversal occurs. A filter on a related object field is evaluated after the primary population is assembled, carrying the full performance cost of building that population first.

Use AND/OR logic within filter groups intentionally. Workday evaluates conditions within a filter group using the logic operator assigned to the group, and nested groups are evaluated independently. Build complex filter logic by nesting filter groups with appropriate operators rather than combining incompatible conditions in a single flat filter.

For reports that serve multiple use cases through runtime prompts, replace static filter values with prompt references. A filter on Hire Date greater than or equal to a Hire Date Start prompt, combined with a filter on Hire Date less than or equal to a Hire Date End prompt, turns a hardcoded period filter into a flexible user-controlled date range. This eliminates the need for separate report definitions for different analytical windows.

Step 6 – Grouping and Subtotaling

On the Sort/Group tab, define row groupings that organize output into sections by field value. A report grouped by Supervisory Organization shows all workers in each org as a section, with the org name as a section header. Adding a subtotal to a numeric column produces a count or sum row at the bottom of each section. Multiple grouping levels can be nested – grouping first by Supervisory Organization and then by Job Family within each organization produces a two-level hierarchy with subtotals at both levels.

The grand total row, controlled separately from grouping, aggregates all subtotaled numeric fields across the entire report output and appears at the end. For compliance reports that must show both detail and totals without exporting to Excel, grouping with subtotals is the correct approach.

Step 7 – Prompts Tab

Add runtime prompts on the Prompts tab. For each prompt, define the field the user will supply a value for, whether the prompt is required or optional, whether multi-select is allowed, and the default value if the user provides no input. Connect prompts to filter conditions by referencing the prompt in the filter condition’s value field rather than entering a static value.

For scheduled reports and RaaS-based integrations, set default values for all prompts so that automated executions run correctly without requiring user input. An annual review period report with a hardcoded default of the current calendar year runs correctly when scheduled monthly – users running it interactively can override the default to query historical years.

Step 8 – Advanced Tab: Sharing and Web Service Configuration

The Advanced tab contains sharing settings and web service configuration. Configure sharing to specify which security groups, users, or organizational scopes can see and run the report. Set the report as shared with the appropriate audience. Remember that sharing does not override data security – a user who can see and run a shared report will only see the records and fields that their own security group memberships grant access to.

To enable RaaS web service exposure, toggle Enable as Web Service. Workday validates that column heading overrides are defined for all columns before allowing this. Once enabled, access the web service URLs from Actions – Web Services – View URLs on the report’s related actions menu. These URLs contain the tenant name, the report name, and optional prompt values as query string parameters. The format parameter in the URL selects the output format: for example, appending format=json returns JSON, format=csv returns comma-separated, and the default returns Workday XML.

Web service consumption requires an Integration System User account with a corresponding Integration System Security Group (ISSG) that has appropriate domain access to the data source and fields the report uses. Assigning report access to a named employee account for integration purposes is a security configuration anti-pattern – ISU accounts are isolated from employee lifecycle events and do not become locked or inactive when employee roles change. The Workday public API technical guide covers ISU setup, ISSG domain assignment, and OAuth 2.0 token handling for RaaS consumers in detail.

Step 9 – Testing

Use the Test option to execute the report against a random 10-record sample before committing to a full execution. This validates that field selections, filter logic, and grouping configurations work as expected without waiting for full execution against the complete data population. Review the test output carefully. Pay specific attention to rows where fields you expected to contain values are blank – this is usually a calculated field security issue (the running user lacks access to a referenced field) or a related object traversal that returns multiple instances for some primary records, causing fan-out.

Click Run to execute against the full data source once the test output looks correct. Monitor runtime. A report that takes more than 30 seconds on a first run in a development tenant is a candidate for performance optimization before it reaches production scale.

Step 10 – Scheduling and Automated Delivery

Schedule the report from its related actions menu using the Schedule option. Workday’s scheduling engine offers the following run frequency configurations:

• Run Now: immediate single execution
• Run Once in Future: single execution at a specified date and time
• Daily recurrence: executes every day at the specified time
• Weekly recurrence: executes on specified days of the week at the specified time
• Monthly recurrence: executes on a specified day of the month at the specified time

For each scheduled run, define the output format (Excel, PDF, CSV, or others depending on report type), the delivery method (download to the My Reports worklet, delivery to a specified email address or list, or Workday Inbox task delivery), and the prompt default values that the scheduled execution uses.

Scheduled reports running as automated deliveries to finance or HR stakeholders outside the Workday interface benefit from the scheduling engine’s ability to pre-supply all prompt values, deliver in Excel format directly to email, and run on calendar cadences matching the operational reporting cycle. Period-close financial packs, weekly headcount summaries, monthly compliance extracts, and quarterly talent review inputs are all scheduling use cases this configuration supports. The broader automation layer that scheduled report delivery fits within – including how Workday Business Process Framework can trigger report-dependent actions automatically – is covered in the Workday business process automation guide.

Calculated Fields in Depth

Calculated fields are the most technically flexible component of the Report Writer and the most commonly misused one. The following function categories are available:

Date functions handle date arithmetic and formatting. Date Difference computes the interval between two dates in days, months, or years. Build Date constructs a new date from component parts. Add to Date adds or subtracts a specified interval from a date. Date Comparison functions return Boolean results used in conditional logic.

Text functions handle string manipulation. Concatenate joins text values from multiple fields into a single output. Substring extracts a defined portion of a text value. Upper, Lower, and Trim normalize text case and remove leading/trailing whitespace. Text Replace substitutes pattern matches within a text value.

Conditional functions implement logic. If/Then/Else evaluates a Boolean condition and returns one value when true and another when false. Nested If chains handle multi-condition decision trees. The And and Or operators combine Boolean conditions.

Lookup functions retrieve data from related objects and reference tables. Extract Single Instance retrieves a single related object instance based on a filter condition – for example, finding the worker’s current active compensation component of type Base Pay from among all their compensation components. Extract Multi Instance retrieves all matching related instances. Count and Sum aggregate numeric values across related instance sets.

Organizational hierarchy functions traverse management reporting chains. Org Level Up functions navigate to a specified number of levels above the worker in the supervisory organization hierarchy, enabling things like identifying the VP-level manager for any worker regardless of depth.

Change Detection functions compare a field’s current value against its value as of a prior date and return a Boolean indicating whether change occurred. These functions are particularly valuable for compliance reporting where you need to identify workers whose compensation, job profile, or classification changed within a specific period.

The scoping distinction between tenant-wide and report-specific calculated fields has maintenance implications at scale. A detailed examination of how calculated fields power dynamic workforce reporting shows this in practice – computed overtime fields, vacation balance derivations, and time-tracking aggregations all rely on the same calculated field function set, and the choice between tenant-wide and report-specific scope determines whether those calculations are maintainable at one point or scattered across dozens of report definitions.

Report Security: Three Layers That All Apply Simultaneously

The security model governing what any user sees when running a Workday report operates at three independent layers simultaneously. Diagnosing a report that returns no data or incomplete data for specific users requires checking all three layers, because a problem at any one of them produces the same surface symptom.

Layer 1: Domain Security Policy Access to the Data Source

Domain security policies group securable items – reports, tasks, integration access points, and related objects – within functional areas. Compensation data is secured by the Compensation functional area’s domains. Worker personal information is secured by its own domains. Payroll result data lives behind payroll-specific domain policies.

For a user to see data from a given data source, their security group memberships must include a domain security policy that grants at minimum Get access to the domain covering that data source. Without this, the user cannot access the data source at all – they see no records even if the report is shared with them directly and they can find it in the system. The functional area search via the Domain Security Policies for Functional Area report is the diagnostic tool for identifying which domain a specific data source belongs to and which security groups currently have access to it. The Workday data source permissions guide provides a complete walkthrough of this diagnostic process.

Layer 2: Report Sharing Visibility

Report sharing controls which users and groups can see the report definition and execute it. Sharing is a necessary condition for external users to run a report – without being on the share list or in a shared group, users cannot find or execute the report. But sharing is not a sufficient condition for seeing data – it does not override domain security access at layer one.

A user who is on the share list but lacks domain access to the data source will find the report in their environment and be able to initiate it, but the results will be empty or limited to only the fields and records covered by their existing domain access. This combination – visible report, empty or reduced results – is a common source of support tickets that are actually security configuration issues.

Layer 3: Row-Level Security Through Constrained Security Groups

Row-level security in Workday is implemented through constrained security groups, most commonly role-based security groups where the role is constrained to a specific supervisory organization scope. A manager whose security group membership is constrained to their supervisory organization and its subordinate organizations can run a report on the All Active Workers data source but will only see the workers within their organizational scope in the results. The report definition, the data source, and the sharing configuration are identical for all users of that report – the security group context of the runner determines the output scope.

This means the same shared report produces different outputs for different users based on their organizational security scope. It is the correct behavior and the mechanism by which self-service reporting scales across the organization without requiring separate report variants for different organizational scopes. It is also the explanation for why a manager complains that a shared headcount report is missing workers – their security group is constrained to their org, not the broader scope that the report author tested against with a tenant-wide security context.

The interaction between all three layers is covered in depth in the securing sensitive data in Workday Analytics guide, which also covers field-level encryption, Prism dataset-level controls, and the role-based access control patterns that protect PII and compensation data across both the Report Writer and Prism Analytics layers.

BIRT Layouts: Attaching Formatted PDF Output to Reports

Workday supports attaching Business Form Layouts – PDF template definitions built using the BIRT (Business Intelligence and Reporting Tools) designer inside Workday Studio – to custom reports. The result is a report that generates branded, formatted PDF output rather than the standard grid-based output Workday produces by default.

The data layer for a BIRT layout is always an Advanced custom report exposed as a web service. BIRT cannot accept more than one data source per layout definition – a constraint that means merging data from multiple object types for BIRT output requires either a Composite report feeding a Prism dataset that the BIRT report then consumes, or a Workday Studio-based integration that pre-assembles the data. This single-source constraint is documented in Workday’s BIRT integration materials and is a significant architectural consideration for layouts that need to combine data from HCM and Finance in a single formatted output.

Common BIRT use cases include custom pay slips with jurisdiction-specific layouts and multi-language localization, offer letters pulling compensation and job data from the hiring process, employment verification letters, and formatted compliance reports for regulatory submission. The full technical implementation process for BIRT layouts against Advanced report data sources – including Studio installation, XML/XSD data structure validation, template design patterns, and multi-language localization – is covered in the Workday BIRT payroll reporting guide.

When Prism Analytics Becomes the Right Architecture

The Report Writer and Workday Prism Analytics address different problems, and confusing the boundary between them produces both under-use of Prism and over-engineering of Report Writer configurations that should have moved to Prism earlier.

The Report Writer is the correct tool for operational reporting against live Workday transactional data – worker lists, benefit enrollment outputs, payroll exception reports, financial transaction details, audit trail views. It is the correct tool when the analysis involves only Workday-native data, when the output is a list or matrix view rather than a persistent dataset, and when the calculation complexity is within the reach of Workday’s calculated field function library.

Prism Analytics is the correct tool when any of four conditions applies. First, when the analysis requires data from outside Workday – call center metrics, LMS completion data from an external provider, headcount data from a third-party applicant tracking system, or any external source that needs to be joined against Workday data. Second, when the calculation logic exceeds what the Report Writer’s calculated field language can express – multi-variable regression outputs, complex windowed aggregations, or transformations that require a full-featured expression engine. Third, when the analytical dataset needs to persist across sessions so that repeated queries run against a stable, cached result rather than re-executing the full Report Writer query every time. Fourth, when report query times against live transaction data have grown to a point where production users are experiencing timeouts or delays that affect operational decision-making.

The pipeline from Report Writer to Prism flows through RaaS. An Advanced report is configured as a web service, a Prism data pipeline ingests that report’s output via its RaaS endpoint on a defined schedule, and Prism’s transformation layer applies any joins, field derivations, or aggregations needed before publishing the result as a persistent Prism dataset. That published dataset then becomes a new data source in Workday – queryable from the Report Writer like any other data source, accessible from Workday’s People Analytics and Discover dashboards, and securable through the same domain security model as native Workday data sources.

For workforce analytics use cases requiring historical trending, attrition prediction, or workforce cost modeling that combines Workday HCM data with financial data, this Report Writer to Prism pipeline pattern is the architecturally correct approach. The Workday Prism Analytics overview explains the platform’s dataset, transformation, and publication model. For teams building financial analytics specifically – where Workday Financial Management data sources feed both Report Writer reports for operational use and Prism datasets for strategic analysis – the Workday Financial Management guide provides the functional context for those data source selections.

Performance Optimization: What Actually Determines Report Speed

Report performance in Workday degrades predictably from a small set of structural causes. Identifying them before building complex reports is easier than diagnosing them post-production.

Data source selection is the largest variable. An indexed data source with a 50,000-worker population executes substantially faster than a non-indexed source with the same population. Check whether the data source you are considering is indexed using the Edit Data Source task before committing to it in a production report build.

Filter placement is the second variable. Primary object filters reduce the record population before related object traversal occurs. Sub-filters on related objects evaluate after the primary population is assembled. A report that filters on a related object field without any primary object filter first assembles the entire primary population and then applies the related object condition, which is a significantly more expensive operation than filtering early on an indexed primary object field.

Calculated field depth is the third variable. Each calculated field evaluation adds computational overhead proportional to the complexity of the expression and the number of records it must evaluate against. Calculated fields that reference other calculated fields create dependency chains that multiply this overhead. Keep calculated field logic as shallow as possible. Where a calculation requires multiple stages, evaluate whether building an intermediate tenant-wide calculated field (so the computation is cached at the tenant level rather than re-evaluated per-report execution) reduces the overall cost.

Sorting on object-type fields – fields that return references to other objects rather than scalar values – is substantially more expensive than sorting on simple typed fields like dates, numbers, or text strings. Where reports require sorting that involves an object-type field (sorting by Supervisory Organization name, for example), evaluate whether a grouping structure can replace the sort, or whether post-export sorting in Excel is acceptable.

Column count also matters. Reports with large numbers of columns where each column involves a separate related object traversal execute slower than equivalent reports with fewer columns. Audit your column configuration before finalizing to confirm that every column in the output is actually used by the report’s consumers. Columns added “just in case” during development that are not displayed in the output or exported version represent unnecessary query overhead on every execution.

Finally, the Optimize for Performance flag in the Advanced report configuration activates an alternative execution path for large data sets. Enable it for high-volume production reports, test the output to confirm no calculated field compatibility issues, and document the flag’s status in the report definition so future maintainers understand why certain calculated field types may not be available for that report.

Report Type Selection: The Decision Framework

Practitioners configuring a new report requirement can apply the following logic to select the correct type.

If the requirement is a flat list of records from a single data source with basic column selection and sorting, and you are certain it will never need web service exposure, sharing, calculated fields, or integration downstream use, Simple is sufficient. If there is any possibility of any of those downstream requirements materializing, build Advanced from the start.

If the requirement involves aggregated dimensional analysis – counts, sums, averages, or any other measure broken down by the intersection of two or more field values – the correct type is Matrix. If practitioners in your environment are exporting Advanced reports to Excel to run pivot tables manually, that is a reliable signal that Matrix reports are absent where they should be present.

If the requirement needs to present metrics from multiple unrelated data sources in a single aligned output, or to compute metrics whose components come from different data sources, the correct type is Composite. Composite builds require Matrix or Trending sub-reports as inputs.

If the requirement is explicitly about how a measure changes over time, across defined periods, using snapshot data sources for performance, the correct type is Trending. Time-series workforce analytics – headcount evolution, attrition rate trends, pay equity trends over fiscal periods – belong in Trending reports.

If the requirement is a performance and potential talent calibration grid for succession planning or annual talent review, the correct type is nBox.

If the requirement is a side-by-side attribute comparison of a small number of instances across a large number of fields, the correct type is Transposed.

If the requirement is to define search result output or to provide an EIB-facing data source that filters by runtime facet values, the correct type is Search.

Every other production reporting use case – which represents the vast majority – is an Advanced report. The most complex Advanced report configurations eventually connect downstream to Prism for persistence, transformation, or external data blending.

Working with Sama on Workday Reporting Architecture

A well-structured reporting layer in Workday is not primarily a matter of knowing which buttons to press. It is a matter of understanding how data source selection, security group configuration, calculated field scoping, report type architecture, and RaaS endpoint management interact across a tenant that evolves continuously after go-live.

Workday’s two annual release cycles introduce new data sources, new calculated field functions, new report type capabilities, and new integration patterns that affect existing reporting architectures. Reports built on assumptions from a 2022 implementation may be performing sub-optimally against new indexed sources that became available in subsequent releases. Calculated field libraries that were built as report-specific during implementation should often be promoted to tenant-wide fields as the reporting layer matures. EIB outbound integrations running against Advanced report RaaS endpoints may benefit from Prism pipeline architectures that reduce extraction overhead and enable richer downstream analytics.

Sama’s consultants work specifically in post-go-live Workday environments. The reporting work Sama does ranges from individual report rebuilds that resolve production performance or security issues to full reporting architecture reviews that map the tenant’s existing report library against the current platform capabilities and identify structural improvements. For teams building out the time-tracking analytics layer – a data-rich area that is consistently under-reported in most tenants – the Workday Time Tracking technical playbook details the specific report objects that generate the highest analytical value from time data: Worker Time Block, Time Entry Code, and their relationships to payroll results and cost center allocations.

To discuss your Workday reporting environment and what a structured reporting architecture review would involve, reach out to the Sama team at samawds.com.