12.3 Custom Notifications
Key Takeaways
- Custom notifications are configurable messages on a business process that alert participants or other security groups when defined triggers fire—process status changes or step entry/exit.
- The Notifications tab on a BP definition shows both system (delivered) and custom notifications for that process.
- Notifications can deliver in Workday and/or email depending on configuration and user preference settings—they inform; they do not replace approvals or security.
- Create and test custom notifications with real BP events so recipients, triggers, and content match the intended control or communication design.
- Notification design complements conditions and routing: conditions decide if steps run, routing decides who acts, notifications decide who is informed.
12.3 Custom Notifications
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. On a 50-question exam where Business Process Fundamentals is about 20%, expect scenario items that ask 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:
| Trigger pattern | Meaning | Example |
|---|---|---|
| Process status changes | Fires when the overall event status moves (for example completed, denied, canceled—per allowed options) | Alert HRIS when Hire is Successfully Completed |
| Step entry | Fires when the workflow enters a configured step | Notify Security Admin when a Change Job To Do for security review is created |
| Step exit | Fires when a step completes and the process leaves it | Notify manager when compensation review step finishes |
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
| Business need | Notification pattern |
|---|---|
| Compliance visibility | Alert a control group when high-risk events complete or are corrected |
| Operational handoff | Notify a team that does not have an approval step but must prepare facilities or IT |
| Audit awareness | Inform administrators when someone cancels or denies a sensitive process |
| Stakeholder courtesy | Tell a worker’s matrix partner that a transfer completed |
| Defense in depth | Alert admins when transactions are corrected (visibility even if not a hard stop) |
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:
| Mechanism | What the recipient gets | Blocks the process? | Typical purpose |
|---|---|---|---|
| Approval / Action step | My Tasks work item requiring Approve/Submit/etc. | Yes, until completed (unless optional/skipped) | Control and data capture |
| To Do step | Inbox reminder/task (may link to a Workday task) | Can hold sequence depending on design | Checklist work inside/outside Workday |
| Step help text | On-screen instructions while on a step | No | Guide the actor |
| Custom notification | Alert (Workday and/or email) | No (informational) | Awareness for participants or others |
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:
- Open the business process definition (correct effective-dated version).
- Go to the Notifications tab (or Related Actions path used in your training lab to maintain notifications).
- Create a custom notification: name it clearly for operations.
- Choose the trigger: status-based and/or step entry/exit for a selected step.
- Define recipients: security groups, roles, process participants, or other allowed targets per configuration options for that process.
- Compose content: subject/body that states what happened and what (if anything) the recipient should do outside the approval path.
- Configure channels (Workday / email) consistent with tenant standards.
- Save with an appropriate effective date strategy for the definition change.
- 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:
- What event occurred (Hire, Terminate, Change Job)?
- Who is the subject worker?
- When / effective context if relevant?
- What next (optional link or instruction), without pretending the email is the approval?
Testing Custom Notifications (T52)
“Create and test” is explicit blueprint language. Testing means more than saving the definition.
| Test case | What you verify |
|---|---|
| Positive trigger | Performing the status/step action generates the notification |
| Negative trigger | A different path that should not fire does not notify |
| Recipient | The intended group/user receives it; unintended users do not |
| Channel | Appears in Workday and/or email as designed |
| Content accuracy | Names, process, and instructions are correct |
| Interaction with conditions | If the step is skipped by entry condition, step-entry notifications for that step should not fire |
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
| System | Custom | |
|---|---|---|
| Source | Delivered with Workday process design | Configured by tenant admins |
| Purpose | Baseline product behavior | Tenant-specific communication |
| Tab listing | Shown on Notifications tab | Shown on Notifications tab |
| Exam angle | Know both appear on the definition | You create/test custom ones for T52 |
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:
| Tab | Role |
|---|---|
| Business Process Steps | Order, type, group, conditions column |
| Notifications | System + custom alerts |
| Allowed Actions by Role | Which actions roles may perform |
| Allowed Services | Delivered services available |
| Related Links | External URLs |
| Available Rules & Fields | Condition inputs |
Custom notifications live with the definition, inherit effective-dating discipline of BP configuration, and should be documented like any other control.
Common Confusions Table
| Statement | Verdict | Why |
|---|---|---|
| Custom notification = Approval step | Incorrect | Inform vs require action |
| Notifications only send email, never Workday | Incorrect | Workday and/or email per config/preferences |
| Step-entry notification fires even if entry condition skips the step | Generally incorrect expectation | No entry → no entry trigger |
| Only process initiator can receive notifications | Incorrect | Other groups/users can be recipients |
| Testing is optional for T52 | Incorrect | Blueprint says create and test |
| Notifications activate domain security policies | Incorrect | Unrelated to Activate Pending Security Policy Changes |
Design Checklist for Exam Scenarios
- Identify the communication goal (inform vs control).
- If control is required, add/configure a step; use notification only for awareness.
- Choose trigger: status vs step entry/exit.
- Choose recipients with least privilege.
- Write clear content.
- Consider interaction with conditions (skipped steps).
- Test positive and negative paths in sandbox.
- 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.
What is a custom notification on a Workday business process?
A team needs to be informed when Hire completes but must not approve the hire. What configuration best fits?
Which statement correctly contrasts custom notifications and step help text?
You configured a step-entry custom notification on a conditional HR review step. Domestic hires skip the step via entry condition. What should a proper test expect for domestic hires?