Plex and Paylocity integration

What moves between them

Employee and payroll data flows from Paylocity into Plex. When Paylocity processes a payroll run, ml-connector reads the Payroll Processed event (or polls for completion) and fetches the underlying pay statements and deductions. These are aggregated by Plex cost center, converted to labor cost journal entries, and posted into the matching Plex GL accounts. Employee records flow the same direction so Plex headcount and organizational data reflect new hires, terminations, and changes in Paylocity. Reference data such as cost centers and work locations are validated against Plex before posting to ensure every entry lands on a valid dimension.

How ml-connector handles it

ml-connector stores OAuth credentials for both Plex and Paylocity encrypted and presents the correct Bearer token on every request. Because Plex does not support webhooks, ml-connector polls Paylocity for Payroll Processed, New Hire, and Employee Change events on a schedule tied to your payroll calendar, then fetches the full details from Paylocity's REST API. Cost centers are fetched from Plex first so every labor line maps to a valid GL account and cost center before posting. Paylocity's webhook payloads arrive with employee IDs only, so ml-connector fetches the full employee record via the Paylocity REST API immediately after receiving a New Hire or Employee Change event. OAuth tokens for both systems are refreshed on expiry, and Paylocity's 3600-second token lifetime is handled transparently. Every labor posting is recorded in the audit trail so failed entries can be replayed without duplication.

A real-world example

A mid-size discrete manufacturer with plants in two locations runs Plex ERP for production, procurement, and finance, and uses Paylocity for payroll across both plants plus a head office. Before the integration, finance received a payroll register from Paylocity each pay period and manually entered labor costs into Plex by plant, then spent the first days of month-end close reconciling Plex headcount against actual hires and terminations. With Plex and Paylocity connected, each payroll run's labor costs flow automatically into Plex, allocated to the correct plant cost center, and employee changes keep headcount current. Month-end close begins with labor accounts already reconciled, and the manual re-keying step is eliminated.

What you can do

• •Sync new hires, terminations, and employee changes from Paylocity into Plex headcount and organizational records.
• •Post labor costs from Paylocity payroll runs into Plex GL accounts, allocated to the correct cost center.
• •Map Paylocity cost centers and work locations to Plex GL dimensions so payroll entries land on valid accounts.
• •Authenticate both systems with OAuth 2.0 client credentials and poll Paylocity on a payroll-calendar schedule.
• •Track audit trails on every employee and labor posting so failed entries can be replayed without duplication.

Questions

Which direction does data move between Plex and Paylocity?

Data flows from Paylocity into Plex. Employee records, new hires, terminations, and payroll-processed events move from Paylocity into Plex so that headcount and labor costs are kept current. Plex cost centers are read and validated, but no data is written back to Paylocity. Plex has no employee or payroll objects to update, and the integration is one-way for operational reasons.

How does ml-connector handle the fact that Plex has no webhooks?

ml-connector polls Paylocity for Payroll Processed, New Hire, and Employee Change events on a cadence tied to your payroll calendar, rather than waiting for a push from Plex. Because Paylocity webhook events carry employee IDs only, ml-connector fetches the full employee and pay statement records from the Paylocity REST API immediately after receiving an event, ensuring complete data is available before posting.

What happens if a labor posting fails to write to Plex?

Every labor posting is recorded in ml-connector's audit trail with the original Paylocity event and Plex GL account reference. If a posting fails due to a network error or invalid cost center, the record is held in the queue and can be replayed after the issue is resolved. Deduplication ensures that replay does not create duplicate postings.