12.2 Primary Data Sources, Indexed Data Sources & Business Objects

12.2 Primary Data Sources, Indexed Data Sources & Business Objects

Quick Answer: The Data Source is the single most critical configuration choice when creating a custom report in Workday. It establishes three immutable boundaries: the Primary Business Object (PBO) representing the baseline grain (one row per instance), the initial population (e.g., active workers vs. all historical records), and the applicable security domains. Enterprise reporting distinguishes between Standard Data Sources (which scan live in-memory objects) and Indexed Data Sources (which leverage pre-computed in-memory indexes on specific fields for massive performance gains at scale). When navigating to Related Business Objects (RBOs), designers must distinguish between 1:1 Single-Instance relationships (direct attributes) and 1:M Multi-Instance relationships (which return collections and risk duplicate rows if improperly handled).

---

The Architecture of Workday Data Sources

When initiating the Create Custom Report task, the designer must select a Data Source. Unlike relational database query builders where the developer writes custom SQL FROM and WHERE clauses against raw tables, Workday requires the selection of a pre-defined Data Source provided by the core platform.

The Three Critical Functions of a Data Source

1. Establishes the Primary Business Object (PBO): The PBO determines the foundational "grain" of the report. Every row in the primary output corresponds to exactly one instance of the PBO.
2. Filters the Initial Record Population: The Data Source applies built-in, kernel-level filtering before any custom report filters are evaluated. For instance, a data source may automatically filter out terminated workers or limit instances to active job requisitions.
3. Enforces Domain Security Context: Every data source belongs to specific functional domains (such as Staffing, Worker Data, or Payroll Reporting). Users cannot run or view reports built on data sources outside their authorized security permissions.

+---------------------------------------------------------------------------------------+
|                                 DATA SOURCE LAYER                                     |
|  - Determines PBO (e.g., Worker, Position, Event)                                     |
|  - Pre-filters population (e.g., Active only, US only)                                |
|  - Applies security domain boundary                                                  |
+---------------------------------------------------------------------------------------+
                                           |
                                           v
+---------------------------------------------------------------------------------------+
|                            PRIMARY BUSINESS OBJECT (PBO)                              |
|                           Grain: 1 Instance = 1 Report Row                            |
+---------------------------------------------------------------------------------------+
         |                                                       |
         | 1:1 Relationship (Single-Instance)                    | 1:M Relationship (Multi-Instance)
         v                                                       v
+-----------------------------------+               +-----------------------------------+
|   RELATED BUSINESS OBJECT (RBO)   |               |   RELATED BUSINESS OBJECT (RBO)   |
|  Example: Supervisory Organization|               |  Example: Dependents, Job History |
|  Direct field retrieval on row    |               |  Requires ESI / Delimited display |
+-----------------------------------+               +-----------------------------------+

Standard HCM Data Sources Catalog

Selecting the correct data source directly dictates query performance and data accuracy. The following table contrasts the most widely utilized HCM data sources:

Exam Tip: If a report requires open or vacant positions, choosing Workers for HCM Reporting or All Active and Terminated Workers as the data source will never return vacant positions. Vacant positions do not have an associated Worker instance. To report on vacant positions, the data source must have Position as its Primary Business Object (such as Current Staffing).

---

Standard Data Sources vs. Indexed Data Sources

As organizations grow from 5,000 to over 100,000 workers, custom reports querying standard data sources can experience latency. To address this, Workday introduced Indexed Data Sources.

Standard Data Sources Mechanics

• In-Memory Sequential Scan: When an Advanced report runs against a Standard Data Source, the in-memory engine scans all instances matching the data source definition, evaluating report filters sequentially across RAM.
• Unconstrained Calculated Fields: Standard data sources allow designers to filter by any field, including complex nested calculated fields.
• Performance Threshold: On massive datasets (e.g., millions of historical compensation changes or 200,000+ workers), complex filtering on standard data sources can result in long runtimes or report execution timeouts.

Indexed Data Sources Architecture

• Pre-Indexed Memory Structures: An Indexed Data Source (IDS) utilizes high-performance, pre-computed in-memory search indexes built on designated indexed fields (e.g., Supervisory Organization, Location, Company, Worker Type, Cost Center).
• Sub-Second Execution at Scale: Rather than scanning every instance in memory, the engine looks up values directly through hash maps and B-tree indexes, executing queries in fractions of a second even across massive enterprise tenants.

The Golden Rule of Indexed Data Sources (Exam Watchpoint)

