Connectors and Connections

Overview of nodes, triggers, and connection types in UKG Compose.

Connectors and Connections

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

This page explains how to think about connectors, nodes, triggers, and connection types in UKG Compose. It helps users choose the right Compose building blocks and understand how UKG-managed and customer-managed connections differ. This page uses the same terminology you see in the editor (trigger, node, workflow, execution, IF, Switch, Error Trigger, Respond to Webhook, etc.).

Node and connector pages in this section

UKG Compose provides several UKG-specific nodes organized by workflow purpose:

Connectors, nodes, and triggers

UKG Compose uses the embedded n8n editor, so users will see n8n terminology directly in the product. That means this documentation should keep the same terminology users see in the editor, including terms like:

  • Trigger
  • Node
  • Workflow
  • Execution
  • Expressions
  • IF
  • Switch
  • Error Trigger
  • Respond to Webhook

At a high level, users will work with three broad categories of workflow building blocks.

Trigger nodes

A trigger node starts the workflow.

Use trigger nodes when the workflow should begin because:

  • A schedule is reached
  • A user submits information
  • An external system calls a webhook
  • A supported UKG Pro event occurs

Action nodes

An action node performs work after the workflow starts.

Use action nodes when the workflow needs to:

  • Send a notification
  • Request or process an approval
  • Update data
  • Call a downstream service
  • Move work forward in another UKG process

Query nodes

A query node retrieves information so the workflow can make decisions or enrich later steps.

Use query nodes when the workflow needs to:

  • Look up person information
  • Retrieve ITM-related context
  • Find identifiers needed by later nodes
  • Branch based on returned data
  • Enrich a request before taking action

General n8n nodes

Compose workflows also use general n8n nodes for workflow logic and orchestration.

Use general n8n nodes when the workflow needs to:

  • Transform data
  • Branch with IF or Switch
  • Manipulate values with expressions
  • Call a generic HTTP endpoint
  • Loop, merge, or format values
  • Handle errors or route exception paths

In practice, many real workflows combine UKG-specific nodes with general n8n nodes.

For the full n8n node catalog, see n8n node types.

Connection types in UKG Compose

There are two main connection models users should understand in UKG Compose:

  • UKG connections
  • Third-party connections

UKG connections

UKG connections are managed by Compose and designed to reduce setup effort for builders.

When you use a UKG-specific node in your workflow, the underlying connection to the UKG service is managed by Compose. This means:

  • Reduced configuration: Builders don't need to manually configure credentials, endpoints, or authentication for UKG services
  • Built-in security: Connections use secure, product-managed authentication
  • Simplified workflow design: Builders can focus on workflow logic rather than connection setup

UKG connections support UKG-aware workflow behaviors such as:

  • Reacting to supported UKG Pro HCM events through ProHCMEventTrigger
  • Sending UKG notifications through Notification and BulkNotification
  • Coordinating approvals tied to UKG processes through ItmApproval, HrDataHandler, and ProHcmWorkflow
  • Updating Pro HR data through ProHRServicesAPI
  • Retrieving UKG-related person or ITM information through Person and ITM query nodes

What builders still need to provide

Even though UKG connections are managed by Compose, builders must still ensure:

  • Product access: Users have the right access to Compose through HCM security
  • Prerequisites: Required setup such as UKG Webhooks is complete when using event-driven triggers
  • Workflow inputs: Correct identifiers (person ID, job ID, assignment ID, etc.) are provided to nodes
  • Business logic: Validation and routing logic is designed correctly for the intended use case

Third-party connections

Third-party connections are configured by the customer or implementation team and used securely within Compose workflows (see Security and Governance).

Unlike UKG connections, third-party connections require the customer to:

  • Configure the external system: Set up the target application, service, or API endpoint
  • Provide credentials: Supply authentication credentials that Compose will use securely
  • Coordinate with IT: Work with the customer’s IT team or system owner to ensure network access, permissions, and security requirements are met
  • Maintain the connection: Manage credential updates, system changes, and access governance over time

Third-party connections typically involve external business systems such as:

  • ServiceNow: For ticket creation, updates, and case management workflows
  • Collaboration platforms: For messaging, notifications, and team coordination
  • External APIs: For custom integrations with customer-managed applications
  • Partner systems: For downstream data exchange and orchestration

How Compose secures third-party connections

Once configured, Compose uses third-party connections securely in workflows:

  • Credential management: Connection credentials are stored and used through approved Compose mechanisms
  • Workflow isolation: Workflows use connections without exposing credentials to builders
  • Access control: Only authorized builders can configure and use connections in workflows

However, Compose does not replace the customer’s responsibility for:

  • Configuring and maintaining the external system
  • Ensuring the external system is accessible and properly secured
  • Coordinating changes with system owners and IT teams
  • Governing who can create workflows that use sensitive external connections

Planning for third-party integrations

When designing workflows that use third-party connections, involve the customer’s IT team or system owner early:

  • Before building: Confirm the external system is available, accessible, and approved for integration
  • During setup: Coordinate credential provisioning, network access, and security requirements
  • Before activation: Validate that test calls succeed and the external system responds as expected
  • After activation: Establish monitoring and support ownership for the integrated workflow

