7.1 Business Objects, Fields, Related Business Objects & Data Sources

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:

1. The primary business object (PBO) the report is built on.
2. 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:

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:

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:

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

1. Identify the business object the report should return one row per - worker, position, journal line, expense report.
2. List candidate data sources on that object and read their descriptions. Note any that are pre-filtered.
3. Check whether the fields you need are on the PBO or on an RBO, and check the cardinality of any RBO.
4. 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.
5. 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.