8.2 Configuring & Testing Alerts

Workday Pro Platform Administrator Certification Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The Workday Platform

1.1 Workday Products, Functional Areas & Product Touchpoints 1.2 The Object Management Model & Business Objects 1.3 Navigation & Search Techniques 1.4 Organizations in Workday

2 Chapter 2: Tenants & Release Management

2.1 Tenant Types & Tenant Management Tasks 2.2 Releases, Adoption, System Testing & Support

3 Chapter 3: The Configurable Security Framework

3.1 Components of the Configurable Security Framework 3.2 Core Security Group Types: Workday-Assigned, User-Based & Role-Based 3.3 Advanced Security Group Types

4 Chapter 4: Security Policies, Assignment & Troubleshooting

4.1 Domain Security Policies & Permissions 4.2 Assigning Roles & Security Group Membership 4.3 Troubleshooting Security Access Issues

5 Chapter 5: Business Process Definitions & Steps

5.1 The Business Process Framework & Definitions 5.2 Business Process Step Types 5.3 Step Configuration, Order & the Completion Step

6 Chapter 6: BP Security, Condition Rules & Troubleshooting

6.1 Business Process Security Policies 6.2 Creating & Testing Condition Rules 6.3 Using Reports to Troubleshoot Business Processes

7 Chapter 7: Report Foundations & Custom Reports

7.1 Business Objects, Fields, Related Business Objects & Data Sources 7.2 Standard Reports, Custom Report Types & the Report Writer 7.3 Worklets, Dashboards & Sharing Reports

8 Chapter 8: Calculated Fields, Alerts & Report Administration

8.1 Identifying & Maintaining Calculated Fields 8.2 Configuring & Testing Alerts 8.3 Scheduling Reports, Report Groups & Transferring Ownership 8.4 Troubleshooting Report Data & Access Issues

9 Chapter 9: Integration Architecture & Security

9.1 Workday Integration Architecture & Web Services 9.2 Workday Integration Tools & Choosing the Right One 9.3 Integration System Users & Integration System Security Groups

10 Chapter 10: Enterprise Interface Builders

10.1 Creating & Launching an Inbound EIB 10.2 Creating & Launching an Outbound EIB 10.3 Troubleshooting EIB Data Loads & Access Issues

8.2 Configuring & Testing Alerts

Key Takeaways Explain This Topic AI

Alerts notify users based on the results of a report, independent of a business process.

The filter criteria in the underlying custom report define the conditions for the alert, so the report is where the logic lives.

The Configure Alert task requires a report and a frequency, and alerts can be one-time or recurring.

The Notification Alerts security domain secures the Configure Alert task, and the Process Monitor report shows the status of configured alerts.

Workday generates a notification for each instance of the underlying report output and groups notifications by recipient when there is more than one instance per recipient.

Last updated: August 2026

What an alert is

An alert notifies users based on the results of a report, independent of a business process . That last clause is the definition's most important part and the exam's favorite distinction.

Notification Alert
Triggered by A business process - a status change, or entry to or exit from a step The results of a report

Configured on The Notifications tab of a business process definition The Configure Alert task, against a custom report

Answers "This event moved" "These records match criteria"

If the requirement is "tell someone when this event reaches this step," that is a business process notification. If it is "tell someone when records look like this," that is an alert. Alerts are how you monitor a state rather than an event - and there is no business process for "a credit card transaction has no expense report."

Workday's own examples of alert use cases:

Exceptions , such as credit card transactions with no expense reports
Birthday and employment anniversary reminders to managers
Time off reminders to a team
The report carries the logic

The filter criteria in the custom report define the conditions by which you want to alert.

This is the single most important operational fact about alerts. An alert does not have its own logic engine. It runs a report on a schedule and notifies people about the rows that come back. If the alert fires too often, too rarely, or about the wrong records, fix the report's filters - not the alert configuration.

It follows that the design sequence is always: 1. Build a custom report whose FILTERS define the condition
2. Verify the report returns exactly the rows you want to alert on
3. Configure Alert on that report → recipients, message, schedule
4. Monitor with Process Monitor; review with View Alerts

The three objects involved:

Task or report Role
Create Custom Report Filter criteria define the conditions for the alert
Configure Alert Include recipients, message, and schedule
Process Monitor Shows the status of configured reports
Configuring the alert

The Configure Alert task requires you to define the report and the frequency . Alerts can be one-time or recurring .

Alert configuration lets you specify:

Report Parameters , if the report has prompts
Include Tasks (optional) - surface actionable tasks alongside the notification

Configure Recipients :

Recipients using available fields for context from the report - for example Worker or Project Manager . This is the powerful option: the recipient is derived per row from the report's own data, so each manager is notified about their own people.

Security Groups - for example HR Administrator or Security Administrator, when a fixed audience should see everything

Subject and Body of the notification, using static text or fields from the report

The configuration tabs:

Tab Contents
Alert Configuration Recipients, Subject, and Body - the message itself
Schedule How often the process runs and the range of recurrence, with a Start and End Date
Additional Info Other details, such as who created the alert
How notifications are generated

Workday generates a notification for each instance of the underlying report output, and groups notifications by recipient if there is more than one instance per recipient.

Two consequences worth internalizing.

First, volume is driven by row count . A report returning 4,000 rows generates notifications for 4,000 instances. Grouping by recipient softens the effect - a manager with eight matching workers gets one grouped notification, not eight - but a poorly filtered report is still the fastest way to make an alert unwelcome.

Second, using a field-based recipient scales the audience automatically . Setting the recipient to the Worker or the worker's manager means every manager receives only their own rows, from one alert definition.

Security

The Notification Alerts security domain secures the Configure Alert task. A user who cannot find Configure Alert is missing that domain - use the standard method from section 4.3: View Security for Securable Item on the task, then View Security Groups for User .

Separately, the recipient's own security governs what they can do with the data in the notification. The alert delivers a message; it does not grant access.

The delivered birthday example

Workday's canonical example is worth knowing because it demonstrates the copy-first pattern.

Two standard Workday-delivered reports drive the delivered birthday and anniversary alerts. To use these alerts, copy each associated report to a custom report and use the copy for the alert configuration. For example, use the Birthdays for this week and next report in an alert that executes once a week to notify managers of upcoming birthdays. The Recipients section identifies the manager; the Subject and Body carry introductory text plus the worker name and birth date, so the manager can see whose birthday is coming and exactly when.

The pattern generalizes: you cannot configure an alert directly on a delivered standard report. Copy it to a custom report first , then configure the alert on the copy. This is a frequent exam distractor.

Managing and testing alerts

Once scheduled, you can View Alerts and edit the details like any other scheduled process. The View Alerts report shows all existing alerts, including the Run Frequency and the Status - the right starting point for an audit of what a tenant is sending.

A practical test sequence:

Run the report interactively first and confirm the row set is exactly what should trigger the alert. This is where nearly all alert defects live.

Configure the alert with a short frequency and a narrow recipient - yourself, or a test security group - in a nonproduction tenant.

Check Process Monitor for the status of the run.

Confirm delivery and read the rendered Subject and Body, checking that field references resolved to values rather than blanks.

Test the negative case. Adjust data so the report returns nothing and confirm no notification is sent.

Widen the recipients and move to the intended frequency only after both cases behave.

Remember from section 1.3: proxy sessions cannot receive notifications. You cannot verify alert delivery by proxying in as the recipient - you must use a real account or make yourself the recipient.