How to choose the right node or connection

When choosing a node or connection, start with these questions.

What starts the workflow?

Choose the trigger based on how the business process begins (see Build Workflows in UKG Compose):

  • Use a schedule for recurring evaluation
  • Use a webhook when another service needs to call the workflow (see Webhook Triggers)
  • Use a UKG HCM event trigger when the workflow should start from a supported Pro event (see Webhook Triggers)
  • Use a form or request-based pattern when a person must provide input

What result should the workflow produce?

Choose the action node based on the intended outcome:

What data is needed along the way?

After choosing the trigger and intended action, decide if:

  • Values need to be inspected
  • Branching is needed
  • Enrichment or lookup is required
  • Failures need an exception path
  • The workflow depends on identifiers such as person ID, job ID, request ID, or approver identity

Is the target UKG-managed or third-party?

Choose a UKG-managed connection when the workflow needs UKG-aware behavior and supported product integration.

Choose a third-party connection when the workflow must interact with an external customer-managed system. In these cases, involve the customer’s IT team or system owner early in the design and setup process.

Tips for working with connectors and triggers

  • A workflow may use more than one trigger pattern when the business process requires it.
  • Some solutions may support both a scheduled trigger and an event-driven trigger pattern, depending on how the workflow is designed.
  • Webhook-based workflows use endpoints secured within UKG Cloud.
  • UKG-managed connections reduce setup effort, but builders still need the right permissions and prerequisites.
  • Third-party connections often require coordination with the customer’s IT team or system owner.
  • General n8n nodes are often used alongside UKG nodes to transform data, branch logic, and handle exceptions.
  • Validate prerequisites before testing event-driven or externally connected workflows.

Common workflow pattern: combine UKG nodes with n8n logic

A typical Compose workflow often looks like this:

  1. Start with a UKG or n8n trigger.
  2. Use general n8n logic nodes to inspect and transform data.
  3. Use a UKG node or third-party connection to complete the business action.
  4. Add an exception or error path if needed.

Examples:

  • A UKG webhook trigger starts a workflow (see Webhook Triggers), then IF routes to the correct notification path (see Notification Nodes)
  • A person query node (see Data Query Nodes) retrieves an identifier, then a workflow action node uses it in a later step
  • A request flow collects input, enriches it through a query node, and sends an approval (see Approval and Workflow Nodes)
  • An event-driven flow receives an HCM event, transforms the payload, and sends a downstream update (see API Integration Nodes)
  • A workflow evaluates a ServiceNow-related condition and then sends work to a customer-managed connection

This mixed pattern is normal and should be expected (see Common Use Cases and Design Patterns).

Connector categories in this documentation set

The current public connector documentation is organized into the following categories.

Webhook Triggers

Use these when the workflow should start from a UKG-aligned event or webhook call.

Covered nodes:

  • ProHCMEventTrigger
  • UkgWebhookTrigger

Notification Nodes

Use these when the workflow needs to communicate with users through supported channels or approval-style notification patterns.

Covered nodes:

  • Notification
  • BulkNotification

Approval and Workflow Nodes

Use these when the workflow must approve, reject, coordinate, or advance work in a UKG process.

Covered nodes:

  • ItmApproval
  • HrDataHandler
  • ProHcmWorkflow

API Integration Nodes

Use these when the workflow needs to update data through a supported UKG API-oriented node.

Covered nodes:

  • ProHRServicesAPI

Data Query Nodes

Use these when the workflow needs to retrieve person or ITM information before making a decision or taking action.

Covered nodes:

  • Person
  • ITM

Data Tables

Use this when the workflow needs to store and query structured data within Compose.

Covered node:

  • Data Tables

Form Triggers

Use these when the workflow should start from a user-submitted form or multi-page form flow.

Covered nodes:

  • Form Trigger
  • Form (Next Page and Ending Page)

HTTP Request Node

Use this when the workflow needs to call an API that doesn't have a dedicated node, including UKG APIs, third-party services, or custom applications.

Covered node:

  • HTTP Request

Explore specific node types

For detailed information about each UKG-specific node category, including when to use each node, prerequisites, configuration guidance, and troubleshooting tips:

  • Webhook Triggers - ProHCMEventTrigger and UkgWebhookTrigger for event-driven and webhook-based workflows
  • Form Triggers - Form Trigger, Form (Next Page), and Form (Ending Page) for user-submitted forms and multi-page flows
  • Notification Nodes - Notification and BulkNotification for targeted and bulk messaging
  • Approval and Workflow Nodes - ItmApproval, HrDataHandler, and ProHcmWorkflow for approval and workflow coordination
  • API Integration Nodes - ProHRServicesAPI for Pro HR employee data updates
  • Data Query Nodes - Person and ITM for retrieving workflow context
  • Data Tables - Data Tables node for storing and querying structured data within workflows
  • HTTP Request Node - HTTP Request node for calling any REST API, including UKG APIs and third-party services

Related pages

Note: Additional UKG connector categories can be added later as the supported node set expands.