How does Joinly sync Dayforce to Microsoft Entra ID?

Joinly reads each HR change in Dayforce through the REST API and applies it to the matching Entra ID account automatically. Dayforce holds a single combined HR and payroll record per employee, so it is the authoritative starting point for each identity action.

1. Joiner. HR completes the hire in Dayforce. Joinly reads the new employee record, resolves the XRefCodes for department, position, location and pay group, and determines the role from those values. It then creates the account in Entra ID, assigns the right licences and maps the person into the correct groups — timed to the hire date on the record.

2. Mover. When someone changes position, department or location in Dayforce, Joinly updates their group membership, permissions and licences to match. Access that no longer fits the new position is revoked, so permissions stay aligned with the actual job rather than the one the person held last quarter.

3. Leaver. On the termination date recorded in Dayforce, Joinly disables the Entra ID account automatically. Because Dayforce termination and IdP deprovisioning are otherwise fully decoupled, this is exactly where access usually leaks — Joinly closes that gap so no account stays live after the last working day.

Example: Illustrative: a national hotel group hires a front-desk supervisor in Dayforce with a hire date next Monday, at its Amsterdam property. Joinly reads the record, resolves the location and position XRefCodes, waits until the hire date, creates the Entra ID account, assigns an Office E3 licence and adds the supervisor to the NL-FrontDesk group. When that person later moves to a revenue-management position, Joinly swaps the groups the same day and the old desk access falls away.

What manual user management costs

Without automation, every account starts as a Dayforce ticket or a CSV export that IT works through by hand. Aquera's Dayforce Identity Integration and Microsoft's API-driven inbound provisioning can move attributes across, but they leave role-to-group mapping, XRefCode resolution and the decoupled-termination gap to you — so the part that actually decides access still falls to people.

• Onboarding delays. New joiners wait for accounts, licences and group access while a ticket sits in a queue, losing productive days in their first week.

• Permissions that don't keep up (privilege creep). When movers change position or location, old access often stays attached, so people accumulate rights they no longer need.

• Forgotten offboarding. Because a Dayforce termination doesn't deprovision the identity by itself, accounts that aren't disabled on time are both a security and audit risk, and unused licences keep costing money.

Joinly vs. the middleware connectors for Dayforce

Aquera's Dayforce Identity Integration and Microsoft's API-driven inbound provisioning are a fine baseline, but they stop short of the part that actually decides access. Here's how the two compare for a Dayforce-driven setup.

Watch-outs when connecting Dayforce to Microsoft Entra ID

A few Dayforce-specific details decide whether this connection stays reliable at scale.

• XRefCode resolution. Every Dayforce lookup — department, position, location, pay group, employment status — is keyed by an XRefCode, and an invalid one returns a bare HTTP 400. Joinly resolves the right XRefCodes from the live tenant before it acts, so mappings don't fail silently halfway through a sync.

• Termination decoupled from deprovisioning. A Dayforce termination does not disable the Entra ID account on its own; the two are fully separate. Joinly bridges them, so the moment Dayforce records a termination date the account is disabled — no terminated employee retains downstream access.

• Future-dated work assignments. Dayforce can hold a position or work assignment that starts in the future, and acting on it too early causes problems. Joinly reads the hire / assignment date and times account creation to it, so access is ready on the right day and not before.

• Changing employment status and rehire. An employee's active status can change mid-record — leave, rehire, status conversion — and the EmploymentStatuses collection has to be read as a whole, not patched field-by-field. Joinly evaluates the current active status so a rehire reactivates the right account instead of creating a duplicate.

• UPN format with duplicate names. When two employees share a name, a naive UPN rule produces collisions. Joinly applies custom transformation rules — a suffix, location code or controlled tiebreaker — so every UPN is unique and predictable from day one.

Joinly handles each of these by default with custom mapping and transformation.

Always audit-ready

Every account action Joinly performs is logged: who was affected, when it happened, which access changed and which Dayforce change triggered it. For NIS2 that matters directly: access can be traced back to an authorised HR source rather than an ad-hoc request. Joinly is ISO 27001 certified, runs in an EU data centre in Amsterdam, applies least-privilege by default, and is built to meet NIS2 and ISO 27001.

Example case

Picture a national hotel group with around 4,500 employees across forty properties, running Dayforce as its combined HR and payroll core while its identity provisioning never quite keeps up. The middleware connector handles the simple cases, yet seasonal front-desk and housekeeping contracts, property-to-property transfers and a steady stream of rehires keep breaking it — terminated seasonal staff keep their Entra ID access because the Dayforce termination never disabled the account, and future-dated hires are provisioned the moment HR saves the record rather than on their actual start date.

Connect Dayforce to Microsoft Entra ID with Joinly and that work disappears. Joinly reads each HR change at the source and acts on it automatically: new hires have their account, Office licence and group access ready on their hire date, transfers between properties swap the right groups the same day, rehires reactivate the existing account, and leavers are disabled on their termination date with a 30-day soft-delete grace window.

"Terminated seasonal staff used to keep their access for weeks because nobody wired the Dayforce termination to the account. Now an account is simply ready on the hire date, a rehire reopens the right one, and we can show the auditor exactly which Dayforce change created every bit of access."

The outcome this setup is designed for: onboarding drops from days to zero touch, terminated-but-active accounts stop entirely, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.