14.2 Building Custom Reports: Index vs Standard

14.2 Building Custom Reports: Index vs Standard

Quick Summary: Build Custom Reports by copying delivered definitions when close, or by creating a custom report with an intentional data source. Prefer Index data sources for high-volume, performance-sensitive reporting; use Standard data sources when you need flexible, object-centric field paths. Add columns from the primary business object and related BOs, and enable RaaS when systems must call the report as a web service.

Tasks T58, T59, and T60 sit at the center of Report Writer Fundamentals. After T57's copy-and-columns skill, the exam expects you to create custom reports thoughtfully: pick the right starting point, choose Index vs Standard, assemble fields across the data model, and know when web service enablement matters.

Creating a Custom Report (T58)

"Create a custom report by starting with or copying a delivered report" is deliberate wording. Two valid starts:

Create Custom Report high-level steps

1. Launch Create Custom Report (or copy a delivered report if that is the better start).
2. Name the report with a clear tenant convention.
3. Select report type (for example Advanced for flexible lists; Matrix when you need summarized row×column layouts—Matrix detail is expanded in Advanced Reporting).
4. Select the data source (Index vs Standard decision below).
5. Optionally set data source filters that permanently constrain the population.
6. Add columns (fields from primary and related objects).
7. Configure sort, filters, and prompts (section 14.3).
8. Configure sharing / security design (section 14.4).
9. Enable as web service only if integrations need RaaS.
10. Save, test as yourself and as a representative runner, then promote through your change process.

Exam trap: Creating a custom report is not writing SQL against the tenant database. Workday Report Writer is metadata-driven over data sources and business objects.

Index vs Standard Data Sources (T59) — Exam-Critical

Every custom report binds to a data source. For HCM Core Report Writer, master the contrast between Index and Standard data sources.

Definition pair to memorize:

• Index data sources = pre-built, optimized, denormalized structures for faster reporting on large datasets (example language: Worker Index style sources).
• Standard data sources = pull directly from a business object and its related objects, offering more flexibility but potentially slower performance on large tenants.

Exam trap A: "Standard is always faster than Index." → False. Index is generally the performance-oriented choice for large volumes.

Exam trap B: "Index requires a paid add-on license." → False in standard Core exam language—do not invent licensing gates.

Exam trap C: "There is no difference." → False. Structure, flexibility, and performance differ.

Need high volume + speed?  --> prefer Index data source
Need flexible BO paths?   --> Standard data source (or Index if fields exist there)
Unsure?                   --> Check whether a delivered report already solved it (copy)

Configuration scenario: Global Retail must extract 120,000 worker rows nightly for a workforce analytics mart. The author chooses an Index worker-oriented data source for performance, limits columns to required fields, and enables RaaS for the integration ISU. A second report for a 40-person HRIS team that must traverse unusual related objects for a one-off audit may use a Standard data source where those paths are clearer—even if slightly slower—because flexibility matters more than bulk speed.

Fields from Business Objects and Related BOs (T60 part 1)

Report columns are not free-form Excel headers. They are fields on the primary business object of the data source or on related business objects reachable through Workday's data model.

Recall from HCM Fundamentals:

• A business object is an entity type (Worker, Position, Supervisory Organization, Job Profile, Location…).
• Fields store values on an instance.
• Related business objects link instances so reports can hop (Worker → Position → Job Profile → management level).

Practical field-add rules

1. Confirm the primary object of the data source matches the grain of the question (one row per worker vs per position).
2. Add direct fields first (Employee ID, Preferred Name).
3. Use related business object field pickers for attributes that live one or more hops away.
4. Avoid unnecessary hops—each related-object traversal can cost performance (deepened under T69).
5. Prefer fields already denormalized on an Index source when performance is critical and the field exists there.

Configuration scenario: "Show each worker's Job Profile and Location." On a worker report, add Job Profile and Location via related object paths (or index fields that already expose them). Do not create a second report solely for Job Profile unless the grain must be one row per profile.

Exam trap: Believing Report Writer can invent a column with no path from the data source's objects. If the field is not on the primary or related BOs available to that source, you need a different source, a calculated field (later chapter), or a different report grain.

Enable as Web Service — RaaS (T60 part 2)

Report as a Service (RaaS) means enabling a Custom Report so external systems can consume its output through a SOAP/REST web service endpoint. This is a common Workday integration pattern for outbound extracts and system-to-system feeds.

Configuration scenario: Contoso's middleware must pull active worker IDs and emails every hour. HRIS builds an Advanced custom report on an Index data source with only those columns, enables the report as a web service, documents the endpoint, and grants the Integration System Security Group Get on the domains securing those data elements. The ISU authenticates and calls RaaS; humans may still run the same report in the UI if shared.

Exam traps for RaaS:

• "RaaS runs without any security" → False.
• "RaaS writes data back into Workday" → False (read/consume output).
• "RaaS bypasses all filters" → False.

Putting T58–T60 Together: Design Checklist

Use this checklist when a stem describes building a custom report:

1. Start: Copy delivered if close; else Create Custom Report.
2. Type: Advanced for lists; Matrix when summarization/drill is the goal (Matrix depth in ch. 15).
3. Data source: Index for large/fast; Standard for flexible BO/related-field access.
4. Columns: Primary BO fields + related BO fields only along real relationships.
5. Minimize hops and columns for performance-sensitive extracts.
6. RaaS: Enable only if programmatic consumption is required; pair with domain Get for the ISU.
7. Share and test under a real runner's security (next sections).

Side-by-Side: Copy Path vs Create Path

Common Exam Scenarios

Scenario 1 — Index vs Standard definition. Question asks the difference → Index = optimized denormalized/pre-built for large data speed; Standard = direct BO + related objects, more flexible.

Scenario 2 — Performance. Large tenant, nightly extract → lean toward Index, fewer related hops, fewer columns.

Scenario 3 — Flexibility. Need obscure related fields not on the index → Standard (or a different source that exposes them).

Scenario 4 — Integration. "External system must consume report output" → enable RaaS + domain Get for ISU.

Scenario 5 — Fields. "Add manager name to worker report" → related BO field path from worker, not a new staffing model.

Master Index vs Standard and RaaS security before memorizing every delivered data source name. Under exam timing, vocabulary and design intent score the points.