How does Joinly sync Zenegy to Microsoft Entra ID?

Joinly reads each HR change in Zenegy through its OAuth 2.0 API and applies it to the matching Entra ID account automatically. Zenegy holds the authoritative payroll and employment record, so it is the starting point for each identity action.

1. Joiner. Payroll or HR completes the hire in Zenegy. Joinly reads the new employee and employment record, determines the role from attributes like department and job title, then creates the account in Entra ID, assigns the right licences and maps the person into the correct groups — timed to the employment start date.

2. Mover. When someone changes department or job title in Zenegy, Joinly updates their group membership, permissions and licences to match. Access that no longer fits the new role is revoked, so permissions stay aligned with the actual job.

3. Leaver. On the termination date recorded in Zenegy, Joinly disables the Entra ID account automatically. There are no orphaned accounts left active after someone has left, and no unused licences quietly costing money.

Example: A hospitality group runs Zenegy for its restaurants and hotels and hires a front-desk supervisor with a start date next Monday, in its Copenhagen department. Joinly reads the future-dated record, waits until the start date, creates the Entra ID account, assigns an Office E1 licence and adds the supervisor to the Reception group. When that person later moves to the events team, Joinly swaps the groups the same day.

What manual user management costs

Without automation, every account starts as a message from payroll or a line in a spreadsheet that IT works through by hand. Because Zenegy has no native identity connector, the usual stopgap is a manual export into Entra Cloud Sync or a hand-built script — which can move attributes across but has no idea what a Zenegy department means, so the part that actually decides access still falls to people.

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

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

• Forgotten offboarding. Accounts that aren’t disabled on time are both a security and audit risk, and unused licences keep costing money — and a manual export rarely reflects a leaver on the exact termination date.

Joinly vs. Entra Cloud Sync from a Zenegy export

Zenegy has no dedicated Entra provisioning connector, so the native fallback is Microsoft Entra Cloud Sync fed from a manual Zenegy export. That moves attributes, but it stops short of the part that actually decides access. Here’s how the two compare for a Zenegy-driven setup.

Watch-outs when connecting Zenegy to Microsoft Entra ID

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

• No native role-to-group logic. Zenegy models the organisation as departments and employments, not as Entra security groups. Joinly builds explicit mapping rules from department and job title to the correct groups and licences, so role drives access rather than manual assignment.

• Future-dated payroll changes. Zenegy stores hires, salary steps and pension changes as future-dated records well before they take effect. Provisioning too early or too late both cause problems. Joinly reads the effective start and end dates and times each action to them, so access is ready on the right day and not before.

• Flat department model. Because Zenegy is built for lean Danish payroll, its structure is deliberately shallow. Joinly enriches it with your own rules — combining department, job title and location — so a small source model still produces precise Entra ID group and licence assignment.

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

• Token and API hygiene. Zenegy’s API uses short-lived OAuth 2.0 Bearer tokens that must be refreshed. Joinly manages the authorization-code flow and token refresh for you, so the connection stays live without manual re-authentication.

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 Zenegy 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 runs in an EU data centre in Amsterdam, applies least-privilege by default, and is built to meet NIS2 and GDPR.

Example case

Picture a hospitality group with around 900 employees across a dozen restaurants and two hotels, running Zenegy for payroll and HR while its identity provisioning never quite keeps up. There is no native Zenegy-to-Entra path, so IT works from a weekly export: new front-of-house staff wait days for an account, seasonal contracts pile up, and when someone moves from one venue to another the old group access simply stays attached.

Connect Zenegy to Microsoft Entra ID with Joinly and that work disappears. Joinly reads each HR change in Zenegy at the source and acts on it automatically: new hires have their account, Office licence and group access ready on their employment start date, a move between venues swaps the right groups the same day, and leavers are disabled on their termination date with a 30-day soft-delete grace window.

“Seasonal hiring used to bury us in account requests. Now an account is simply ready on the start date, a move to another venue just swaps the access, and we can show exactly which Zenegy change created every login.” — Head of IT, hospitality group

The outcome this setup is designed for: onboarding drops from days to zero touch, privilege creep from old venues stops, and the team has a complete, source-backed audit trail for its next security review.