When a reporting or integration requirement needs data from more than one place, Workday teams choose between three tools: Custom Report Writer (Advanced, Matrix, or Composite reports), Workday Query Language (WQL), and Workday Prism Analytics. Choosing the wrong layer leads to slow reports that time out on related-object joins, WQL queries that cannot see external historical records, or Prism datasets that accidentally strip Workday domain security when created from a custom report.
This guide compares the three layers, explains the exact architectural and security boundaries of a Prism Data Source, and details how to expose Prism data safely in custom reports, reporting models, and WQL.
When to use Custom Reports, WQL, or Prism Analytics
| Capability | Custom Reports (Advanced / Matrix / Composite) | Workday Query Language (WQL) | Workday Prism Analytics |
|---|---|---|---|
| Primary data origin | Live Workday tenant data sources and business objects | Live Workday data sources (including published Prism data sources exposed to WQL/reporting) | Blended external data (SFTP, REST API, file upload) + Workday report extracts |
| Cross-source joins | Composite Reports join multiple subreports on a shared Control Field business object; Advanced/Matrix reports traverse pre-delivered Related Business Object (RBO) links | SELECT queries one data source at a time and traverses its delivered related business object fields |
Full relational pipeline in the Data Catalog: join, union, group, filter, and transform multiple tables and derived datasets before publishing |
| Primary Business Object (PBO) | Linked directly to Workday's live object model | Bound to the queried data source's PBO | Has its own isolated PBO that is not linked to other business objects in Workday unless you configure Instance fields or a Reporting Model |
| Best fit | Operational HCM/Finance reports, RaaS feeds, dashboards, and financial statements | Extend apps, orchestrations, API extracts, and fast ad-hoc tenant queries (see our WQL guide) | Historical data conversion archives, third-party point-of-sale/claims/badge data blended with worker or ledger dimensions |
How a Prism Data Source differs from a delivered Workday data source
When you publish a Prism table or dataset (manually or on a schedule), Workday creates a Prism Data Source (viewable via the View Prism Data Source report). Workday documents six structural differences between a Prism data source and a Workday-delivered data source:
- Unlinked Primary Business Object: A Prism data source has its own PBO that is not automatically linked to other Workday business objects. To link a Prism column to a live Workday object (such as Worker, Supervisory Organization, or Cost Center), you must create Instance or Multi-Instance fields mapped to valid Workday IDs.
- Instance fields store only the WID: In a Prism data source, Instance and Multi-Instance fields store only the unique identifier (WID), not the display name. Because of this, Workday blocks you from using Instance or Multi-Instance fields inside text-manipulating calculated fields like Format Text or Substring Text, and only 17 calculated field functions are supported on Prism data sources.
- Report type restrictions: Prism data sources support Simple and Transposed reports fully, Matrix reports (except Lookup Prior Value), Composite reports (only if the Prism data source contains at least 1 Instance field), and Advanced reports (without Subfilters; Workday also warns to add RBO fields only when necessary to avoid report performance degradation).
- Inactive state and deletion rules: A Prism data source can become inactive—meaning it still exists in the tenant, but is empty and unavailable for querying in reports or discovery boards. You can delete a Prism data source from the tenant only after removing every custom report and discovery board visualization that references it.
- Modeled reporting (
Set Up Reporting Model): To include Prism actuals or historical versions alongside live financial or operational models, create field mappings (Create Field Mapping for Reporting Model) and run Set Up Reporting Model (secured by the Set up Reporting Model domain in System) to bind the Prism field mappings, custom versions, and Instance dimensions into the reporting model.
The 5-phase Prism security trap (why tables have unconstrained access)
The most common security mistake in Prism Analytics happens between Phase 1 (bringing data into the Data Catalog) and Phase 3 (applying data source security before publishing).
Workday divides Prism security into five phases:
- Phases 1 & 2 — Tables, Derived Datasets, and Data Change Tasks (Unconstrained Access): When you create a table or base dataset in the Data Catalog from a Workday custom report, Workday removes all security domains configured for the business objects in that report. Access to a Prism table or dataset in the Data Catalog (via View Table Details, Edit Table, View Dataset Details, or Edit Dataset Transformations) is unconstrained: anyone granted access via the Prism: Tables or Prism Datasets security domains—or shared as a Table Viewer, Table Editor, or Dataset Editor—can view all fields and rows (or sample rows in datasets and data change tasks), regardless of origin.
- Phase 3 — Configuring Prism Data Source Security (
Prism: Manage Data Source): Before publishing data for reporting or discovery boards, an administrator with the Prism: Manage Data Source domain must configure Edit Prism Data Source Security at four levels:- Data source-level (table-level): Specify one or more security domains that control who can see the Prism data source at all.
- Row-level (
Securing Entities): Populate the Securing Entities prompt with one or more Instance or Multi-Instance fields on the dataset (such as Supervisory Organization or Company). Workday combines these securing entities with the user's constrained security group memberships to filter which rows each user can see. - Field-level: Assign security domains to sensitive columns (such as compensation or claim amounts) to control who can see specific fields.
- Field value-level: Workday combines your configured Securing Entities with field-level security domains to restrict who can see specific field values by row context.
- Phases 4 & 5 — Publishing and Querying (
Prism: Default to Dataset Accesstrap): If you publish a Prism data source without configuring data source security in Phase 3, Workday falls back to the Prism: Default to Dataset Access domain, which grants contextual access based on underlying table/dataset access rather than row-level organizational constraints. Always configure Securing Entities and data source domains before exposing a Prism data source to report writers or WQL queries.
Exploring WQL, reports, and Prism data sources with kiweely
When you need to know whether a question can be answered directly from a live Workday data source via WQL or requires a custom report or Prism dataset, kiweely inspects your tenant's live data sources, fields, and security domains in the conversation. It can run and verify WQL queries against your tenant, check why a Prism data source is returning no rows to a test user via proxy, and draft or update the report definition with your approval.