Microsoft Dynamics 365 F&O and BambooHR integration

What moves between them

Records move one direction, from BambooHR into Microsoft Dynamics 365 F&O. A BambooHR new hire creates or updates a matching employee-vendor record in VendorsV2, a job information change updates the department or cost-center dimension value, and an employment status change to terminated deactivates the vendor. Departments and divisions from BambooHR feed D365 financial dimension values used for GL tagging. Sync runs near real time off BambooHR webhooks and falls back to a scheduled cursor-paged employee poll to catch any missed events. D365 holds no people data to send back, so the flow stays inbound.

How ml-connector handles it

The auth bridge holds two separate credential sets: BambooHR OAuth on the company subdomain (its authorize and token URLs are subdomain-scoped, not global) or a legacy API key, and the Entra ID client-credentials token D365 F&O requires, refreshed each hour. On each BambooHR webhook, ml-connector verifies the X-BambooHR-Signature HMAC-SHA256 over the raw body plus the X-BambooHR-Timestamp using a constant-time compare, rejecting anything unsigned. Because the webhook payload is only an employee ID and a changedFields list, it then calls GET employees/{id} with an explicit fields list to pull the current values, since BambooHR returns only the ID by default. Employee data maps to a vendor in VendorsV2, and the BambooHR department maps to a D365 financial dimension passed as a formatted display string; that dimension format must be configured in D365 first or the write fails silently. The BambooHR employee ID is stored as the natural key, so re-delivered events update rather than duplicate, which matters because BambooHR has no idempotency key and a duplicate vendor on a D365 natural key errors. Writes target a single legal entity per flow via dataAreaId, BambooHR 503 throttling is retried on Retry-After, and D365 429 service-protection responses are retried on their Retry-After header.

A real-world example

A 600-person engineering services firm runs HR in BambooHR and finance in Microsoft Dynamics 365 F&O. Staff submit travel and tool expenses as vendor reimbursements, but finance was creating each employee-vendor by hand and tagging the wrong department, so reimbursements posted to closed cost centers and month-end took days to clean up. With this connection a BambooHR hire creates the vendor and the right department dimension automatically, a transfer updates the dimension, and a termination deactivates the vendor the same day, so expense entries land on valid cost centers without re-keying.

What you can do

• •New BambooHR hires create matching employee-vendor records in Microsoft Dynamics 365 F&O.
• •Department and division changes in BambooHR update D365 F&O financial dimension values for GL tagging.
• •Terminations in BambooHR deactivate the corresponding D365 vendor so reimbursements stop.
• •Every BambooHR webhook signature is verified before any write to D365 F&O.
• •A scheduled cursor-paged BambooHR poll backfills any employee events the webhooks missed.

Questions

Does data flow back from Dynamics 365 F&O into BambooHR?

No. BambooHR is the HRIS system of record for people, and Microsoft Dynamics 365 F&O holds no employee master that BambooHR needs. The sync is one direction, from BambooHR into D365 F&O. D365 finance objects such as invoices and journals have no place in BambooHR, which has no vendors, invoices, or GL accounts.

How are the two different authentication methods handled?

ml-connector stores both credential sets and bridges them on every run. BambooHR uses OAuth 2.0 authorization code on its company subdomain, where the authorize and token URLs are subdomain-scoped rather than a single global endpoint, with legacy API key auth as a fallback. Microsoft Dynamics 365 F&O uses OAuth 2.0 client credentials through Microsoft Entra ID, and that bearer token is refreshed each hour since no refresh token is issued.

How does the integration avoid creating duplicate vendors?

BambooHR has no idempotency key, and creating the same vendor twice on a D365 natural key raises a duplicate-key error. ml-connector stores the BambooHR employee ID as the link to its D365 vendor, so a re-delivered employee.updated or employee.created event updates the existing record instead of inserting a new one. The webhook ControlNumber on the D365 side and constant-time signature checks further guard against acting on a replayed or unsigned event.