Skip to main content
Administrator Guide
Last Updated: 2026-04-03
FAQ: Calculated Fields

FAQ: Calculated Fields

What happens when I make changes to the hierarchical structure? Does this impact reporting, specifically calculated fields?
When you change organizational hierarchy in Workday, the impact on your reporting depends on how your calculated fields are constructed.
Calculated fields that reference a hard-coded level number or name are likely to break or return incorrect data when you add or remove levels. You must manually identify, review, and update any lookup hierarchy calculated fields with a specified level number or name after a hierarchy change.
Calculated fields built with dynamic functions are resilient to changes in the number of levels because they’re based on relationships. Reports that display hierarchies should automatically reflect the new structure because the underlying data isn’t affected. A worker's assignment to their supervisory organization remains the same, and only the organization's position in the hierarchy changes.
How do I manage calculated fields in hierarchy changes?
Before you make hierarchy changes, run the
All Calculated Fields
report to find lookup hierarchy fields and to determine if you need to manually update them.
Use lookup hierarchy rollup fields or relational fields like superior organization instead of fields like lookup hierarchy that reference hard-coded numbers or names. This way, you won’t have to manually update your calculated fields when hierarchies change.
Always make your hierarchy changes in a sandbox tenant first. Run key reports and integrations to identify any calculated fields or processes that produce unexpected results.
Document which calculated fields that rely on a specific level so you can find and update them during future reorganizations.
How do I use calculated fields as filters on reports?
How can I link a calculated field from one business object to another one?
Use a lookup related value (LRV) calculated field. This field enables you to retrieve a value from a related business object and bring it into the data record of your report's primary business object. See
Lookup Related Value
.
Can I convert a report-specific calculated field to a tenant-wide field?
You can only convert a report-specific calculated field into a tenant-wide field when it isn’t dependent on other report-specific calculated fields. If it is, then you must first convert the dependent report-specific calculated fields into tenant-wide calculated fields.
Example: If Calculated Field 1 (CF1) uses Calculated Field 2 (CF2) in its definition, you must convert CF2 into a tenant-wide field before you can convert CF1.
How do I use calculated fields to connect a primary and related business objects that are not directly linked?
To link your PBO to the target RBO, you create a chain of LRV calculated fields.
Example: To link the Worker business object to the Time Sheet business object, you can use the Time Block business object as an intermediary.
  1. Create an
    LRV
    field on the Time Block object to look up the desired field from the Time Sheet object.
  2. Create a second
    LRV
    field on the Worker object to look up the value from the calculated field you just created on the Time Block object.
What business object should I use to create calculated fields in notice period rules?
Use the Notice Period Target business object. If the data you need is on a different object, use a lookup related value calculated field to pull that information into the Notice Period Target context.
For condition rules within a business process, the calculated field must be available on a business object related to the business process, such as Worker Business Process or Action Event. This can sometimes involve creating a chain of calculated fields to move the data between business objects.