Workday / Guide: Report Best Practices

Objective

• To provide information about the adopted best practices for naming custom reports in Workday

Scope

• Recommended naming standards and guidelines

User

• Workday Custom Report Writers

Environment

• 1191721: Workday

Why use Standards and Best Practices?

Using standards and best practices in Workday Report Writing offers the following benefits:

• Maximizes performance of reports and dashboards
• Improves data integrity, resulting in increased confidence
• Shortens report creation time
• Increases accuracy
• Enhances the end-user experience with Workday reporting

Production will be audited on a monthly basis for adherence to the standards and governance. If your reports do not adhere to the standards and best practices outlined in this document, you will be requested to update your reports accordingly.

Before creating a Custom Report

When first building a Custom Report, you must consider:

Context of the Request	What data is being requested and who is asking?
Existing Report	Is there an existing default or config catalog report that already meets the criteria or can be used as a template for the request?
Performance	How fast does the report run? Choose an indexed data source and be mindful of built-in prompts if possible.
Security	Does the requester(s) and target audience have access to the data source?
Accuracy	What is the expected output?

Custom Report Standards

• Limit reports to no more than 50 fields
• Avoid using multiple multi-instance-related business objects when possible. These result in confusing output due to multiple blank rows
• Mark reports as temporary until you have determined you would like to use the report permanently  
• Never update or edit a Custom Report used in an Integration without an associated ticket, even if it is not in compliance with Standards & Best Practices.  Open a ticket to receive appropriate approvals as appropriate.  
• Never use a Custom Report as a template that is being used in an Integration, Report Group, Worksheet, Composite Report, Dashboard, or Embedded Analytic
• To prevent duplicating work, avoid individual-specific Custom Reports. Multi-function and utility are best practices.
• Remember to share a report you are building with “Report Administrators” in the sharing option (if you are not selecting “All Authorized Users” as the share option)

Naming Custom Reports

Custom Reports will use the following naming convention logic as detailed below by Report Type. All reports must start with the prefix MU unless they are a Sub Report, used for a Prism Base Data Set, an alert, an Integration, or otherwise stated in the Naming Custom Reports Section. MU stands for Miami University and helps all users of Workday identify a custom report.

None of the following should occur in the names of reports intended to be released in Workday:

• Underscores
• Initials
• "Copy"
• "Test"
• Names of Individual(s)

Report Naming Guidelines

Item	Guideline	Example
Abbreviations	Workday does not limit the length of report names, so it is not necessary to abbreviate. Longer, more detailed names can be very useful in communicating the purpose of a report to a user. Avoid abbreviations unless it is common practice to abbreviate a word or phrase.	IPEDS
Ampersand (&)	Spell out the word “and” instead of using an ampersand (&). NOTE: A couple of Workday customers have reported an issue with running reports in the background that contain ampersands (&) in the report name. Workday also confirmed that they have noticed an intermittent problem with ampersands that causes the solution-sharing tool to error out.
Hyphens (-)	Do not use hyphens or underscores instead of spaces between words, as it can affect the user’s ability to search for a report. It’s acceptable to use hyphens to set off part of the name or when it is part of the word.	Pre-hires by Location
Special Characters	Avoid the use of special characters or abbreviations in names to ensure search results return accurately.
Be Specific	Avoid using vague names such as “SSN Report.” Use a descriptive name to give the user an idea about what the report provides.
Title Case	Use title case (i.e., use capital letters for the principal words; do not capitalize prepositions, articles, or conjunctions).	MU – Workers by Supervisory Organization
Dashboard Override	Always override the name in dashboards to be as succinct as possible, removing MU to allow users to see the worklet title in the dashboard.	Headcount by Country

Report usage and title guidelines

