12.3 Custom Notifications

12.3 Custom Notifications

Study index: T-numbers here refer to this guide’s index of an older Workday topic list. They are not current Workday task IDs or published exam weights.

Quick Summary: Custom notifications send targeted alerts when a business process reaches a status or when a step is entered or exited. Configure them on the definition’s Notifications tab (alongside system notifications), choose recipients and channels, then test with real events. Notifications improve visibility; they do not approve transactions or grant security.

Task T52 asks you to create and test custom notifications with BP triggers. A useful practice scenario asks when a message fires, who receives it, and how that differs from an approval task or help text.

What Custom Notifications Are

A notification is a message Workday generates from business process configuration to inform people about workflow activity. Definitions expose a Notifications tab that lists:

• System notifications — delivered behaviors Workday provides for the process.
• Custom notifications — customer-configured messages for tenant-specific communication needs.

You can configure notifications to trigger on:

Delivery can target Workday (in-product notifications) and/or email, subject to configuration and the recipient’s notification preferences.

 BP Event lifecycle
   │
   ├─ Status change ──► custom notification (optional)
   │
   └─ Step A entry ──► notification
      Step A exit  ──► notification
      Step B entry ──► notification

Why Tenants Configure Custom Notifications

Configuration scenario: Contoso wants the IT provisioning team notified when Hire completes so laptop and account requests can start, but IT should not approve Hire. Designers add a custom notification on process successful completion to an IT security group (or distribution role), while Manager and HR Partner remain the only Approve participants. IT is informed; HR controls the workflow.

Notifications vs Other BP Communication Tools

Exam distractors often confuse four concepts:

Exam trap: “Add a notification so the manager must approve.” Notifications do not create approval authority. Use an Approval step (and BP security + routing). Notifications can tell a manager something happened; they do not require Approve.

Creating Custom Notifications (Conceptual Workflow)

Exact UI labels vary slightly by tenant version, but the skill flow is stable:

1. Open the business process definition (correct effective-dated version).
2. Go to the Notifications tab (or Related Actions path used in your training lab to maintain notifications).
3. Create a custom notification: name it clearly for operations.
4. Choose the trigger: status-based and/or step entry/exit for a selected step.
5. Define recipients: security groups, roles, process participants, or other allowed targets per configuration options for that process.
6. Compose content: subject/body that states what happened and what (if anything) the recipient should do outside the approval path.
7. Configure channels (Workday / email) consistent with tenant standards.
8. Save with an appropriate effective date strategy for the definition change.
9. Test (next subsection).

Recipient design tips

• Prefer role-based or purpose-built groups over long personal email lists embedded only in notification text.
• Align recipients with who needs to know, not who needs to approve (unless they coincide).
• Avoid notification storms: one completion alert may beat entry+exit+status triples for the same audience.
• Remember constrained security groups receive notifications in their identity context; poorly chosen unconstrained groups can spam the enterprise.

Content design tips

Good notification content answers:

1. What event occurred (Hire, Terminate, Change Job)?
2. Who is the subject worker?
3. When / effective context if relevant?
4. What next (optional link or instruction), without pretending the email is the approval?

Testing Custom Notifications (T52)

“Create and test” is explicit wording in the older Workday guide. Testing means more than saving the definition.

Test method: In a sandbox, initiate a realistic event (proxy as Manager/HR Partner). Drive it through the trigger point. Confirm inbox/email. Then run a parallel event that skips the step via condition and confirm silence.

Configuration scenario: Global Retail adds a custom notification on entry to a “Security review” To Do on Change Job when the worker moves to a privileged job family. Testers: (1) change job into privileged family → To Do created and Security group notified; (2) lateral change without family change → step skipped, no security notification. That negative test proves trigger coupling to the conditional step.

System vs Custom Notifications

Do not disable critical system behaviors casually to “replace” them with custom messages without understanding side effects. Custom notifications add communication; they are not a full substitute for workflow steps.

Notifications, Security, and Privacy

Notifications can expose operational details (worker names, process types, effective dates). Design with least privilege:

• Recipients should already be appropriate for the data class.
• Do not use notifications to bypass domain security by emailing sensitive compensation numbers to broad lists.
• For compensation or employee relations processes, tighten recipient groups and message content.

Exam framing: If a stem emphasizes who is informed when a BP reaches a status, think notifications. If it emphasizes who must act before the process continues, think steps + security + routing.

Placement in the BP Definition Mental Model

Recall definition tabs you met in BP Framework:

Custom notifications live with the definition, inherit effective-dating discipline of BP configuration, and should be documented like any other control.

Common Confusions Table

Design Checklist for Exam Scenarios

1. Identify the communication goal (inform vs control).
2. If control is required, add/configure a step; use notification only for awareness.
3. Choose trigger: status vs step entry/exit.
4. Choose recipients with least privilege.
5. Write clear content.
6. Consider interaction with conditions (skipped steps).
7. Test positive and negative paths in sandbox.
8. Document operational ownership (who maintains the notification when process changes).

Master notifications as the awareness layer of BP configuration. Paired with conditions (logic) and advanced routing (actors), they complete the step-level toolkit before definition-level ordering and validation in the next section.