Workday Financial Management and Rippling integration

What moves between them

The primary data flow runs from Rippling into Workday Financial Management. Employee records, department assignments, and compensation data move from Rippling to Workday, mapped to worktags and GL cost centers so payroll allocations land on valid accounts. Compensation changes such as salary adjustments and job changes trigger GL dimension updates in Workday, so accrual accounts reflect the current headcount. The integration polls Rippling employee records and payroll runs on a schedule tied to your pay cycle, typically weekly or biweekly, and transforms payroll liabilities into GL entries for accrual matching.

How ml-connector handles it

ml-connector stores both OAuth2 credential sets encrypted and handles refresh-token cycles on both sides, requesting new access tokens from Rippling and Workday when a call returns 401. It accepts the Rippling API key or OAuth2 credentials and uses either polling or webhooks (if App Shop OAuth is enabled) to capture employee lifecycle changes. For Workday, it uses the SOAP interface for complex GL dimension writes and REST for lighter reads, applying both ISU UsernameToken and OAuth2 refresh tokens as needed. Employee records are normalized first: departments and compensation fields are extracted from Rippling, mapped to Workday worktags and cost centers, and validated against Workday's GL account list before any write. Because Workday has no webhooks, the integration polls Rippling on a weekly or biweekly schedule aligned to your payroll calendar, and it deduplicates repeated polls using the updated_at timestamp on Rippling employees to avoid re-writing unchanged records. Compensation changes trigger GL accrual entries only when thresholds are met, so minor adjustments do not flood the ledger. Every transformed record carries a full audit trail, tracking the source employee ID, the mapped GL account, and the journal entry ID in Workday, so payroll can be replayed or corrected if a downstream write fails.

A real-world example

A mid-market professional services firm runs Workday Financial Management for procurement and general ledger, and Rippling for payroll, HRIS, and benefits across four regional offices. Before the integration, the finance team received a CSV of active employees and compensation from Rippling each month, manually updated cost center and compensation worktags in Workday, and ran a reconciliation step to verify that every payroll accrual GL account matched the current headcount and salaries in Rippling. With Workday and Rippling connected, employee hires and terminations flow automatically into Workday's workforce dimensions, salary changes trigger GL accrual updates on the same day, and month-end close starts with the payroll accrual accounts pre-reconciled. The manual worktag maintenance step is eliminated, and discrepancies between HR headcount and GL balances are caught immediately.

What you can do

• •Sync employee hires, terminations, rehires, and department changes from Rippling into Workday worktags and GL cost centers.
• •Update GL accrual accounts and payroll liability dimensions when compensation changes in Rippling, with validation against Workday's active GL account list.
• •Map Rippling departments and job titles to Workday cost centers so payroll allocations land on valid GL dimensions.
• •Handle OAuth2 refresh cycles and ISU authentication on both sides, with encrypted credential storage and automatic token refresh on 401 responses.
• •Poll Rippling on a schedule tied to your pay cycle, deduplicate repeated polls using timestamps, and maintain a full audit trail on every GL entry.

Questions

How does ml-connector handle Workday's lack of webhooks and Rippling's webhook restriction?

ml-connector polls Rippling's employee records and compensation on a schedule aligned to your payroll cycle, typically weekly or biweekly. It uses the updated_at timestamp on Rippling employees to avoid re-writing unchanged records, and it validates every GL dimension against Workday before writing to avoid duplicate accounts. If your Rippling instance is an App Shop integration with webhooks enabled, ml-connector can listen for real-time employee lifecycle events instead, but the default is polling.

What happens when Rippling compensation data is redacted or Workday GL accounts are missing?

Rippling may redact compensation data based on entitlements, in which case ml-connector skips compensation-based GL updates for that employee and flags the record in the audit log. If a Workday GL account or cost center does not exist, ml-connector halts the write, logs the mismatch, and alerts the finance team so the missing account can be added to Workday before the next sync cycle. No partial writes are applied.

Does ml-connector write back employee or compensation data from Workday into Rippling?

No. Rippling is the authoritative employee and payroll system, and Workday is the authoritative GL system. ml-connector reads employees and compensation from Rippling and writes GL dimensions and accrual allocations into Workday. Rippling employees can only be updated via the Rippling API with the employees:write scope, which is outside this integration's scope.