Report Use	Prefix	Title Structure	Example
Used for Prism Base Data Set	PRM -	Data Source for XYZ Purpose NOTE: Prism source reports should always be “Exclude Execution Link from Search” enabled.	PRM - Locations for Mapping Stages
Sub Reports	SUB -	Description of source of report and any prefilteration NOTE: Sub reports should always be “Exclude Execution Link from Search” enabled.	SUB - Journal Lines for Company Balance Sheet with Grants
Alert Reports	ALERT -	Description of Notification and Target Audience NOTE: Alert reports should always be "Exclude Execution Link from Search" enabled and be shared in a limited capacity to minimize use outside of the alert.
Scheduled Reports (Not Intended for Interface Use)	SCH -	If it refers to a metric it needs to abide by the metric established by the Organization. Any report with Headcount in the name should be filtered for that exact population that matches the data dictionary.	SCH - Hires in the Past Week
Report as a Service	RAAS -	Metric(s) by Dimension(s)/Time Period Used for Row Grouping and Dimension(s)/Time Period Used for Column Grouping	RAAS - Employee Job Allocation
Custom Report	MU (Prefix)	Metric(s) by Dimension(s)/Time Period Used for Row Grouping and Dimension(s)/Time Period Used for Column Grouping	MU Count of Terminations by Supervisory Organization and Fiscal Quarter

Hide reports from search

Custom reports should be hidden under the following conditions:

• Sub Reports
• Reports built to support Dashboards that are redundant
• Drill-to Reports
• Scorecards
• Integration-owned Reports
• Prism source Reports
• RaaS Reports

Standard Drill-to Details Data Sources

When developing a Matrix, Trended, or SUB report, these are the standard drill-to details in this specific order that you would want to ensure are included.

• Workers for HCM Reporting
• Trended Worker
• Job Application
• Job Requisition
• Staffing Events for HCM Reporting (Movement Out)
• Staffing Events for HCM Reporting (Movement In)
• Staffing Events for HCM Reporting (Movement In-between)
• Positions for HCM Reporting
• Journal Lines for Financial Reporting
• Plan Lines for Financial Reporting

Enable Save Parameters

Every custom report containing prompts should have Enable Save Parameters checked. This enables users to save their favorite prompt parameters for reuse.

Report tag guidelines

Each custom report MUST be assigned one or more functional report tags based on the General Area. Refer to the functional report tags listed in the following table.

General Area	Functional Report Tags
HCM (Human Capital Management)	Absence
	Benefits
	Career Development
	Compensation
	Recruiting
	Time Tacking
	Workforce
PAY (Payroll)	Payroll
FIN/SCM	Banking and Settlement
	Budget
	Business Assets
	Endowments
	Financial Accounting
	Financial Reporting
	Grants Management
	Inventory Management
	Payroll Accounting
	Procurement
	Projects
	Revenue Analysis
	Spend Analysis
	Supplier Accounts
STUDENT	Academic Advising
	Academic Foundation
	Admissions
	Curriculum Management
	Financial Aid
	Student Core
	Student Finance
	Student Records
	Student Recruiting
TECHNICAL	BIRT
	Business Process Administration
	Data Audit
	Needs Updating
	Report Administration
	Scheduled Report
	Security Administration
	RAAS
	WIP
COM	Compliance
	Regulatory
USAGE	Usage: Sub Reports
	Usage: Custom Menu
	Usage: Dashboards
	Usage: Integrations
	Usage: Workbook

Best Practices for report descriptions

Each custom report should contain the following elements in the "Brief Description" and "More Info" sections.

 

Brief Description

Shows users a short synopsis below the report title in search results. Assists users in identifying the appropriate report to run for their use case. This is located on the output tab of the report creation under the Help Text section.

Topic	Description	Example
Use Case	As briefly as possible, describe what the report does and why.	This advanced report enables time tracking administrators to identify workers who have unsubmitted time and returns 1 row per worker.
Built-in Filters	Notate data that would be excluded from the results.	The report uses the Indexed All Workers report data source and the Workers With Unsubmitted Time data source filter Required prompts: Start Date, End Date, and Time Period to automatically filter report results. If you enter all 3 prompts, the report data source filters results by Time Period only.

 

More Info

