Notification Nodes

Note: Compose is only available for Beta testing. See Welcome to UKG Compose > Beta Disclosure for more information.

Notification nodes send messages, approval requests, or pause workflows while waiting for user action. This page uses the same terminology you see in the editor (node, workflow, execution, pending execution, etc.).

UKG Compose provides two notification nodes: Notification for targeted communication to one or a small set of recipients, and BulkNotification for inbox-style communication to many recipients.

Notification nodes in UKG Compose

Notification - Send messages or approval requests to one person or a small set of recipients; supports email, SMS, inbox, and approval-style patterns
BulkNotification - Send inbox-style communication to many recipients at once; designed for bulk outreach and multi-recipient approval collection

Use notification nodes when a workflow needs to:

Notify one person or many people
Send an email, SMS, or inbox message
Create an approval or response-driven step
Wait for a person to take action before continuing
Communicate the result of a business event or workflow branch

Notification nodes are often paired with IF or Switch to decide who should receive a message, query nodes to look up recipients (see Data Query Nodes), and approval nodes to continue processing after a response (see Approval and Workflow Nodes).

When to use Notification

Use Notification when the workflow needs to send a message or approval request to one person or a limited set of recipients.

This node is the best fit when:

The workflow needs to notify a single employee, manager, or approver
The message should use email, SMS, inbox, or another supported channel
The workflow may need to wait for a single approval-style response
The communication is targeted and not intended as a large bulk operation

Typical scenarios include:

Notifying an employee or manager about a workflow outcome
Sending a targeted approval request
Alerting one recipient or a small recipient set after a branch condition is met
Following up after a request, exception, or business event

When to use BulkNotification

Use BulkNotification when the workflow needs to send inbox-style communication or response requests to many recipients at once.

This node is the best fit when:

The workflow needs to notify a larger set of users
The workflow sends bulk inbox messages
Multiple users must receive the same or similar communication
The process may depend on collecting multiple responses or approvals

Typical scenarios include:

Sending inbox notifications to a large audience
Requesting approvals from many users in parallel
Communicating a policy-related update to multiple recipients
Handling a multi-recipient review or action pattern

Choosing between the two nodes

Use this simplified decision model:

Choose Notification when:

The workflow is communicating with one user or a small target set
The workflow uses a direct approval or response pattern
The communication is individualized
The workflow should pause waiting for a single response or a limited interaction

Choose BulkNotification when:

The workflow needs to reach many recipients
The primary pattern is bulk inbox communication
The workflow expects multiple users to receive the same request or message
The process needs a multi-recipient notification or approval model

Supported communication patterns

Notification nodes can support several workflow patterns.

Direct notification

Pattern:

Trigger or branch condition occurs.
Workflow determines the recipient.
Notification node sends the message.
Workflow ends or continues to a follow-up step.

Use this pattern when the goal is simply to inform a user or group.

Approval-style notification

Pattern:

Trigger or request starts the workflow.
Workflow prepares the approval context.
Notification node sends the approval request.
The workflow waits for the user response.
Later nodes route based on the returned result.

Use this pattern when the process requires a human decision before continuing.

Bulk communication

Pattern:

Workflow builds a recipient set.
Bulk notification sends the inbox message or request.
Later logic evaluates delivery or response conditions.

Use this pattern when the workflow must reach multiple people efficiently.

Notification plus follow-up workflow logic

Pattern:

Event or request starts the workflow.
IF or Switch decides whether communication is needed.
Notification node sends the message.
Later nodes update data, escalate, or close the workflow.

Use this pattern when communication is one part of a broader business process rather than the final step.

Channels and message design

Depending on the node and supported pattern, notifications may include channels such as:

Email
SMS
Inbox
Approval-style message or response request

Builders should choose the channel based on:

Who needs the message
Whether a response is expected
How urgent the communication is
Whether the message is targeted or broad
Whether the process should pause while waiting for a reply

Waiting for responses and pending workflows

Some notification patterns intentionally pause the workflow.

This is especially common when:

The notification is acting as an approval request
The workflow waits for a user response
The workflow must not continue until a decision is made

