Documentation
What's NewUKG.comMarketplaceUKG Pro status

API Integration Nodes

ProHRServicesAPI for Pro HR employee data updates.

API Integration Nodes

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

API integration nodes send structured data updates to supported UKG services. This page uses the same terminology you see in the editor (node, workflow, execution, etc.).

UKG Compose currently provides ProHRServicesAPI for supported Pro HR employee data updates.

API integration node in UKG Compose

ProHRServicesAPI - Apply supported employee data updates in Pro HR after validation or approval; handles name, address, phone, and other employee field changes

Use API integration nodes when a workflow must:

  • Update employee data after a request is submitted.
  • Apply a change after an approval is granted.
  • Write validated field changes back into Pro HR.
  • Move from workflow logic into a system-of-record update.

These nodes are often paired with form-based workflows that collect employee data, notification or approval steps that validate updates (see Notification Nodes and Approval and Workflow Nodes), query nodes that retrieve identifiers (see Data Query Nodes), and IF or Switch logic that determines whether to proceed.

When to use ProHRServicesAPI

Use ProHRServicesAPI when the workflow needs to apply a supported employee data update in Pro HR.

This node is the best fit when:

  • The workflow has already gathered the required employee identifier.
  • The change should be applied only after validation or approval.
  • The workflow must write the change back into Pro HR.
  • The business process is centered on updating supported employee data fields.

Typical scenarios include:

  • Updating name-related information after a validated request.
  • Updating address information after review.
  • Updating phone-related details after intake and approval.
  • Applying HR data changes after a structured workflow decision.

What kinds of updates this node supports

Public documentation should describe this node in business terms rather than low-level payload detail.

Typical update patterns may include supported employee data changes such as:

  • Name updates
  • Address updates
  • Phone updates
  • Other supported employee field changes as documented by the product

The public guide should stay focused on what kinds of business updates are supported and what design considerations matter before the node is executed.

Common workflow patterns

Form-driven employee update

Pattern:

  1. Form Trigger starts the workflow.
  2. Workflow collects employee-submitted information.
  3. Logic validates required values.
  4. (Optional) Approval or review step occurs.
  5. ProHRServicesAPI applies the update.
  6. Workflow sends confirmation or follow-up communication.

Use this pattern when the workflow starts with employee- or admin-submitted data.

Approval to HR update

Pattern:

  1. Request or event starts the workflow (see Webhook Triggers).
  2. Workflow gathers the target employee ID and proposed field changes (see Data Query Nodes).
  3. Notification or another approval step collects a decision (see Notification Nodes and Approval and Workflow Nodes).
  4. IF or Switch routes based on the returned result.
  5. ProHRServicesAPI applies the approved update.

Use this pattern when the system update should happen only after a business decision is made.

Event-driven evaluation to update

Pattern:

  1. Event or webhook trigger starts the workflow.
  2. Workflow evaluates the incoming context.
  3. Lookup or logic confirms whether an update is needed.
  4. ProHRServicesAPI applies the update.
  5. Later nodes send confirmation, audit, or exception handling.

Use this pattern when the workflow is part of a broader automation scenario.

Inputs that matter

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

Typical inputs may include:

  • Employee identifier.
  • Supported field values to be updated.
  • Workflow context that determines whether the update should proceed.
  • Approval or validation result from earlier steps.
  • Any comments or business context needed by the process.

Before executing the node, builders should confirm:

  • The correct employee is targeted.
  • The field values are complete and valid.
  • The workflow has already resolved any approval or exception path.
  • The update is appropriate for the supported business scenario.

Outputs that matter

Later nodes may depend on:

  • Confirmation that the update succeeded.
  • Response details indicating that the change was accepted.
  • Status information used for later routing.
  • Identifiers or results needed for confirmation messages, audit steps, or exception handling.

Builders do not need every low-level response field in the public guide, but they do need to understand whether the workflow can trust the update result and what later logic should review.

Validation and safety considerations

When a workflow updates employee data, validation matters.

Builders should think carefully about:

  • Whether the employee identifier is correct.
  • Whether the proposed change was reviewed or approved if needed.
  • Whether the workflow is using the correct field values and formats.
  • Whether the workflow should stop when validation fails.
  • Whether a fallback or exception path should handle invalid input.

Public documentation should encourage builders to validate before update, not after.

Identity, permissions, and prerequisites

Data-update workflows often depend on the right access model and business identifiers being available.

Builders and admins should confirm:

  • The workflow has the right employee identifier.
  • The builder understands which user or business action is driving the change.
  • Access and prerequisites are satisfied for the product scenario.
  • The workflow only attempts supported updates through the node.

This is especially important when the workflow combines employee-submitted data, approval steps, and downstream system-of-record changes.

Tips for working with API integration nodes

  • Validate business logic before executing the update node.
  • Use IF or Switch to separate approved, rejected, and exception paths before the node runs.
  • Gather and verify the employee identifier before attempting the update.
  • Use form or query steps to prepare complete, structured data for the update.
  • Treat the update step as the system-of-record action, not just another workflow transformation.
  • Use Execution History to review the exact point where the update succeeded or failed.
  • Design a confirmation or exception path after the update so the workflow does not end silently.
  • Use Error Trigger or an exception branch when downstream recovery is needed after a failed update.

Common pitfalls to avoid

  • Attempting the update before the workflow has the correct employee identifier.
  • Applying the update before approval or validation has completed.
  • Assuming the data format is correct without checking workflow inputs.
  • Not handling failed updates explicitly.
  • Not separating data collection from data update in more complex workflows.
  • Treating the update as successful without reviewing the execution result.

Troubleshooting API integration issues

When an update-oriented workflow does not behave as expected, start with:

  • Whether the execution reached the API integration node
  • Whether the employee identifier was present and correct
  • Whether the input values were complete and valid
  • Whether the workflow routed to the update step appropriately
  • Whether the node output indicates success or failure
  • Whether a later step assumed the update succeeded when it did not

If the workflow includes approval or form-based intake, also confirm that the returned data was structured correctly before the update step executed (see Approval and Workflow Nodes).

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

Related nodes and workflow patterns

API integration nodes are commonly used with:

  • Form-based triggers and request workflows
  • Notification for approval or confirmation steps
  • Query nodes for retrieving employee identifiers or related context
  • IF and Switch for validation and routing
  • Error Trigger and exception branches for failed updates
  • Webhook or event triggers that start a data-driven workflow

Related pages

Other node types:

Conceptual pages:

Updated 8 days ago