After a report is run, the More Info explains the returned data as the user views it. This is located on the output tab of the report creation under the Help Text section.

Topic	Description	Example
Data Source	Mention the data source(s) on which the report is built. If the data source is a Prism data source, a note MUST be added here that the data is refreshed daily and is not live data. NOTE: When you are using Trended Worker and Completed Staffing Events for HCM Reporting data sources, include the following to assist users in tying out data between the two. "This report is built on Completed Staffing Events for HCM Reporting" and will return terminations for all employee types, including future effective dated events. Leave the Defaulted Prompts (End Date, Employee Type) to tie out to reports built on the "Trended Workers" data source. Keep in mind reports built off of "Trended Workers" only return a rolling 36 months of data." The Defaulted Prompts should be End Date = Last Day of This Month and Employee Type = International Fixed Term, PEO, and Regular.	Built on Data Source: All Custom Reports. It excludes custom reports owned by Integration Systems. Description Status counts the character length of report description and buckets 0-1 characters as "Empty." 2-50 as "Insufficient," and 51+ characters as “Present." Optional Prompts: Report Owner
Built-in Filters	Notate data that would be excluded from the results.
Metric Logic	Describe any metric logic, like turnover rate, or evaluate expression bands.
Prompts	This is optional to include in the More Info section: List all prompts according to their status of required or optional.

Schedule Reports

• Scheduling reports should always be optimized to limit excessive data in some way (i.e. Effective date prompts for a report on hires). A good practice is to limit the schedule transaction reports to the frequency that it is scheduled
  • Example: A report scheduled for every Monday should pull data only for the time that has transpired since the last scheduled date
• Sharing scheduled reports with others should be rigorously scrutinized to prevent circumvention of security unless pre-authorized
• All scheduled reports should be set to end on July 1 of the following calendar year. 

Calculated Field Standards

Calculated Fields must align with best practice standards and will be audited for adherence to the following:

• The proper Naming standard followed
• The description of the Calculated Field is complete
• Always check for an existing Calculated Field before building to limit duplication
• Never update or edit a Calculated Field used in an Integration without an associated ticket, even if it is not in compliance with Standards & Best Practices.  Open a ticket to receive appropriate approvals as appropriate.  
• Report Writers can only create Report Specific Calculated Fields
  • Requests can be made to make a report-specific calculated field into a system-wide field through a Workday Support Ticket

Consider securing calculated fields using the following domains.

• Custom Field Management - allows the user to create system-wide calculated fields and would be granted to members of the reporting team
• Private Calculated Field Management - Limits users to create only report-specific calculated fields and would be granted to non-reporting team users
• Convert Calculated Field - This task allows conversion of calculated fields between categories (i.e. report specific to system-wide or vice-versa) and appears to be automatically granted when a member of both of the first two domains is shown above. A process should be put in place for non-reporting team members to request that report-specific calculated fields be converted to system-wide

Calculated Field Standards

Filters and Prompts

Filters and Sub-filters

• Use report data source filters whenever possible (they show up as prompts when you create a report) to filter data. RDS filters are optimized for better and faster search
• With multiple filters, start by adding the filter that narrows down the search most effectively. For when your report needs to return all new hires entered last week and your data source includes all business process types, your first filter should be Business Process Type – in the selection list – Hire, followed by Date and Time Completed date range filters
• To turn filters into prompt fields that users complete when they run the report, use:
  • “Prompt the user for the value” – for required prompts and remember to mark them required on the Prompts tab
  • “Prompt the user for the value and ignore the filter condition if the value is blank” – for optional prompts
• For filters connected to date prompts, you can select:
  • “Value from another field” – more appropriate if you wish to use the same prompt field for several conditions
  • “Prompt the user for the value…” – better for separate prompts
• When using both filters and subfilters, consider including a condition on the filter: subfilter business object(s) “is not empty” to avoid partially empty lines on the report where filter and subfilter conditions don’t overlap
  • E.g. Benefit Changes report has no filter but has a subfilter to show changes for medical and dental plans that happened in a specified time period. When run, the report returns blank rows for all employees in Workday except the ones who had benefit changes in a period. For those, the report shows new medical and dental plan election details. After adding the “Benefit Changes – is not empty” condition on the filter, the report returns only the employees who had a change in the period

 