When a workflow is waiting for a response:

The execution may appear as Pending
Admins and advanced builders should review the execution history before treating the workflow as failed
The next step in the flow may depend on returned response data

This is one of the most important operational concepts for notification workflows. A pending execution is not always a problem. It may mean the workflow is doing exactly what it was designed to do.

Inputs and outputs that matter

Public documentation should focus on the practical input and output concepts that matter to builders.

Inputs

Notification patterns often depend on:

Recipient information
Message content
Channel selection
Workflow context or business identifiers
Response expectations
Branch-specific values prepared earlier in the workflow

Outputs

Later nodes may depend on:

Confirmation that the node executed successfully
Returned response values from a user action
Delivery-related status
Approval result or selected action
Identifiers that let the workflow continue with the next step

Builders do not need every low-level field map in the public guide, but they do need to understand what information the node expects and what later nodes may receive from it.

Common workflow patterns

Single-recipient approval request

Pattern:

Trigger starts the workflow (see Webhook Triggers).
Query or logic determines the approver (see Data Query Nodes).
Notification sends the request.
Workflow waits for response.
IF or Switch routes based on the returned action.

Use this pattern when a manager or designated approver must decide what happens next (see Approval and Workflow Nodes).

Exception alert to a targeted owner

Pattern:

Branch condition detects an exception
Workflow determines the responsible person
Notification sends an alert
Workflow ends or routes to a support step

Use this pattern when the goal is visibility or intervention, not necessarily approval.

Bulk inbox outreach

Pattern:

Workflow builds a list of recipients.
BulkNotification sends the inbox communication.
Later logic reviews whether additional follow-up is needed.

Use this pattern when many recipients need the same message or request.

Multi-recipient approval or response collection

Pattern:

Request or event starts the workflow
Workflow determines the recipient set
BulkNotification sends the request
The process waits for responses or evaluates follow-up logic

Use this pattern when a business process depends on multiple people seeing or responding to the same request.

Tips for working with notification nodes

Choose Notification for direct, targeted communication and BulkNotification for broader inbox-based patterns.
Treat approval-oriented notification steps as wait states in the workflow design, not as simple message sends.
Use Execution History to review whether a workflow is Pending, Failed, or completed successfully.
Use query nodes or earlier workflow logic to resolve the correct recipient before the notification step.
Use IF or Switch after a response-driven notification when later actions depend on how the user responded.
Keep message content aligned to the workflow action the recipient is expected to take.
Design a fallback path when the workflow may wait too long for a response.
Use bulk patterns intentionally. Sending to many recipients changes both workflow behavior and troubleshooting expectations.

Common pitfalls to avoid

Using BulkNotification when the workflow only needs a targeted single-user interaction
Treating a Pending approval-style execution as a failure before checking whether the workflow is waiting for response
Not providing the correct recipient information
Assuming a response value will be available when the workflow was not configured to wait for one
Sending a notification before the workflow has gathered the identifiers or context needed by the recipient
Not planning for timeout, no-response, or delayed-response cases
Not reviewing node output before troubleshooting later steps

Troubleshooting notification issues

When a notification workflow does not behave as expected, start with:

Whether the notification node executed successfully
Whether the correct recipient or recipients were passed to the node
Whether the selected channel matched the intended design
Whether the workflow is Pending because it is waiting for a response
Whether the workflow expected a response value that was never returned
Whether a later IF or Switch used the returned values correctly
Whether the issue is in the notification step or in later workflow logic

For operational troubleshooting patterns, use the Administration and Operations page together with this one.

Related nodes and workflow patterns

Notification nodes are commonly used with:

IF for conditional routing after a response
Switch for branching based on returned action or message type
person or ITM query nodes to determine recipients
approval and workflow nodes to continue processing after response
Error Trigger and exception branches for failed communication or delayed responses
webhook, form, or event triggers that start the process

Other node types:

Conceptual pages:

Connectors and Connections (node overview)
Build Workflows in UKG Compose
Common Use Cases and Design Patterns
Administration and Operations

Notification Nodes