Navigating Notifications in Workday

In this post we’ve laid out some basics for navigating Workday notification settings to help you in understanding, troubleshooting and even testing email notifications in your tenant.

There are both functional-specific and system areas with their own notification settings. Functional-specific notifications can be set up for areas like learning campaigns, open enrollment, security notifications, and so on. In addition to the more functional-specific alerts and emails, below are some of the more generic configurable places that emails can be generated and sent to users out of Workday.

Workday Delivered Business Process Notifications

Enabled by default for every step of your business processes. These can be individually disabled from the BP definition.

Custom Business Process Notifications

Completely configured by you and can be set to trigger from a variety of actions to nearly any security group, individual user or independent email address. Condition rules and/or BP statuses can be used to trigger the notifications.

Custom Alerts

Completely configured by you and are tied to custom reports, rather than business processes. For any instance that returns in a report, an email can be sent to an applicable security group or individual user for that instance.

Integration Notifications

Created for specific integration status events or on the BP of the integration. Condition rules can be assigned to the notification so that specific messages/ specific recipients can be configured based on the rule.

Tenant Level Settings

There are some important tenant level settings needed for notifications, and to be honest the setup page can be a little confusing for this. The tenant level settings allow you to disable/enable all notifications in the tenant, and also define what method and how frequently different types of notifications should be sent. Below is a breakdown of what all of the setup options are in the “Edit Tenant Setup – Notifications” task.

General Email Notification Settings
  1. Define if you want to disable all emails or redirect all emails to a specific user or independent email address
  2. Selections are made by tenant type by selecting the applicable tenants in the ‘OMS Environment Selected for Restriction’
  3. These selections need to be made in the tenant you want them to apply to, so for Production you probably never want to make any changes to these selections without testing and understanding that you will be impacting the way notification emails are sent out of Production
Reminder Settings
  1. The “Enable reminders” checkbox enables the ability to configure reminder notifications for learning courses, campaigns and personal reminders only
Mobile App Notification Settings
  1. By selecting the “Enable Apple Push Notifications” or “Enable Google Cloud Messaging” checkbox you are enabling both types of notifications to be available for selection in the notification delivery settings
  2. If you select environments for these mobile notifications to apply to then it will adhere only to those environments. You can leave the “Environment” field blank for the selection to apply to all tenant types
Notification Delivery Settings
  1. On the left hand panel of the screen you have the different Notification Areas where delivery settings can be made – categorized in sections such as Adaptive Insights, Alerts, BPs, Payroll, System, etc.
  2. For each Notification Area selected, on the right hand side you have a breakdown of the Notification Types in that area that you can set specific delivery settings for. So, for instance, in the Business Processes Notification Area you can set different delivery settings for your delivered BPs notifications (Approvals, To-Dos, Tasks), Custom BP notifications, Delegations and more. In the System Notification Area, you can define settings for the Integrations Notification Type.
  3. Each Notification Area has a default routing rule, and each Notification Type can have an override routing rule. *Note – if no override routing rule is defined for the notification type, then the default routing rule of the notification area applies that notification type.*
  4. The delivery settings you can define for each routing rule (default or override) are as follows
    • Channel (How/What Method): Will users receive notifications via Email or Mobile Push Notifications, or both? *Note that Mobile Push notifications are only available for selection if one or more of the ‘Mobile App Notification Settings’ are selected earlier in your tenant level notification settings.*
    • Default Frequency (When): This defines by default when the notifications are sent. Options for selection are Immediate, Daily or Mute. Workers can override these selections if allowed frequencies are selected below.

      • Immediate – emails are received immediately upon notification trigger without delay.

      Daily – Emails will be received only once a day in the daily digest emails all together in one email.

      Mute – notifications are completely turned off for the channel

    • Allowed Frequencies: These determine the available options a user has for setting a personal setting on their user account for that specific notification type. If you enter an allowed frequency, then users can set their own preference to change the default frequency of when they receive emails.
    • You can set different frequencies and/or allowed frequencies for your two different channels also. So, for each notification type you could have mobile push notifications sent immediately, but emails sent only once a day in the daily digest emails.
Troubleshooting Notification Delivery

