Approval and Workflow Nodes

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

Approval and workflow nodes execute business actions that require approval, rejection, workflow coordination, or user attribution. This page uses the same terminology you see in the editor (node, workflow, execution, pending execution, etc.).

UKG Compose provides three approval and workflow action nodes: ItmApproval for ITM assignment and application approvals, HrDataHandler for approval coordination and normalization, and ProHcmWorkflow for Pro HCM workflow actions.

Approval and workflow nodes in UKG Compose

• ItmApproval - Approve or reject ITM assignments and applications; writes approval decisions back to ITM
• HrDataHandler - Coordinate approval data across multi-step processes; normalize responses and manage pause/resume behavior
• ProHcmWorkflow - Execute supported Pro HCM workflow actions including approve, reject, submit, and advance operations

Use approval and workflow nodes when a workflow must:

• Approve or reject an ITM assignment or application.
• Coordinate pause and resume behavior in an approval process.
• Advance a Pro HCM workflow using a supported action.
• Combine a user response with a downstream business action.

These nodes are often paired with Notification to request user responses (see Notification Nodes), IF or Switch to route based on results, query nodes to retrieve approvers and identifiers (see Data Query Nodes), and triggers that start the approval process (see Webhook Triggers).

When to use ItmApproval

Use ItmApproval when the workflow needs to approve or reject ITM-related records, such as assignments or applications.

This node is the best fit when:

• The workflow already knows which ITM record needs action.
• A user or workflow decision should approve or reject that record.
• The business process must write the decision back to ITM.
• The workflow needs an explicit approval action rather than only a notification.

Typical scenarios include:

• Assignment approval
• Assignment rejection
• Application approval
• Application rejection
• Workflow paths that turn a user response into an ITM action

When to use HrDataHandler

Use HrDataHandler when the workflow needs coordination logic for HR approval-style processing, especially when pause, resume, normalization, or multi-step approval handling is involved.

This node is the best fit when:

• The workflow needs to coordinate data across approval stages.
• User responses must be normalized before later routing.
• The process includes pause and resume behavior.
• The workflow needs a structured handoff between approval steps and later business actions.

Typical scenarios include:

• Approval coordination across multiple steps.
• Normalization of approval outcomes before routing.
• Pause/resume patterns after a notification or decision point.
• Workflows where later nodes depend on a consistent HR data structure.

When to use ProHcmWorkflow

Use ProHcmWorkflow when the workflow needs to perform a supported workflow action in Pro HCM.

This node is the best fit when:

• The workflow must approve, reject, submit, or advance Pro HCM work
• The process depends on a workflow action code
• The workflow needs to act on a specific Pro HCM job or work item
• The business process must write a user-attributed action back into Pro HCM

Typical scenarios include:

• Approval of a Pro HCM workflow task
• Rejection of a workflow task
• Submission or advancement of a workflow step
• Workflow actions that require comments, metadata, or action context

Choosing between the three nodes

Use this simplified decision model:

Choose ItmApproval when:

• The action is specifically about approving or rejecting ITM assignments or applications.
• The workflow needs to act directly on ITM business objects.
• The business result is an ITM approval outcome.

Choose HrDataHandler when:

• The workflow needs coordination or normalization between approval-related steps
• The process includes pause/resume behavior
• The workflow must prepare or structure approval data before later action nodes run

Choose ProHcmWorkflow when:

• The workflow needs to perform a supported action in Pro HCM
• The process depends on a workflow action code
• The workflow must advance or resolve Pro HCM work

Approval and workflow action patterns

These nodes are most useful when the workflow design clearly separates:

1. How the decision is collected.
2. How the business action is executed.
3. How the result is routed afterward.

In many cases, the workflow pattern looks like:

1. Trigger starts the workflow.
2. Notification or form collects the decision.
3. Logic evaluates the returned action.
4. An approval or workflow node performs the business action.
5. The workflow routes to the next step.

Common workflow patterns

Notification to ITM approval action

Pattern:

1. Trigger starts the workflow (see Webhook Triggers).
2. Notification requests a user decision (see Notification Nodes).
3. IF or Switch inspects the response.
4. ItmApproval approves or rejects the ITM record.
5. Workflow ends or routes to follow-up steps.

Use this pattern when a user response should directly drive ITM approval behavior.

Notification to Pro HCM workflow action

Pattern:

