Microsoft Dynamics NAV and Rippling integration

What moves between them

The main flow is from Rippling into Microsoft Dynamics NAV. Employee records flow from Rippling into NAV as employees, with fields mapped to NAV employee master data. Department changes and headcount events trigger updates to NAV dimensions so cost allocations remain accurate. Accounting dimensions (cost centers, departments, legal entities) are synced from Rippling into NAV's dimension tables. Because NAV GL Accounts are read-only and GL entries immutable once posted, ml-connector reads accounting data from Rippling and prepares it for posting into NAV journals without write-back. Synchronization is event-driven via Rippling webhooks where App Shop OAuth is enabled, or polling-based via updated_at filters where direct API-key authentication is used.

How ml-connector handles it

ml-connector bridges Rippling's workforce API and Microsoft Dynamics NAV's OData platform. For cloud NAV deployments, it authenticates via OAuth 2.0 client credentials to both systems; for on-premises NAV, it uses OAuth 2.0 or web service access keys. If Rippling uses App Shop OAuth, ml-connector subscribes to employee lifecycle webhooks; otherwise it polls Rippling's employee endpoint with updated_at filtering on a schedule. Departments and legal entities from Rippling are mapped to NAV dimensions and validated against the chart of accounts. Employee records are deduplicated by external ID to prevent duplicate master records. Because NAV's GL Accounts are read-only, payroll-period accounting dimensions from Rippling are formatted for journal entry templates in NAV rather than direct GL account creation. NAV's 3-day webhook subscription requires renewal before expiry; ml-connector tracks expiry times and resubscribes proactively. Rippling compensation data may be restricted by entitlement, so ml-connector handles null compensation gracefully. All employee movements, department transfers, and dimension updates carry full audit trail and are replayable if a NAV journal post fails.

A real-world example

A mid-market services firm runs Microsoft Dynamics NAV for general ledger and financial reporting, and Rippling for payroll and HR across five departments. Before the integration, the finance team manually entered payroll headcount changes into NAV's employee master and department dimension tables every pay period, often causing mismatches where a terminated employee remained in NAV for two days after payroll termination, or a department transfer was delayed in NAV while already reflected in Rippling. With Rippling and NAV connected, every hire, termination, and department change in Rippling flows automatically into NAV, keeping the ERP headcount and cost dimension synchronized in real time. The finance team spends less time on manual data entry and more time on month-end closing, since the employee and department master data in NAV is always current with payroll.

What you can do

• •Sync Rippling employee records (name, email, department, status) into Microsoft Dynamics NAV employee master.
• •Keep NAV employee dimensions and cost centers aligned with Rippling department changes, transfers, and organizational updates.
• •Map Rippling departments and legal entities to NAV chart of accounts dimensions so payroll allocations land on valid cost centers.
• •Authenticate Rippling with OAuth2 or API Key, and Microsoft Dynamics NAV with OAuth 2.0 or web service access keys, supporting both cloud and on-premises deployments.
• •Track Rippling webhook subscription expiry and employee changes via polling with full audit trail and replay on NAV journal post failures.

Questions

Which direction does data move between Rippling and Microsoft Dynamics NAV?

The primary flow is from Rippling into NAV. Employee records, departments, and organizational dimensions move from Rippling into NAV's master files and dimension tables. Because NAV's GL Accounts are read-only and general ledger entries are immutable once posted, ml-connector reads accounting data from Rippling and prepares it for manual or templated journal entry in NAV rather than writing GL entries directly.

Does ml-connector support both cloud NAV and on-premises deployments?

Yes. For Business Central online, ml-connector authenticates via OAuth 2.0 client credentials to Microsoft Entra ID and the tenant-specific OData endpoint. For on-premises NAV, it uses OAuth 2.0 or legacy web service access keys against the server instance URL (default OData port 7048). On-premises deployments require the NAV administrator to enable OData and API services via the NAV Server Administration tool and open port 7048 through the firewall.

How does the integration handle Rippling's webhook restrictions and NAV's subscription expiry?

If Rippling is configured for App Shop OAuth, ml-connector subscribes to employee lifecycle webhooks. If direct API-key authentication is used, ml-connector polls Rippling's employee endpoint with updated_at filters on a schedule you set. On the NAV side, because webhooks expire after 3 days, ml-connector tracks subscription expiry and resubscribes automatically before expiration so that employee and dimension changes are captured without gaps.