Every business object already has a report data source

When an Extend app is deployed, Workday creates a report data source for each business object and attachment object in it. The data source's name is the label of the object's defaultCollection, which is why Workday recommends labels such as "All Equipment Requests" (Reference: Model Component Attributes). Its WQL alias is derived from the app's Reference ID and the name of the defaultCollection, so a WQL query must use that generated alias, not the label.

To find both, open the Workday Extend App Manager worklet in the tenant and select the app. It lists each data source, the report fields created for each business object, and each field's web service alias and WQL alias (Concept: Create Custom Reports Using Business Object Data). Once you pick a data source, any report field created on the business object is available in the custom report.

Two kinds of report: authored in the app, or built in the tenant

App reports are .report model components you author in App Builder. They are standard reports of the Advanced type, travel with the app to every tenant it is deployed to, are secured by one or more of the app's domains, and can use regular and derived fields of one business object or attachment (Concept: Reports). Their definition has columns and sort order only:

{
  "id": 1,
  "name": "OpenEquipmentRequests",
  "label": "Open Equipment Requests",
  "businessObject": "EquipmentRequest",
  "defaultSecurityDomains": ["ManageEquipmentRequests"],
  "sortConfigs": [
    { "id": 1, "order": "a", "field": "requestedDate", "direction": "DESCENDING" }
  ],
  "columns": [
    { "id": 1, "name": "Request", "order": "a", "isSelfReferencing": true },
    { "id": 2, "name": "Requester", "order": "b", "field": "requester" },
    { "id": 3, "name": "Cost Center", "order": "c", "field": "costCenter" },
    { "id": 4, "name": "Amount", "order": "d", "field": "amount" }
  ]
}

isSelfReferencing adds a column holding the instance itself, which gives users a link to the record. Users find the report in search by its label (Add Reports). An app can hold 10 reports.

Custom reports are built with Create Custom Report in the tenant, on the business object's data source. This is where you add filters, including filters populated from prompts, and anything beyond the app report's columns and sort order. You can start one from scratch or copy an app report into a custom report and extend it. The trade-off is that a custom report is configuration in that tenant, whereas an app report is native to the app; Workday's docs don't describe custom reports moving with the app, so treat them as tenant content.

Make the Extend object the primary data source

You cannot start a report on a Workday-delivered object such as Worker and traverse to an Extend object that references it. Workday documents that the Extend object's data source must be the primary data source, and you reach the delivered object through the field that targets it (Reference: Reporting and Object Dating Restrictions). A report of workers who have Equipment Requests is built on "All Equipment Requests", with Requester as a related business object.

There is one way to go the other direction. Set "enableReportingFromTarget": true on a SINGLE_INSTANCE field that targets WORKER, and Workday generates a report field named in the form Equipment Request - Requester (app reference ID) that returns all related instances for the worker in context. The Extend object then appears as a related business object from Worker, and the field can be used in calculated fields, condition rules and business process alerts and notifications (Two-Way Visibility). The limits: 5 such fields per app, and these fields don't support field-level security.

Extend business objects are not effective dated. Workday's docs say to report on values for a given date with an object that stores a dated transaction log of changes to the business object, so build one in the model if you need history.

Filters that perform: index the fields

Every SINGLE_INSTANCE field is indexed automatically. You can index up to 5 other fields per business object or attachment with "enableIndex": true. Derived fields and MULTI_INSTANCE fields cannot be indexed, and a field can be indexed only if the object's default security domains secure it (Reference: Model Component Attributes). Workday lists custom report filters, REST query parameters and the WQL WHERE clause as what indexed fields speed up (Example: Query Parameters in Business Object API Requests).

So before data volumes grow, decide which non-reference fields your reports will filter on, such as a status TEXT field or a requestedDate, and index them in the model.

Prompts that let users pick an Extend instance

A custom report prompt that should offer a list of Extend instances (pick an Equipment Request, pick a Charity) needs the target object to be searchable. Per Concept: Reports:

  1. On the target business object, set "enableSearch": true and "enableIndex": true on one TEXT field. That field's values are what the prompt shows.
  2. In the custom report, filter on a SINGLE_INSTANCE field that targets that object, and populate the filter from a prompt.

The prompt shows search-enabled values for up to 500 instances; beyond that, users type ahead to narrow the list. An app can enable search on 3 TEXT fields in total. Turn enableSearch on before loading data: the field's values must be unique, and a deployment that adds it to a field with duplicate values fails (Reference: Model Component Attributes). The same attribute is what makes an Extend object usable in a Discovery Board filter.

Prompts on ordinary fields, such as a date range or a cost center, need nothing special; they behave as on any data source.

Putting a report on a dashboard

For a report worklet, open the custom report's Output tab and use Enable as Worklet, choosing the dashboards or landing pages in Available On. The report must also be shared with the security groups that use the dashboard, or the worklet is empty for them (Set Up Output Options for Custom Reports).

On Analytics Dashboards, prompt mapping lets one dashboard prompt filter several visualization cards whose reports expose the same prompt field, and single- and multi-instance prompts are supported. Every undefined prompt default on the underlying report must be populated before the report can be added as a card, and each card's query times out after 45 seconds (Concept: Analytics Dashboards). Give the Extend report default prompt values, and keep its filters on indexed fields; that is a recommendation, since the docs don't tie the two together.

Adding the app's own pages to menus and dashboards is a separate job, covered in adding an Extend app to the Workday menu and dashboards.

Why a report shows no rows for some users

Access to the rows comes from the business object's domain security policy, and where a SINGLE_INSTANCE field sets "secureByTarget": true, only instances the user is contextually secured to view are returned (Example: Query Parameters in Business Object API Requests). A report that returns rows for the developer and none for a manager should be checked against those two first; the mechanics are in secureByTarget and Extend security domains, and the general report checks in report sharing and security.

How to prove the report is right

Compare the report with the API, as the same user. Run the report as a user in the domain, then call GET /apps/{appId}/v1/equipmentRequests with the same filter as a query parameter (or the equivalent WQL against the alias) and check that the counts match. Then run it as a user who should see only part of the data, such as a manager scoped by cost center, and confirm the row count drops to what that user is allowed to see. If the counts match for the developer but not for the manager, the report is fine and the security model is doing the filtering.

Sources checked