1. Event, request, or form starts the workflow
2. Workflow gathers the job ID, action code, and user context
3. Notification or another decision step captures the user response
4. ProHcmWorkflow executes the supported workflow action
5. Later logic handles confirmation, follow-up, or exception paths

Use this pattern when a human or system decision should advance work in Pro HCM.

Approval coordination with HrDataHandler

Pattern:

1. Trigger starts the workflow
2. Workflow gathers and structures the approval context
3. HrDataHandler normalizes or coordinates the approval state
4. Later nodes route the workflow, notify users, or execute business actions

Use this pattern when the workflow needs an intermediate coordination step rather than a final approval action only.

Multi-step approval with pause and resume

Pattern:

1. Request or event starts the workflow
2. Workflow sends a notification or approval request
3. Execution enters a wait state or pending state
4. Response returns to the workflow
5. HrDataHandler, ItmApproval, or ProHcmWorkflow executes the next business action

Use this pattern when the workflow is not complete until a person responds and the result must be written back into a UKG process.

Inputs and outputs that matter

Public documentation should focus on the practical inputs and outputs that matter to builders.

Inputs

Approval and workflow nodes often depend on:

• Job ID or workflow record identifier
• ITM assignment or application identifier
• Action code
• Approver or acting user identity
• Approval result or selected response
• Comments, metadata, or business context prepared earlier in the workflow

Outputs

Later nodes may depend on:

• Confirmation that the action executed successfully
• The approval or rejection result
• Normalized response values
• Workflow status or transition information
• Identifiers or outputs needed for follow-up communication and tracking

Builders do not need every low-level field map in the public guide, but they do need to understand what business identifiers and decision values the node expects.

User identity and attribution

Many approval and workflow nodes depend on who is taking the action.

Builders should think carefully about:

• Which user is acting
• Whether the workflow is using the right approver or actor identity
• Whether the correct person ID, approver ID, or action user must be passed to the node
• Whether the business action should reflect the initiating user, an approver, or a system-level service action

This is one of the most important design and troubleshooting considerations for approval workflows.

Waiting, pending states, and resumed execution

Approval-oriented workflows often pause while waiting for a person or system response.

When the workflow is waiting:

• The execution may appear as Pending
• The workflow may be behaving correctly rather than failing
• Later action nodes may not run until the response is returned
• Admins should use Execution History to determine whether the process is waiting, failed, or completed

This is especially important when a notification or form step comes before an approval action node.

Tips for working with approval and workflow nodes

• Separate the decision-collection step from the action-execution step when the process is easier to understand that way.
• Use Notification or form-based input to collect a response, then use IF or Switch to determine which action node should run.
• Validate that the workflow has the correct business identifiers before executing an approval or workflow action node.
• Treat Pending executions as expected when the workflow is waiting for a user response.
• Use query nodes to retrieve approver identity, person data, or record identifiers before the action step.
• Use Execution History to confirm whether the workflow paused correctly, resumed correctly, and executed the intended action node.
• Design exception paths for no-response, invalid-response, or missing-identifier cases.
• Keep comments, action codes, and user attribution aligned with the intended business result.

Common pitfalls to avoid

• using an approval action node before the workflow has the required identifier or actor context
• assuming a user response has been captured when the workflow is still waiting
• writing routing logic that does not correctly distinguish approve vs reject vs other returned values
• treating a Pending execution as a failed workflow without checking whether a wait state is expected
• calling a Pro HCM workflow action without validating the action code and target record
• using the wrong approval node for the business object being acted on
• not separating data normalization from final action execution when the workflow becomes hard to debug

Troubleshooting approval and workflow issues

When an approval-oriented workflow does not behave as expected, start with (see Administration and Operations):

• Whether the execution is Pending, Failed, or completed
• Whether the response or decision was actually returned to the workflow
• Whether the workflow routed to the correct IF or Switch branch
• Whether the required job ID, assignment ID, application ID, or actor identity was present
• Whether the action node executed successfully
• Whether the wrong node was used for the intended business object
• Whether a later step assumed the action completed when it did not

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

Related nodes and workflow patterns

Approval and workflow nodes are commonly used with:

• Notification for collecting an approval or decision
• Query nodes for retrieving approvers and business identifiers
• IF and Switch for approval-result routing
• Webhook, form, or event triggers that start the process
• Error Trigger and exception branches for failed or missing responses
• API and data query nodes for related data updates or lookups

Related pages

Other node types:

• Webhook Triggers
• Notification Nodes
• API Integration Nodes
• Data Query Nodes

Conceptual pages:

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