8.4 Troubleshooting Report Data & Access Issues

Two families of problem

Sort the symptom before touching anything.

Notice that the third row looks like a data problem and is a security behavior. It is the most commonly misdiagnosed reporting issue in Workday.

Access problems: the documented resolution

Workday documents this resolution for the error "a user gets an error that they do not have access to a report field."

Root cause: the user does not belong to a security group with access to a report field used to generate the report, such as in a filter or subfilter.

Resolution:

1. Read the error message to determine which field is causing the issue.
2. Select Security > View Security from the report field's Related Actions to identify the security domains and permitted security groups. (You can also run the View Security for Securable Item report for the field.)
3. Run the View Security Groups for User report to identify which security groups the user belongs to.
4. Add the user to a security group that can already access the domain, or edit the domain security policy to include a security group that the user belongs to - and then activate.

The clause that resolves most of these tickets: such as in a filter or subfilter. A user can fail on a field that never appears in the output. When the failing field name is unfamiliar, check the report's filters and subfilters before concluding the error is spurious.

Who can create, edit, and delete

Worth restating, because access questions often reduce to these rules:

• Users with access to the Analytics Data: Report Fields and Values security domain can create a custom report.
• Creating a report requires view permission for a domain for the data source and domains for the report fields you add.
• Prompts only show the data sources and report fields you have access to.
• The report owner and users with modify access to Manage: All Custom Reports can edit and delete a custom report.
• You cannot delete a custom report definition in use anywhere, such as a worklet on a dashboard.

Data problems: analyze the definition in order

When the report runs but the data is wrong, work through the definition in the order the report itself does.

1. The data source

The data source sets the primary business object and the population. Most "missing rows" problems are here: the data source is pre-filtered more narrowly than expected. Read its description, and check whether a data source filter is applied - data source filters run before your report filters, so they bound everything downstream.

2. The filters

Then your own filters and subfilters. Points to check:

• Effective dating - filters comparing dates behave differently on effective-dated data than intuition suggests
• Boundary operators - greater-than versus greater-than-or-equal-to
• And/or grouping - parentheses control evaluation order, and a misplaced group silently widens or narrows the result
• Prompt defaults - a prompt with a default value is a filter the user did not knowingly apply

3. Related business objects

Duplicated rows or multi-value cells mean a one-to-many related business object is being used as though it were one-to-one. Resolve with Extract Single Instance, or rebuild with the other object as the primary business object.

4. Calculated fields

A blank or wrong column that comes from a calculated field is a calculated field problem. Remember that a calculated field is only as available as the fields it consumes - if the runner lacks a domain securing an underlying field, the calculated field fails for that user while working for you. That is why the same report can show a populated column for one user and a blank for another with no error.

The Custom Report Exception Audit

Run the Custom Report Exception Audit standard report to view warnings and errors for custom reports.

Workday singles out one use case: it is helpful when transferring ownership of a report to another user. You can transfer a report as long as the new owner has access to the data source - but an error appears if the new owner tries to edit the custom report without access to all of the report fields. Running this audit identifies those errors ahead of time.

Treat it as a periodic hygiene report, not only a transfer step. It surfaces reports broken by a changed calculated field, a retired field, or a security change - before a user finds them.

Reports and tasks worth knowing

A short diagnostic script

1. Does it error, or does it run? Error → access path. Runs → data path.
2. If it errors, name the field from the message, then View Security for Securable Item → View Security Groups for User → close the gap → activate → test.
3. If it runs but rows are missing, check the data source and any data source filter first, then filters, then prompt defaults.
4. If rows are duplicated, look for a one-to-many related business object.
5. If a column is blank for some users, look at the calculated field and the domains securing the fields it consumes.
6. If two users get different row counts with no error, stop looking at the report. Compare their security groups; expect a constrained group.
7. Verify with proxy in a nonproduction tenant - remembering it cannot verify scheduled output or notifications.