Guide: Workday / Custom report naming

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.

Failure to adhere to standards and best practices may result in loss of Workday Report Writer privileges.

Before creating a Custom Report

When first building a Custom Report, you must consider:

Custom Report Standards

• Please 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, even if it is not in compliance with Standards & Best Practices
• Never use a Custom Report used in an Integration in a Report Group, Worksheet, Composite Report, Dashboard, or Embedded Analytic
• To prevent duplicating work, avoid individual-specific Custom Reports. (If the individual(s) leaves, the others are unable to access the report)
• 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.

Absolutely 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
WIP	Use the prefix WIP (work in progress) to denote a report that is under development. Remove the prefix when the report is final, shared with security roles, and ready to be migrated to Production.	WIP Turnover Rate by Supervisory Organization and Month
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	PRSM -	Data Source for XYZ Purpose NOTE: Prism source reports should always be “Excluded Execution Link from Search” enabled.	PRSM - Locations for Mapping Stages
Sub Reports	SUB -	Data Source Filter NOTE: Subreports should always be “Excluded Execution Link from Search” enabled.
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
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

Hiding reports from search

Custom reports should be shared and hidden under the following conditions:

• Sub Reports
• Reports built to support Dashboards that are redundant
• Drill-to Reports
• Scorecards
• Integration-owned 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 should 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
	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
	Admissions
	Curriculum Management
	Financial Aid
	Student Finance
	Student Records
	Student Recruiting
TECHNICAL	BIRT
	Business Process Administration
	Data Audit
	Needs Updating
	Report Administration
	Security Administration
COM	Compliance
	Regulatory

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.	Shows the count and percent of all custom reports according to their Description Status to help identify reports that need to be updated. It excludes custom reports owned by Integration Systems.
Built-in Filters	Notate data that would be excluded from the results.	Shows the count and percent of all custom reports according to their Description Status to help identify reports that need to be updated. It excludes custom reports owned by Integration Systems.

 

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.

Scheduling Reports

• Scheduling reports should always limit the datain 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 end at the same time, typically the end of the year, so that the data governance team can re-evaluate all scheduled reports for review and removal
• Schedules are not multi-year. Schedules expire after one year

Calculated Field Standards

Calculated Fields must align with standards and should be audited for adherence to the following:

• Naming
• Description
• Usage
• Always check for an existing Calculated Field before building
• Never use a Calculated field used in an Integration in a Custom Report
• Never update or edit a Calculated Field if it is used in an Integration, even if it is not in compliance with Standard & Best Practices
• 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 (this process needs to be created)

Calculated Field Standards

Filters and Prompts

Filters and Subfilters

• 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. The Report Governance Committee will be reviewing the list of archived reports on a semi-annual basis to permanently delete unnecessary reports.

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

1. The developer works with the user to create a report specification
2. The developer creates the report
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. Notifies the user
   2. Updates the report request ticket
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. The developer removes the WIP tag and shares the report with the proper groups
7. The developer notifies the user that the report is available in a Production status

Securing Calculated Fields

REVIEW OF THIS AREA - SECURITY

Reporting developers can create system-wide calculated fields. However, as additional users request access to write their own reports the risk of accidental modifications to calculated fields will increase. A user with Report Writer access has the potential to modify a calculated field used elsewhere and cause problems on reports downstream.
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 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