Read time: 10 minutes

Hey there! You’ve got a whole lotta data in Workday, right? You’re sitting on a goldmine of insight into your workforce and organization. However…

Data without action is useless 😵‍💫

The first step to making your data useful is to share it with the right people.

In Workday, alerts do just that.

Alerts allow you to send dynamic notifications based on custom report data. With alerts, you can do things like…

🥵 Prevent burnout by notifying managers when their employees haven’t taken a vacation in a while.

🚩 Keep your tenant tidy and compliant by flagging incorrectly named custom reports, calc fields, etc., for cleanup.

🥳 Boost morale by telling employees when their teammates have a birthday or work anniversary coming up.

Thanks to the flexibility of custom reports, the use cases for alerts are truly endless.

In today’s newsletter, I’m sharing a step-by-step alert configuration guide!

Let’s dive right in, shall we? 🌊

Like any well built initiative, before we build, we plan! As you define your alert, consider…

Why are you building this alert?

Who will receive the alert?

What is the alert about?

How often will the alert be sent?

When will the alert be sent?

In today’s example, our goal is to prevent burnout (why) by notifying an employee (who) when they haven’t taken vacation for more than 6 months (what). The alert will fire once a month (how often) on the first Monday of each month at 8am PT (when).

🚨 Complete steps 2 - 5 in a test environment first!

Every alert is built on a custom report. One custom report can drive multiple alerts, but every alert is built on just one custom report.

Your “what” from step 1 should tell you everything you need to know about what data your custom report needs to include. In today’s example, our custom report needs to return employees who have taken 0 vacation time off within the last 6 months, as of when the alert fires.

You’ll create this custom report just as you would any other, with one exception—alerts don’t support the Filter on Aggregations or Subfilter features, so leave these blank:

Run the task, “Create Custom Report”.

Report Name: Name the report something along the lines of “Alert - Employees Who Haven't Taken Vacation in 6 Months”. When you create custom reports that will drive alerts, best practice is add an “Alert - “ prefix to the report name.

Report Type: Create an Advanced report. Both Simple and Advanced reports can drive alerts, but a Simple report’s functionality is limited (you can’t add related business objects or prompts).

Data Source: Your Data Source’s Primary Business Object (PBO) is the topic of your alert. In this example, the topic of our alert is worker. We’ll select the “Workers for HCM Reporting” Data Source, which has a PBO of Worker. Since we’ll be using a calculated field in the report Filter later on, leave “Optimized for Performance” unchecked. When checked, this setting limits your Filter to indexed fields.

Let’s first consider our Filter and Prompts. We want to narrow the report results to employees who have taken 0 vacation time off within the last 6 months. To accomplish this, we’ll build the calculated field below for our Filter:

We won’t get into the calculation details here, but you can check out our True False Condition and Sum Related Instances calculated field tutorials to learn more about these field types 😊

This field sums a worker’s approved vacation time off that occurred within Prompt Dates 1 and 2. Using prompts here makes your field and custom report more dynamic!

Configure your Filter like this:

And configure your Prompts like this:

You can hardcode Default Values into your report prompts and mark them as “Do Not Prompt at Runtime”, or you can configure the prompts within your alert settings. We’ll come back to this in a bit!

Your custom report drives your alert on the backend (i.e., your report isn’t visible within your alert). For your alert to run successfully, your report only needs one field on the PBO on the Columns tab.

Check out Example A and B below. Both of these Columns setups can produce the same alert. The fields you include as columns on your report don’t affect the contents of your alert. The contents of your alert are set up on the alert itself in a later step.

Sure, your report doesn’t need a bunch of fields. However, as you build your report, I recommend adding relevant fields to check for accuracy. For example:

Then run the report to test:

Looks great! 😎 There are just two employees who have used 0 vacation within the last 6 months. We can expect our alert to generate 2 notifications—one to Spongebob and one to Squidward.

Run the task, “Configure Alert”. Select your report, and choose a Run Frequency. For our example, we’ll choose a Monthly Recurrence.

