Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2026-03-13
Concept: Workday Reporting Relationships

Concept: Workday Reporting Relationships

Workday reporting utilizes business objects that represent data, relationships, and logic. Instead of querying isolated rows and columns, you interact with a network of these interconnected objects.
Examples:
  • The Worker business object serves as the primary data entity for employee and contingent worker records. From this business object, you can navigate to related information such as position, compensation, and benefits data.
  • The Supplier Invoice business object contains information on the supplier invoice header data. From this business object, you can access related information, such as invoice lines and payment information.
Workday links business objects together through instance fields, which are dynamic references to specific records rather than just plain text. In this model, you enter information once, and then Workday uses it consistently across your tenant. See Data Structure Principles.

Core Components of a Business Object

Each business object is composed of:
  • Instances, which represents a single, unique record within a business object. Example: the Worker business object contains 1 instance for each worker.Fields, which are the individual attributes within an instance. Example: The Worker business object includes fields like
    Hire Date
     and
    Legal Name
    .Workday uses these primary field types:
    • Workday-delivered fields: These are the standard fields that are included in all Workday tenants. Example: The Worker business object includes Workday-delivered fields such as
      Hire Date
      ,
      Legal Name
      , and
      Cost Center
      .
    • Custom fields: These are fields that you can create to store data that’s unique to your organization and not accommodated by Workday-delivered fields.
    • Calculated fields: These user-defined fields perform calculations, transformations, or logical evaluations on other fields. They enable you to manipulate data and retrieve values that don’t exist as a standard field.

Relationships between Primary Business Object and Related Business Object

The relationships between business objects define how the objects connect, and they enable you to pull data from a primary business object (PBO) and its corresponding related business objects (RBOs).
The relationship between PBOs and RBOs can be either:
  • 1-to-1, where 1 PBO instance links to 1 RBO instance. Example: Worker to Primary Position.
  • 1-to-Many, where 1 PBO instance links to multiple RBO instances. Example: Worker to Dependents.
To build a report, you start with a PBO determined by the data source you select. You can then pull in data from RBOs.
The PBO you select determines what a single row of data represents. Example: If you build a report using the Worker business object as your PBO, each row will represent 1 unique employee or contingent worker. You can then use RBOs to access data that’s connected to the PBO. Example: From the Worker PBO, you can access the Primary Position and Dependents RBOs.
When you select a PBO, Workday connects the PBO to an RBO through instance fields that determine which data is retrieved from the RBO. Example: The Worker PBO is linked to the Organization RBO. While many fields on the Worker object point to the Organization object, they serve different functional purposes, including:
  • The
    Supervisory Organization
     field, which returns only the specific organization associated with the worker’s primary position.
  • The
    Organizations Managed
    field, which returns a list of every organization where the worker holds a manager role.
Supervisory Organization
and
Organizations Managed
 both point to the same Organization RBO, but they return different results because the logic of the link is unique to each field.

Data Structure Principles

Workday organizes information using horizontal links and vertical hierarchies.
  • Horizontal Connectivity, when different business objects are linked to one another through related business objects. When you enter information on a PBO, the information is automatically available everywhere else it is needed.
  • Vertical Hierarchies, when business objects are organized vertically into a hierarchy, moving from general categories to more specific types.
When a business object is part of a hierarchy, the parent business object provides a common set of fields that its child business objects inherit. When you use a data source with a parent business object as the PBO, your report automatically returns instances from the PBO's child business objects.
The primary purpose of this structure is to ensure consistency and reduce redundancy. By defining common fields once on the parent object, all child business objects automatically inherit them. This is especially powerful for reporting.
Examples:
  • For HCM:
    • Parent Business Object: Worker
    • Child Business Objects: Employee, Contingent Worker
    • Inherited Fields (on Worker):
      Legal Name
      ,
      Worker ID
      ,
      Work Email
      ,
      Supervisory Organization
      .
    • Unique Fields for Employee:
      Employee Type (Regular/Temporary)
      ,
      Probation Period End Date
      ,
      Collective Agreement
      .
      Use the Worker object to view common fields like
      Email
      , but switch to the Employee child object to access Probation Date.
  • For Financial Management:
    • Parent Business Object: Accounting Worktag
    • Child Business Objects: Cost Center, Program, Fund, Gift etc.
    • Inherited Fields on Worktag: Worktag Name, Reference ID, Worktag Type.
    • Unique Fields for Cost Center: Cost Center Manager, Hierarchy Parent, External ID.
A child business object inherits all the fields from its parent business object and includes its own unique fields.
Examples:
  • The
    Hire Employee
     event is a child business object of the
    Action
    event. It includes all the fields from its parent, plus specific fields relevant only to the hiring process.
  • An accounting journal is a child business object of a journal. Workday uses the accounting journal for journal entries that are created by a user rather than generated automatically by another business process. As a child object, an accounting journal inherits all the common fields from its parent, journal, and includes its own unique fields that are relevant only to a manual entry process, such as:
    • Prepared By
    • Journal Source
    • Approval Status