Test the field on one instance before you touch the definition
A calculated field that shows blank, zero, or the wrong value on a report is almost never broken in general — it is wrong for a specific instance, for a specific viewer, or on a specific data source. Before editing anything, build a small test report on the same data source, filter it to one instance you already know the correct answer for, and add the calculated field next to each field it reads. That shows what the field actually returns there. If the calculated field itself resolves correctly on that instance but the report still shows blank, the problem is in the report's data source or the running user's security, not the field's logic. That one check tells you which half of this guide to read.
Check the field's business object against the report's data source
A calculated field is defined on one business object, and the fields it can reference come from that object and its related objects. A report only shows a value for rows where its primary data source resolves to that same object, directly or through a related-object path. A field built against Worker returns blank on a report whose source is Position, or on a row where the related Worker is empty, even though the field itself is configured correctly. Open the calculated field's definition and confirm the business object it names matches — or is reachable from — the report's data source before you look at the calculation at all.
A broken related-object path is the most common cause
Lookup Related Value, Extract Single Instance, Extract Multi-Instance, and Lookup Value as of Date all depend on a related business object relationship resolving on that particular row. When it doesn't, Workday returns an empty value rather than an error, which is why these are the functions most often blamed on "the calculated field" when the real gap is upstream data.
- Lookup Related Value returns blank. The relationship between the primary and related business object must be one-to-one. If the row's related instance is empty — for example a worker with no manager assigned yet — there is nothing to look up, and the function returns blank rather than an error.
- Extract Single Instance returns blank. The function returns zero instances when no related instance satisfies its boolean Condition. Open the condition and confirm it against the actual data on that instance: a condition written for "current" enrollment, for example, returns nothing for a worker whose enrollment ended.
- Extract Single Instance returns the wrong instance. When more than one related instance satisfies the condition, the Sort Field and Sort Direction decide which one comes back. Confirm both are set the way you expect, not just the condition.
- Extract Multi-Instance returns blank or fewer rows than expected. Check the Operation Type. Intersection and Except only return instances common to, or exclusive of, both source fields — if the two source fields pull from populations that rarely overlap, an Intersection can legitimately return nothing.
Effective dating and prompts change what "current" means
Lookup Value as of Date reads the value of a field as it stood on a specific date, using the Effective Date and Entry Date you configure. If the source field's business object doesn't support effective dating, the function ignores the date entirely and just returns the field's current value — which can look like the date logic silently failed rather than never having applied. If the field is prompted at report run time, confirm the person running the report actually supplied the date you expect; a blank or default prompt value changes the result without changing the field's definition.
Null arithmetic and error handling can turn into a quiet blank or zero
Arithmetic Calculation and Convert Text to Number both have a Return Zero on Error option. When it's checked, a calculation that would otherwise error — a null operand, dividing by zero, or non-numeric text — returns zero instead, and that zero can be indistinguishable from a real answer on the report. When it's unchecked, the same condition returns an actual error rather than a value. Check that setting first if a numeric field is coming back as zero for rows that should have a real value. For Convert Text to Number specifically, also confirm the Decimal Separator: a text value read with the wrong separator either converts to the wrong number or, without Return Zero on Error, fails outright.
Evaluate Expression stops at the first true condition
Evaluate Expression tests its conditions in row order and returns the value for the first one that evaluates true, then stops — it does not check the remaining rows even if more than one would match. If a broad condition sits above a narrower one, the narrow condition can never fire. If the field returns its Default Value when you expected a specific result, the row order is usually the first thing to check, followed by whether any condition is true for that instance at all.
Confirm the field type matches what you're actually returning
A Format Date field returns text, not a date, so a report or downstream field expecting a date type can show it as blank or fail to sort it correctly. Format Mask options are case-sensitive, so check each letter's case against a date whose answer you already know. For Convert Text to Number, remember the function reads the display ID when the source is a single-instance field, not visible label text, so a field that looks numeric on screen can still fail to convert if its underlying ID isn't numeric.
Security is a common cause of "it works for me but not for them"
A calculated field's own security follows the fields it's built from: you must have access to every field the calculation references to see a value at all. Without that access, Workday shows zero for currency or numeric fields and blank for every other field type — which looks exactly like a broken calculation to the person reporting it, even though the field is working as designed. When a field is correct for you but blank or zero for another user, compare each person's access to the underlying fields — including fields reached through a related business object — before assuming the definition itself is wrong. Also check report sharing separately from field security: a person can have access to run a shared report while still lacking access to one of the fields the calculated field depends on.
Diagnostic order
Work through these in order; each one rules out a layer before you touch the definition.
- Symptom: blank for everyone, on every instance. Likely cause: the report's data source doesn't match, or isn't related to, the field's business object. Check: open the field's definition and compare its business object with the report's data source.
- Symptom: blank on specific instances only. Likely cause: a related-object path with nothing on the other end, or an Extract/Lookup condition that excludes that row. Check: test the field on that exact instance in a one-row test report, then read the Condition against the instance's real data.
- Symptom: zero instead of blank, or zero where you expect a real number. Likely cause: Return Zero on Error is masking a null operand, a divide-by-zero, or a failed text-to-number conversion. Check: clear Return Zero on Error temporarily in a nonproduction tenant and see what error surfaces.
- Symptom: the default value shows instead of the expected result. Likely cause: an Evaluate Expression condition above the intended one is already matching. Check: read every condition row in order, not just the one you expect to fire.
- Symptom: correct for you, blank or zero for someone else. Likely cause: that person lacks access to one of the fields the calculation reads, including a field on a related business object. Check: compare field-level security for both users, and confirm report sharing separately from field security.
- Symptom: right value, wrong format, or it won't sort as a date. Likely cause: Format Date returns text, or a case-sensitive Format Mask letter is in the wrong case. Check: confirm the consuming field or sort expects text, and test the mask against a known date.
- Symptom: works in one tenant, blank or wrong in another. Likely cause: the two tenants' fields carry the same name but different definitions, related-object paths, or security, or a referenced value doesn't exist in the second tenant. Check: open View Calculated Field in both tenants and compare the definitions side by side, not just the names.
Related guides
If the same field behaves differently after a tenant copy, see copying Workday configuration between tenants, which covers preserving a calculated field's exact condition grid and dependencies. If the blank value shows up in a WQL query or a RaaS report rather than a native report, see RaaS, WQL and the REST API. If the calculated field drives a business process condition rule that isn't firing the way you expect, see why a condition rule isn't working.