To leverage the acceleration of an Indexed Data Source, the custom report's primary filter criteria must evaluate indexed fields. If a report author applies primary filter conditions using unindexed fields or complex custom calculated fields, the query engine cannot utilize the index, neutralizing the performance benefit or causing configuration validation warnings.

Standard vs. Indexed Data Sources Comparison Matrix

---

Primary Business Objects (PBO) vs. Related Business Objects (RBO)

Understanding the object hierarchy and relationship cardinality prevents the two most common errors in Workday reporting: missing records and duplicate rows.

Establishing the Data Grain with the PBO

The Primary Business Object (PBO) establishes the foundational grain of the report. The fundamental rule is: $\text{1 Instance of the PBO} = \text{Exactly 1 Row in the Primary Report}$

• If Worker is the PBO, the report generates one row per worker.
• If Supervisory Organization is the PBO, the report generates one row per organization (even if an organization contains 500 workers).
• If Job Requisition is the PBO, the report generates one row per job requisition.

Object Cardinality: 1:1 vs. 1:M Relationships

When an author adds fields from a Related Business Object (RBO), the relationship cardinality between the PBO and RBO dictates how data displays:

1. Single-Instance Relationships (1:1 or N:1)

• The PBO links to zero or exactly one instance of the RBO.
• Example: Worker (PBO) -> Supervisory Organization (RBO). A worker has exactly one primary supervisory organization.
• Display Behavior: Fields from the RBO (e.g., Supervisory Organization > Organization Name) populate directly on the worker's row without creating additional rows or sub-lines.

2. Multi-Instance Relationships (1:M)

• The PBO links to zero, one, or multiple instances of the RBO.
• Example: Worker (PBO) -> Dependents (RBO), Compensation Component Plans (RBO), or Job History (RBO).
• Display Behavior: If an author places a multi-instance field directly onto an Advanced report, Workday renders the related instances as line-item sub-rows within that worker's single cell.
• The Cartesian Multiplication Trap: If a designer attempts to group or subtotal on multi-instance fields without isolating a specific instance, rows multiply across the combinations, distorting headcount counts and financial totals.

Worker (PBO)           Dependents (1:M RBO)         Report Output Cell
+----------------+    +-----------------------+    +----------------------------------+
| Logan McNeil   |--->| Dependent 1: Sarah    |--->| Logan McNeil | Sarah             |
|                |    | Dependent 2: Jacob    |    |              | Jacob             |
+----------------+    +-----------------------+    +----------------------------------+

Strategies for Handling 1:M Multi-Instance Data

When reporting on multi-instance data from a PBO, certified authors deploy three core techniques:

1. Delimited Concatenation: Format the multi-instance collection into a single comma-delimited text string (e.g., displaying all language proficiencies in a single line: English, Spanish, French).
2. Extract Single Instance (ESI) Calculated Field: Use an ESI calculated field to pull exactly one specific instance from the collection (e.g., pulling only the Primary Dependent or the Most Recent Job Change Event).
3. Flip the PBO: If the business objective is to analyze the multi-instance items themselves (e.g., auditing all dependents over age 26 for healthcare compliance), change the PBO to the child object (e.g., choose a data source where Dependent is the PBO). This makes each dependent their own row, with the worker accessed as a single-instance RBO.

---

Certification Pitfalls & Common Exam Traps

1. The Inappropriate Data Source Trap: Exam questions often describe a report built on All Active and Terminated Workers designed to calculate current average salary. The report runs slowly and produces skewed averages. The mistake is selecting All Active and Terminated Workers (which includes historical inactive workers with null or outdated compensation) instead of Workers for HCM Reporting.
2. The Vacant Position Reporting Trap: A scenario asks: "A report author creates an Advanced Report on 'Workers for HCM Reporting' to display all budgeted positions. When the report executes, open positions are missing. Why?" The candidate must recognize that vacant positions have no associated worker; the report must use a data source where Position is the PBO (such as Current Staffing).
3. Indexed Data Source Filter Misconfiguration: When asked why a custom report built on an Indexed Data Source fails to achieve sub-second response times, the correct answer is that the filter criteria does not utilize indexed fields in the primary filter block, forcing the engine into standard evaluation.
4. Multi-Instance Aggregation Distortion: If an exam question describes headcount being accidentally multiplied by three in a custom compensation report, look for an unextracted multi-instance field (such as Compensation Plans or Direct Reports) being evaluated in the grouping section.