Study guide
12.2 Primary Data Sources, Indexed Data Sources & Business Objects
Workday Human Capital Management HCM
Track your progress as you read
Finished sections get a check mark.
1 Foundation & Navigation
1.1 Workday Cloud Architecture, Tenants & Navigation 1.2 Business Objects, Data Model & Related Actions 1.3 Worker Types, My Tasks & Delegation
2 Organizations & Hierarchies
2.1 Supervisory Organizations & Hierarchy Structure 2.2 Matrix, Location & Custom Organizations 2.3 Cost Centers & Financial Organization Hierarchies 2.4 Reorganizations, Effective Dating & Inactivation
3 Staffing Models & Worker Lifecycle
3.1 Staffing Models: Position Management vs Job Management 3.2 The Hire Process & Contingent Worker Contracting 3.3 Job Changes: Transfers, Promotions & Lateral Moves 3.4 Terminations, Separations & Staffing Audit Trails
4 Jobs, Positions & Headcount Management
4.1 Job Profiles, Families & Management Levels 4.2 Position Creation, Restrictions & Availability Dates 4.3 Managing Positions: Close, Freeze & Requisitions
5 Business Process Framework Fundamentals
5.1 Business Process Definitions & Flow Architecture 5.2 Step Types: Actions, Approvals & Approval Chains 5.3 To-Do Steps, Checklists & Integration Steps 5.4 Completion Order, Parallel vs Serial Routing, Conditions & Advanced Routing
6 Advanced Business Process Administration
6.1 Event Operations: Rescind, Cancel, Correct & Mass Operations 6.2 Effective Dates vs Entry Moments & Subprocess Execution 6.3 Service Center Routing & Workday Illuminate AI for BP Intelligence
7 Configurable Security Architecture
7.1 Security Fundamentals: Domains, Functional Areas & Domain Security Policies 7.2 Role-Based Security Groups: Constrained vs Unconstrained 7.3 User-Based, Job-Based, Segment-Based & Workday-Assigned Security Groups 7.4 Security Policy Activation, Role Assignment & Security Audit
8 Compensation Structure & Plan Design
8.1 Compensation Packages, Grades & Grade Profiles 8.2 Base Pay, Allowance Plans & Period Salary Plans 8.3 Bonus Plans, Merit Plans, Commission Plans & Stock Grants 8.4 Compensation Eligibility Rules, Defaulting Logic & Merit Review Cycles
9 Talent, Performance & Skills Management
9.1 Talent Profiles, Competencies & Certifications 9.2 Skills Cloud, Machine Learning Taxonomy & Skill Matching 9.3 Performance Review Cycles, Goals & Anytime Feedback 9.4 Succession Planning, Talent Pools & 9-Box Matrix
10 Absence Management & Time Off
10.1 Absence & Time-Off Plans, Types & Accruals 10.2 Absence Eligibility Rules, Validation Rules & Calendars 10.3 Leave of Absence (LOA) Types, Pay Status & Return to Work
11 Recruiting & Candidate Lifecycle
11.1 Job Requisitions, Postings & Career Sites 11.2 Candidate Pipelines, Stage Progression & Screening Workflows 11.3 Employment Offers, eSignatures & Ready for Hire Transition
12 Report Writer & Data Visualization
12.1 Building Custom Reports: Types, Columns, Sorting, Filters & Prompts 12.2 Primary Data Sources, Indexed Data Sources & Business Objects 12.3 Calculated Fields: Text, Date, Arithmetic, Logic & Lookup Related Value 12.4 Discovery Boards, Dashboards & Prism Analytics Integration
13 Workday Integrations & Enterprise Interface Builder
13.1 Integration Architecture: Core Connectors, Studio, REST & SOAP APIs 13.2 Integration Security: ISUs, ISSGs & Web Services 13.3 Enterprise Interface Builder (EIB): Outbound Integrations & Transformations 13.4 Enterprise Interface Builder (EIB): Inbound Integrations & Spreadsheet Templates
14 Release Management, Ecosystem & Workday AI
14.1 Semi-Annual Release Cadence, Preview Tenants & Feature Opt-In 14.2 Workday Illuminate AI, AI Assistant & Generative Productivity 14.3 Agent System of Record, AI Governance & Workday Extend
12.2 Primary Data Sources, Indexed Data Sources & Business Objects
Key Takeaways Explain This Topic AI
The Data Source defines the Primary Business Object (PBO), the initial evaluated population, and the security domains governing report execution.
Selecting an overly broad data source (such as All Active and Terminated Workers instead of Workers for HCM Reporting) degrades performance by forcing full-population in-memory scans.
Indexed Data Sources utilize pre-computed in-memory indexes on specific key fields, significantly accelerating query execution on large enterprise datasets.
To benefit from an Indexed Data Source, report filter criteria must evaluate indexed fields in the primary filter block.
Traversing from a PBO to a 1:M Multi-Instance RBO without proper extraction logic creates Cartesian row duplication or requires specialized multi-instance formatting.
Last updated: September 2026
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
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.
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.
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:
Data Source Primary Business Object (PBO) Scope / Population Evaluated Primary Use Case
Workers for HCM Reporting Worker Active employees and contingent workers, plus workers on active leave. Suppresses terminated workers. Operational active headcount, manager rosters, current compensation analysis.
All Active and Terminated Workers Worker Every worker instance ever created in the tenant (active, on-leave, retired, and terminated). Turnover and attrition analysis, historical tenure, alumni reporting.
Current Staffing Position All current positions, including both filled positions and open/vacant requisitions. Staffing plan execution, vacancy rate tracking, position control audits.
All Positions Position All historical, active, open, closed, and frozen position instances. Long-term position lifecycle audits and organizational redesign analysis.
Employees for HCM Reporting Worker Active direct employees only (excludes contingent/contract workers). Direct employee benefits eligibility, internal compensation grade audits.
Contingent Workers for HCM Reporting Worker Active contingent workers (contractors, consultants) only. Vendor management, contractor tenure tracking, contingent labor spend.
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
- Architectural Attribute Standard Data Source Indexed Data Source (IDS)
- Query Mechanism Sequential in-memory object scan Direct in-memory index pointer lookup
- Performance on Large Tenants Moderate; degrades with nested calculations Ultra-high; sub-second response times
Filter Field Requirements Any simple or calculated field permitted Must filter on indexed fields in primary block
- Report Type Support Simple, Advanced, Matrix Advanced, Matrix, Discovery Boards
- Calculated Field Flexibility Unlimited Restricted on primary filter lines
- Common Examples Workers for HCM Reporting Indexed Workers for HCM Reporting
- 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: 1 Instance of the PBO = Exactly 1 Row in the Primary Report \text{1 Instance of the PBO} = \text{Exactly 1 Row in the Primary Report} 1 Instance of the PBO = 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:
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 ).
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 ).
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
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 .
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 ).
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.
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.