This is typically your report name without the “Alert - “ prefix, however, you can make minor adjustments as needed. We’ll set our Request Name to “Notify Worker - Employees Who Haven't Taken Vacation in 6 Months” (we’ll build “Notify Manager - Employees Who Haven't Taken Vacation in 6 Months” next week 😉).

Notification Type determines how (email, mobile push, etc.) and on what frequency (daily, immediately, muted) your notifications are delivered. These settings are tucked away within the “Edit Tenant Setup - Notifications” task. You can keep most alerts set to “General Notifications”. In our example, the alert is related to time off, so we’ll select the “Time Off” Notification Type. Next week, we’ll talk more about Notification Routing Rules.

If your custom report includes prompts and you don’t mark them as “Do Not Prompt at Runtime”, you’ll need to configure them here. You can set them up on your alert the same way you’d set them up on a custom report! If you intend to use your custom report for multiple alerts or other purposes, configure the report prompts within your alert to keep the report more flexible.

If you’d like, you can include a task within your alert. This adds a task button at the bottom of the alert’s Workday notifications.

It will look like this in the notification:

You’ve got options here! In the “Recipients” input, you can add any field that exists on your PBO. In the “Groups” input, you can add any security group. A Recipient of “Worker” and a Group of “Employee As Self” will send the alert to the same population. One or the other will suffice!

You can also check the box below and add any email address (e.g., shared inboxes, third party systems, etc.). Workday can now send secured data to external email addresses; by checking this box, you consent to this. So use this setting carefully!

You can enter an email address here if you’d like this notification to have a different Reply To email than your Default SMTP Configuration.

The subject for the notification! For our example, it’ll be:

Text added here will appear before and after the Details of your Body message, respectively:

This is the meat of your notification content! Within the Details of your notification’s Body, you can add dynamic fields, text, and even HTML. Note, however, that HTML only translates to your email notifications—a major limitation.

Unfortunately, alerts aren’t yet supported by Workday’s Notification Designer. This is a huge pain point for Workday customers, and perhaps even deters some folks from utilizing alerts. Personally, I don’t think it’s reason enough to avoid alerts! With calculated fields and line breaks for formatting, you can achieve aesthetically pleasing (albeit, plain) alerts. Notification Designer should be delivered for alerts eventually—you might as well get your alerts in order now, and upgrade aesthetics later! In the meantime, I recommend giving this brainstorm an upvote 😉

In our example, here are the Body Details:

If your Notification Routing Rules are set up for email, alerts deliver both an email and Workday notification. Here are results, respectively:

Keep in mind, if multiple notification topics are generated for one recipient, the Body Details will repeat within the notification. We’ll cover this in detail next week!

Click on the “Schedule” tab. This is where you configure the “How often” and “When” you defined in Step 1. For our example, I’ve set the alert to fire on the first Monday of every month at 8am PT:

Ensure that your alert processes are owned by an integration system user (ISU). If your alerts are owned by employees at your organization, they’re at risk of breaking unexpectedly.

A few months ago, we published a 3-part series on “turnover-proofing” your processes.

Check them out here for detailed help with this step 👇

Turnover-proof your processes Part 1, Part 2, and Part 3.

Once your alert is owned by your ISU, it’s time to test.

First, redirect email notifications to a good email or inbox for testing.

Next, log in as your ISU, navigate to the task, “View Alerts”, and find your alert. Click the related actions button on your alert, hover over “Schedule Future Processes”, and click “Run Now”.

Drill into “Notifications Generated” to see your notification details. Proxy as at least one of the recipients to view the Workday notification, and check for the email notification in your inbox.

If you need to refine your notification, click the related actions button on your alert, hover over “Schedule Future Processes”, and click “Edit”.

Once you’re satisfied with your alert outputs…

And there you have it—your data is now working a little bit harder for you! 😜

💃🏻🕺🏻💃🏻🕺🏻💃🏻

As always, thank you for reading!

We’re celebrating you and your pursuit of a Well Built Workday 🥳

Until next time!

Ceci & Mia

Co-Founders of Well Built Solutions