8.2 Configuring & Testing Alerts

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.

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:

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:

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:

1. 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.
2. Configure the alert with a short frequency and a narrow recipient - yourself, or a test security group - in a nonproduction tenant.
3. Check Process Monitor for the status of the run.
4. Confirm delivery and read the rendered Subject and Body, checking that field references resolved to values rather than blanks.
5. Test the negative case. Adjust data so the report returns nothing and confirm no notification is sent.
6. 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.