The Notification Delivery Settings (from above) combined with the actual configuration of your notification is where you will find the answer to the common question: “why are notifications sending or not sending to the intended users?”. Here are some quick troubleshooting tips to help you decipher why a notification may be sending or may not be sending as you expect. For example, let’s say a BP notification email is sending but another is not sending when it should be. Follow these steps to see what the problem might be

  1. Run the “Business Process and Integration Notifications” report and confirm if the notification you expected to send to a user is on the report or not. If the notification is on the report, then the notification was triggered. If it is not on the report, then it did not trigger, which means you need to look at the area where the notification is configured to see what occurred or what logic did or did not occur to trigger the notification (i.e. -a BP condition rule may not have been met on a custom notification, or perhaps the BP has not been completed yet, or maybe an approval was not required in a certain instance). *Note that to audit this report correctly you need to know the approximate time that the notification should have sent to the user you are looking for, as this report requires a start and end date/time at run. Make sure your time frame selected correctly encompasses the period you expected the notification to send.*
  2. If you’re checking a custom alert run (rather than an integration or BP transaction) run the task “View Alerts” and open up the hyperlink number for “Number of Times Run” to see if the alert successfully ran at the time anticipated. If it did or did not run as expected, then you may need to check steps 3 and 4 below for further review.
  3. Next, if the notification or alert did trigger, but the email wasn’t received by the recipient, try checking your tenant level settings. Find the Notification Area and Notification Type that the notification falls under (i.e. Custom Business Process under Business Processes area or Integration under System area). Check to confirm how the Override Routing Rule is set up. If there is no override routing rule set for the notification type, then check the Default Routing Rule for the notification area. If you want the notification to send, confirm that the default frequency on the routing rule is not “Mute”. If it is set to Mute, then the notification is turned off. If it is not set to Mute, then it is either sending in Daily Digest or Immediately. Confirm that the correct default frequency is selected for the routing rule.
  4. If all the above return and appear as you expect, then you may want to check what Allowed Frequencies are set up on the tenant level notification settings for the notification type. There is a chance that the user could have muted/turned off or changed these specific notification settings. To check this, you can try logging in as the user in a Sandbox or impl environment to check their settings, or you can ask them to confirm their setting selections for you in Production under their account preferences.

If all these checks still leave you confused and unsure why an email is or is not generating as you expect, double check that you are sure exactly which notification you are reviewing and that it should have indeed triggered. Especially when it comes to BPs sometimes there are circumstances or rules, we forget we have set up to work a certain way and these can impact notifications from triggering. Also check with the user who is not receiving the emails and make sure they do not have an automatic filter setup to send the emails to Spam or Trash.

Testing Notifications

As with anything in Workday, testing is always vital. When it comes to notifications you want to test that

  1. The notification is triggering when it should and when it should not and
  2. You want to make sure the delivery of the email or push notification is confirmed to be working properly. By checking the delivery of the notification emails, you can also validate the format and layout of the data in the email and make any changes accordingly.

Below are some detailed steps and important reminders to help guide you in testing notification emails. A word of caution – it is easy to accidentally impact notifications in your Production tenant or to accidentally start sending IMPL or SBX emails to users that appear as Production emails. So please proceed with caution when setting up email notifications for testing. Do not ever make changes to your notifications settings in Production unless you are 100% confident in the change you are making. For testing you’ll only need to edit the testing tenant settings. We highly recommend the below steps to help avoid any unwanted behavior or impacts to your tenants in testing.

Preparation

First, before you start testing right away we need to do a little prep. If you want to test the delivery of emails to an account to review the email, we highly recommend that you create a dummy email account that multiple admins at your company can use to strictly test notifications. Having one secured email account that multiple people have the password to can be helpful in allowing others to see the emails and sign off on the test results. And if possible, it would really be best if you can have this account setup in your company’s own email domain, because using Gmail or another source can open that risk of accidentally sending personally identifiable information in the emails to an unintended account.

Next, we need to update the tenant settings in the tenant you are testing in to redirect the notification emails. Please ensure you are logged in to the tenant where you want to trigger the notification from before making these below changes (this should not be Production).

  1. Access the Edit Tenant Setup -Notifications task
  2. Under the Notification Delivery Settings section, select the notification area on the left panel that the notification you are testing is associated with (i.e. – Business Processes)
  3. In the notification area, find the Notification Type you are testing (i.e. – Custom Notifications) and see if there is an override routing rule. If there is, open this up, but if there is not then open the default routing rule for the Parent Notification Type. Confirm that the Channel you are testing is set to send Immediately or to Daily Digest. If it is set to Mute, change it to send Immediately to test the email. (Note – in Production you will not want to change the Parent notification routing rule, so if no override rule exists and the parent routing rule is muted, then you will need to create a new override routing rule for your notification type. You should set this up for testing in your test environment if needed).
  4. Under the ‘General Email Notification Settings’ select the radio button to “Redirect All Emails to Email Address: and enter the dummy email address created above in the preparation section here. This ensures that any notifications triggered for any reason at all in your test tenant will automatically be sent to this email address.
  5. Check the “OMS Environment Selected for Restriction column under the “General Email Notification Settings. This column should NOT have changed at all in your setup for this testing. Ensure that that tenant type you are testing in is listed here, but do NOT add any environments to the list of tenant types here.

Now you are ready to test. Access whatever tasks necessary to begin triggering your notifications and the emails should begin arriving in your dummy email account for review. Please note that you may get duplicate emails at times because workday is sending 1 email for each notification triggered for every user in the test tenant. So, if you have a notification being sent to HR Partners, you will receive 1 email for every HR Partner in your organization.

Cleanup

When you’re done testing, don’t forget to go back into “Edit Tenant Setup – Notifications” and re-select the radio button under “General Email Notification Settings” to “Disable All Emails” for the environments listed in your test tenant. If you do not disable the emails your dummy email account will be inundated with emails over time. Happy testing!