Prompts

• Arrange prompts in the best logical order. Keep required prompts at the top and date range prompts grouped
• Include detailed Prompt Instructions in cases where prompts are not self-explanatory
• Be sure to explain if some prompt values do not apply to specific cases and should not be used
• If a prompt is required by the data source, Workday automatically marks it with an asterisk and enforces the requirement
• With custom prompts, report writers must check the “Required” box on the Prompts tab for each prompt where they select “Prompt the user for the value” on (sub) filters
• Data source-specific optional prompts can be made required by using the “Required” check box, but required prompts cannot be converted to optional
• Pre-defined prompts often make the user experience better. If you know that users will be running a report for specific dates or the same organization, put those values as default prompts
• For prompts where users can select more than one value, indicate this in the prompt labor by adding (s) as the end
• In date and time prompts, the “time” part (hh:mm:ss) is optional. Be advised that once the report is run, it defaults to 12:00 am of the data selected
• To view data as of a particular moment in time, add Effective Date > Prompt for Effective as of Date (and Time) prompt. It is optional and defaults to blank
• If a report data source does not include an “Organization and Subordinates” prompt, you can still add it at the filter level

Delete and Archive

Reports that are no longer needed should be archived before being deleted from the system. Archived reports will be reviewed on a semi-annual basis for permanent deletion.

To archive a report:

• Add *-ARCHIVE to the start of the name of the report.
• Add to the comments section the date, requester, and reason for Archiving
• Remove all shared users and groups except for “Report Administrator”

Project-related and temporary reports do not need to go through the archival process and may be removed from the system at any time using the “Delete” action off the report.

******** Purge of temporary reports - TBD*********

Development Cycle

Peer Review

Have another developer perform a peer review of the report to verify the report follows the standards outlined in this document. The peer reviewer should also compare the report specifications to the report results and perform some basic validation. Ideally, this should happen before the report is sent to a user for testing, but if that is not possible it should happen before the report is moved into a Production state. It is an opportunity to have the report proofed by a fresh set of eyes to ensure it meets the standards outlined in this document.

 

Development Cycle for New Reports

1. The developer works with the user to create a report specification and requirements document
2. The developer develops the report and tags as WIP
3. Before the report is sent to the user to test, the developer works with a peer to review the report definition and ensures it follows the standards outlined in this document. The developer makes any changes as needed
4. When the report is ready for testing, the developer:
   1. The developer will remove WIP report tag
   2. Updates the report request ticket for promotion to sandbox
   3. Notifies the user
5. The user tests and signs off on the report
   • NOTE: At this point, the user may have requested changes to the report that require the report to be revised. Be sure the name and description reflect changes
6. If user approval is given, the developer will update the ticket for promotion to production
7. The developer notifies the user that the report is available in a Production status

 

Development Cycle for Updating a Report

1. Begin with the version in Sandbox-Preview. If report does not exist, have it demoted from Sandbox
2. The developer will add WIP report tag while making updates
3. The developer will make requested changes
4. The developer will add information to the comments section of the report definition in the following format. Always put the newest updates at the top of the section
   • Date - UniqueID - What changes were made
   • Example: 11/11/2024 - gollas - Created a calculated shift date column. Changed the prompts to use the new shift date column. Updated the name to reflect it's expanded usage
5. When the report is ready for testing, the developer:
   1. The developer removes the WIP report tag and share with the proper groups
   2. Updates the report request ticket for promotion to sandbox
   3. Notifies the user
6. The user tests and signs off on the report
   • NOTE: At this point, the user may have requested changes to the report that require the report to be revised. Be sure the name and description reflect changes.
7. If user approval is given, the developer will update the ticket for promotion to production
8. The developer notifies the user that the report is available in a Production status