Microsoft Dynamics 365 F&O and Rippling integration

What moves between them

The main flow runs from Rippling into Microsoft Dynamics 365 F&O. After each pay run, ml-connector reads Rippling worker and payroll cost data and posts the resulting labor cost journals into the Dynamics general ledger through journal entities, mapped to the matching Dynamics main accounts and financial dimensions. Worker records flow the same direction so Dynamics headcount reflects Rippling hires, terminations, and rehires. Reference data such as Rippling departments, legal entities, and job codes is aligned with Dynamics financial dimensions so every payroll allocation lands on a valid account. Posted journal entries are read-only in Dynamics, and Rippling is treated as the system of record for workforce data, so ml-connector never writes financial entries back into Rippling.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Rippling side it sends the OAuth bearer token from an App Shop install or a direct API key on every request, and reads workers through the v2 REST API using cursor pagination with expand parameters for legal_entity, department, and compensation to avoid N+1 fetches. On the Dynamics side it accepts the full tenant environment host per customer, requests an Entra ID token with the client credentials flow against the environment scope, and refreshes that token when a call returns 401. Rippling departments, legal entities, and job codes are mapped to Dynamics financial dimensions first, and because Dynamics passes dimensions as a formatted display string the dimension format is configured before any write so a wrong format does not fail silently. Where Rippling App Shop webhooks for employee.created, employee.terminated, and employee.rehired are available they trigger the worker sync; otherwise ml-connector polls the employees and company_activity endpoints by updated_at on a schedule tied to the payroll calendar. Compensation that comes back in redacted_fields is skipped rather than written as empty. Rippling returns HTTP 429 without a Retry-After header, so ml-connector applies exponential backoff, while Dynamics returns 429 with a Retry-After header that is honored directly. Every record carries a full audit trail and can be replayed if a Dynamics post fails.

A real-world example

A mid-sized professional services firm of around 400 staff across three legal entities runs Microsoft Dynamics 365 F&O for finance and the general ledger and uses Rippling for HR and payroll. Before the integration, the finance team exported payroll registers from Rippling every pay period and re-entered the labor totals into Dynamics by hand, then spent the first days of month-end close chasing differences between HR headcount and the labor accounts in the ledger. With the two systems connected, each pay run's labor cost data flows into Dynamics automatically, allocated to the financial dimension for each department and legal entity, and worker changes keep the two systems aligned. Month-end close starts with the labor accounts already reconciled, and the manual re-keying step is gone.

What you can do

• •Post Rippling payroll cost data into the Microsoft Dynamics 365 F&O general ledger after every pay run through journal entities.
• •Keep Dynamics worker and vendor records aligned with Rippling hires, terminations, and rehires.
• •Map Rippling departments, legal entities, and job codes to Dynamics financial dimensions so payroll lands on valid accounts.
• •Bridge Rippling OAuth or API-key auth and the Microsoft Entra ID token Dynamics requires, refreshing each token before it expires.
• •Sync from Rippling App Shop webhooks where available, falling back to scheduled polling by updated_at, with retries and a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Rippling?

The main flow is Rippling into Dynamics. Payroll cost data and worker records move from Rippling into Dynamics, while departments, legal entities, and job codes are aligned with Dynamics financial dimensions. Posted journal entries are read-only in Dynamics and Rippling owns the workforce data, so ml-connector does not write financial entries back into Rippling.

How does the integration bridge the two authentication models?

Rippling uses OAuth 2.0 from an App Shop install or a direct API key, while Dynamics uses an OAuth 2.0 bearer token from Microsoft Entra ID via the client credentials flow against a tenant-specific environment host. ml-connector stores both credential sets encrypted, requests the Entra ID token per environment, and refreshes either token when a call returns 401.

Does the integration need Rippling webhooks, and how does it handle missing data?

No. Rippling webhooks are limited to App Shop listings, so where they are unavailable ml-connector polls the employees and company_activity endpoints by updated_at on a schedule tied to the payroll calendar. Compensation that Rippling returns in a redacted_fields list because of an entitlement gap is skipped rather than written as an empty value.