Plex and UKG integration

What moves between them

The main flow runs from UKG into Plex. After each payroll run, ml-connector reads UKG's payroll GL journal export and posts the labor cost journals into Plex's general ledger, mapped to matching Plex GL accounts and cost centers. Employee records flow the same direction so Plex headcount reflects UKG hires, terminations, and rehires. Cost centers and departments are aligned in both directions so payroll allocations land on valid Plex cost center codes. GL postings are read-only in UKG, so ml-connector never writes financial entries back to payroll.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents UKG's API key headers and bearer token on every REST call, refreshing the OAuth token when it expires in 1 hour. On the Plex side, it accepts either REST OAuth credentials or legacy SOAP company code and credentials, validating that the integration user has the required Plex role for the entities being synced. Because neither system offers guaranteed real-time webhooks, ml-connector polls UKG on a schedule tied to your payroll calendar using delta endpoints where available, and polls Plex using modified_date filtering or SOAP DataSources, with exponential backoff on HTTP 429 rate-limit responses. Cost centers and departments are mapped first, so every payroll journal line references a GL account and cost center code that already exists in Plex. UKG API key expiry is not a risk since keys do not expire, but OAuth tokens are refreshed on 401 responses. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized automotive supplier runs Plex ERP for production, procurement, and finance across three plants, and uses UKG for payroll and HR across all locations. Before the integration, the finance team exported payroll registers from UKG every pay period and manually re-entered the labor totals into Plex by plant, then spent the first days of month-end close chasing headcount discrepancies between HR records in UKG and the labor accounts in Plex. With Plex and UKG connected, each payroll run's GL document flows into Plex automatically, allocated to the cost center for each plant, and employee changes keep the two systems aligned. Month-end close starts with the labor accounts already reconciled, and the manual re-keying step is eliminated.

What you can do

• •Post UKG payroll GL journals into Plex's general ledger after every pay run, allocated to the correct cost centers.
• •Keep Plex employee records aligned with UKG hires, terminations, and rehires.
• •Map UKG cost centers and employees to Plex cost center codes and GL dimensions so payroll lands on valid accounts.
• •Authenticate UKG with Basic Auth and API keys, or OAuth 2.0, and Plex with either REST OAuth or legacy SOAP credentials.
• •Poll on a schedule tied to your payroll calendar, with exponential backoff on rate limits and a full audit trail on every record.

Questions

Which direction does data move between Plex and UKG?

The main flow is UKG into Plex. Payroll GL journals and employee records move from UKG into Plex, while cost centers and departments are aligned in both directions. UKG payroll GL data is read-only, so ml-connector does not write financial entries back into payroll.

How does ml-connector handle UKG's API key headers and OAuth token expiry?

ml-connector stores both the API key headers (US-CUSTOMER-API-KEY and US-USER-API-KEY) and OAuth credentials encrypted. It presents the API key headers on every REST call and refreshes the OAuth bearer token when it expires in 1 hour or when a call returns 401, so expiry does not cause outages.

How does the integration handle Plex's role-based permissions and lack of webhooks?

ml-connector validates that the integration user has the required Plex role assigned before syncing, so API calls do not return 403 or empty results. Because Plex has no webhooks, it polls REST APIs using modified_date filters or legacy SOAP DataSources on a schedule tied to your payroll calendar, with exponential backoff on HTTP 429 rate-limit responses.