Study guide
7.1 Business Objects, Fields, Related Business Objects & Data Sources
Workday Pro Platform Administrator Certification Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: The Workday Platform
1.1 Workday Products, Functional Areas & Product Touchpoints 1.2 The Object Management Model & Business Objects 1.3 Navigation & Search Techniques 1.4 Organizations in Workday
2 Chapter 2: Tenants & Release Management
2.1 Tenant Types & Tenant Management Tasks 2.2 Releases, Adoption, System Testing & Support
3 Chapter 3: The Configurable Security Framework
3.1 Components of the Configurable Security Framework 3.2 Core Security Group Types: Workday-Assigned, User-Based & Role-Based 3.3 Advanced Security Group Types
4 Chapter 4: Security Policies, Assignment & Troubleshooting
4.1 Domain Security Policies & Permissions 4.2 Assigning Roles & Security Group Membership 4.3 Troubleshooting Security Access Issues
5 Chapter 5: Business Process Definitions & Steps
5.1 The Business Process Framework & Definitions 5.2 Business Process Step Types 5.3 Step Configuration, Order & the Completion Step
6 Chapter 6: BP Security, Condition Rules & Troubleshooting
6.1 Business Process Security Policies 6.2 Creating & Testing Condition Rules 6.3 Using Reports to Troubleshoot Business Processes
7 Chapter 7: Report Foundations & Custom Reports
7.1 Business Objects, Fields, Related Business Objects & Data Sources 7.2 Standard Reports, Custom Report Types & the Report Writer 7.3 Worklets, Dashboards & Sharing Reports
8 Chapter 8: Calculated Fields, Alerts & Report Administration
8.1 Identifying & Maintaining Calculated Fields 8.2 Configuring & Testing Alerts 8.3 Scheduling Reports, Report Groups & Transferring Ownership 8.4 Troubleshooting Report Data & Access Issues
9 Chapter 9: Integration Architecture & Security
9.1 Workday Integration Architecture & Web Services 9.2 Workday Integration Tools & Choosing the Right One 9.3 Integration System Users & Integration System Security Groups
10 Chapter 10: Enterprise Interface Builders
10.1 Creating & Launching an Inbound EIB 10.2 Creating & Launching an Outbound EIB 10.3 Troubleshooting EIB Data Loads & Access Issues
7.1 Business Objects, Fields, Related Business Objects & Data Sources
Key Takeaways Explain This Topic AI
A report data source determines the primary business object and the population of instances the report returns.
The primary business object holds the report's data; related business objects are reached through fields and can have one-to-one or one-to-many relationships with it.
Data sources and report fields are each secured by domains, so building a report can require access to several domains at once.
Data source filters narrow the population a data source returns and are themselves securable items governed by domains.
Use the View Report Field task and the field's Related Actions to inspect a field, copy its Integration ID or WID, and see which domains secure it.
Last updated: August 2026
Start from the data source
When you build a custom report, the first real decision is the data source . It determines two things at once:
The primary business object (PBO) the report is built on.
The population of instances the report can return.
With the exception of composite reports, you must select a single report data source when creating a report , and the report displays one row for each instance of that primary business object.
Two data sources on the same business object are not interchangeable. "All Active Employees" and "All Workers" both return Worker instances, but one is pre-filtered to active employees. Choosing the wrong one produces a report that is subtly incomplete rather than obviously broken - which is why data source choice appears so often in troubleshooting scenarios.
Business objects, fields, and instances
From the object model in section 1.2:
- Concept Analogy Example
- Business object Worksheet or table Worker
- Field Column Hire Date, Job Profile
- Instance Row Logan McNeil
A report returns one row per instance of the primary business object returned by the data source.
Primary and related business objects
The primary business object holds the data that displays in the report.
Related business objects (RBOs) are objects associated with the primary object. Workday links them together through fields , and RBOs let you access fields in a report that do not belong to the primary business object.
The relationship cardinality decides how the field behaves as a column:
- Relationship Behavior in a report Handling
- One-to-one Exactly one value per row Use the field directly as a column
One-to-many A set of values per row Accept a multi-value cell, use a calculated field to extract a single instance, or rebuild the report with the other object as the PBO
The classic symptom: a report "duplicates" rows or shows several values crammed into one cell. That is a one-to-many related business object being used as though it were one-to-one. The fix is usually to change the primary business object, not to add a filter.
Workday's own example chains several relationships: a Worker is associated with a Position ; that position is associated with a Job Profile ; that job profile carries management level , job classification , and exempt status . From a Worker-based report you can reach all of those without writing a join, because Workday already knows the path.
Class report fields
Fields available on a business object include both delivered fields and class report fields - fields defined for reporting on that class of object. When you replace a field across many reports you work with class report fields directly, and the Reporting Mass Action task is the tool for that (covered in section 8.3).
To research how business objects relate to one another - essential before designing a calculated field or reaching for a related business object - run the Business Object Details report.
To inspect a field, use the View Report Field task. From the field's Related Actions you can copy its Integration ID or WID , which is how you unambiguously identify a field when two have similar names - and the only way to identify a field marked Do Not Use (DNU) .
Data source filters
A data source filter narrows the population a data source returns before your report's own filters run. Workday delivers data source filters, and they appear as a selectable option when you choose a data source.
Two consequences worth holding:
A data source filter runs before report filters, so it constrains what your filters can even see.
Data source filters are securable items , secured by domains like everything else. This is why the guidance on transferring report ownership specifies that the new owner needs access to the report's data source and data source filter .
Security applies at every level
This is the most examinable idea in the reporting module. Domains secure all delivered items , and the pieces of a report are secured individually :
- Securable item Example Securing domain (example)
- Task Create Custom Report Analytics Data: Report Fields and Values
- Data source All Customer-Owned Deductions Set Up: Payroll (Calculations - Payroll Specific)
- Report field Billing Schedule Process: Billing
- Standard report Find Journal Lines Process: Journals
So creating a custom report requires view permission for :
A security domain for the data source you want to use, and
Security domains for the report fields you want to add.
Prompts only show the data sources and report fields you have access to. That is a genuinely useful diagnostic: if a colleague can see a data source in the prompt and you cannot, the difference is domain access, not report configuration.
The trap that generates the most support tickets: a field used only in a filter or subfilter is still a securable item that the runner of the report needs access to. A report can therefore fail for a user on a field they never see in the output. Section 8.4 develops the diagnosis.
Choosing a data source in practice
Identify the business object the report should return one row per - worker, position, journal line, expense report.
List candidate data sources on that object and read their descriptions. Note any that are pre-filtered.
Check whether the fields you need are on the PBO or on an RBO , and check the cardinality of any RBO.
Confirm you have access - if the data source does not appear in the prompt, that is a domain problem, and adding it to the report is not the fix.
Prefer the narrower data source when two would work. A pre-filtered data source is usually faster and less likely to leak instances you did not intend to include.
A worked example
Requirement: list every active employee with their job profile's management level and their cost center.
One row per worker → the PBO is Worker .
Data source : a worker data source pre-filtered to active employees.
Management level is not a Worker field. It is reached through Position → Job Profile , a chain of one-to-one relationships, so it works directly as a column.
Cost center comes from the worker's organization assignment - also one-to-one for the primary assignment.
Security : you need the domain securing the data source, plus the domains securing each report field. If management level does not appear in the field prompt, you lack the domain that secures it.
Nothing here required a join, a subquery, or knowledge of a table structure. That is what the object model buys you - and why understanding it converts most reporting problems into security problems, which have a known diagnostic method.